1
0
mirror of https://github.com/Snailclimb/JavaGuide synced 2025-06-25 02:27:10 +08:00
This commit is contained in:
TommyMerlin 2021-06-21 16:53:08 +08:00
parent 35adb48753
commit 4685dd8a5c

View File

@ -1,6 +1,5 @@
点击关注[公众号](#公众号)及时获取笔主最新更新文章并可免费领取本文档配套的《Java 面试突击》以及 Java 工程师必备学习资源。
<!-- @import "[TOC]" {cmd="toc" depthFrom=1 depthTo=6 orderedList=false} -->
<!-- code_chunk_output -->
@ -187,8 +186,8 @@ OK
#### 6.2. list
1. **介绍** **list** 即是 **链表**。链表是一种非常常见的数据结构,特点是易于数据元素的插入和删除并且可以灵活调整链表长度,但是链表的随机访问困难。许多高级编程语言都内置了链表的实现比如 Java 中的 **LinkedList**,但是 C 语言并没有实现链表,所以 Redis 实现了自己的链表数据结构。Redis 的 list 的实现为一个 **双向链表**,即可以支持反向查找和遍历,更方便操作,不过带来了部分额外的内存开销。
2. **常用命令:** `rpush,lpop,lpush,rpop,lrangellen` 等。
1. **介绍** **list** 即是 **链表**。链表是一种非常常见的数据结构,特点是易于数据元素的插入和删除并且可以灵活调整链表长度,但是链表的随机访问困难。许多高级编程语言都内置了链表的实现比如 Java 中的 **LinkedList**,但是 C 语言并没有实现链表,所以 Redis 实现了自己的链表数据结构。Redis 的 list 的实现为一个 **双向链表**,即可以支持反向查找和遍历,更方便操作,不过带来了部分额外的内存开销。
2. **常用命令:** `rpush,lpop,lpush,rpop,lrange,llen` 等。
3. **应用场景:** 发布与订阅或者说消息队列、慢查询。
下面我们简单看看它的使用!
@ -342,7 +341,7 @@ OK
1. **介绍:** bitmap 存储的是连续的二进制数字0 和 1通过 bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态key 就是对应元素本身 。我们知道 8 个 bit 可以组成一个 byte所以 bitmap 本身会极大的节省储存空间。
2. **常用命令:** `setbit``getbit``bitcount``bitop`
3. **应用场景:** 适合需要保存状态信息(比如是否签到、是否登录...)并需要进一步对这些信息进行分析的场景。比如用户签到情况、活跃用户情况、用户行为统计(比如是否点赞过某个视频)。
3. **应用场景** 适合需要保存状态信息(比如是否签到、是否登录...)并需要进一步对这些信息进行分析的场景。比如用户签到情况、活跃用户情况、用户行为统计(比如是否点赞过某个视频)。
```bash
# SETBIT 会返回之前位的值(默认是 0这里会生成 7 个位
@ -375,7 +374,7 @@ OK
使用时间作为 key然后用户 ID 为 offset如果当日活跃过就设置为 1
那么我该如果计算某几天/月/年的活跃用户呢(暂且约定,统计时间内只有有一天在线就称为活跃),有请下一个 redis 的命令
那么我该如何计算某几天/月/年的活跃用户呢(暂且约定,统计时间内只要有一天在线就称为活跃),有请下一个 redis 的命令
```bash
# 对一个或多个保存二进制位的字符串 key 进行位元操作,并将结果保存到 destkey 上。
@ -414,7 +413,7 @@ BITOP operation destkey key [key ...]
**使用场景三:用户在线状态**
对于获取或者统计用户在线状态,使用 bitmap 是一个节约空间效率又高的一种方法。
对于获取或者统计用户在线状态,使用 bitmap 是一个节约空间效率又高的一种方法。
只需要一个 key然后用户 ID 为 offset如果在线就设置为 1不在线就设置为 0。
@ -424,7 +423,7 @@ BITOP operation destkey key [key ...]
**既然是单线程,那怎么监听大量的客户端连接呢?**
Redis 通过**IO 多路复用程序** 来监听来自客户端的大量连接(或者说是监听多个 socket它会将感兴趣的事件及类型(读、写)注册到内核中并监听每个事件是否发生。
Redis 通过**IO 多路复用程序** 来监听来自客户端的大量连接(或者说是监听多个 socket它会将感兴趣的事件及类型读、写)注册到内核中并监听每个事件是否发生。
这样的好处非常明显: **I/O 多路复用技术的使用让 Redis 不需要额外创建多余的线程来监听客户端的大量连接,降低了资源的消耗**(和 NIO 中的 `Selector` 组件很像)。
@ -466,7 +465,7 @@ Redis 通过**IO 多路复用程序** 来监听来自客户端的大量连接(
我觉得主要原因有下面 3 个:
1. 单线程编程容易并且更容易维护;
2. Redis 的性能瓶颈不 CPU ,主要在内存和网络;
2. Redis 的性能瓶颈不 CPU ,主要在内存和网络;
3. 多线程就会存在死锁、线程上下文切换等问题,甚至会影响性能。
### 9. Redis6.0 之后为何引入了多线程?
@ -509,7 +508,7 @@ OK
(integer) 56
```
注意:**Redis 中除了字符串类型有自己独有设置过期时间的命令 `setex` 外,其他方法都需要依靠 `expire` 命令来设置过期时间 。另外, `persist` 命令可以移除一个键的过期时间 **
注意:**Redis 中除了字符串类型有自己独有设置过期时间的命令 `setex` 外,其他方法都需要依靠 `expire` 命令来设置过期时间 。另外, `persist` 命令可以移除一个键的过期时间 **
**过期时间除了有助于缓解内存的消耗,还有什么其他用么?**
@ -565,7 +564,7 @@ Redis 提供 6 种数据淘汰策略:
4.0 版本后增加以下两种:
7. **volatile-lfuleast frequently used**:从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
7. **volatile-lfuleast frequently used**:从已设置过期时间的数据集server.db[i].expires中挑选最不经常使用的数据淘汰
8. **allkeys-lfuleast frequently used**:当内存不足以容纳新写入数据时,在键空间中,移除最不经常使用的 key
### 14. Redis 持久化机制(怎么保证 Redis 挂掉之后再重启数据可以进行恢复)
@ -622,7 +621,7 @@ AOF 重写可以产生一个新的 AOF 文件,这个新的 AOF 文件和原有
AOF 重写是一个有歧义的名字,该功能是通过读取数据库中的键值对来实现的,程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。
在执行 BGREWRITEAOF 命令时Redis 服务器会维护一个 AOF 重写缓冲区,该缓冲区会在子进程创建新 AOF 文件期间,记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后,服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾,使得新旧两个 AOF 文件所保存的数据库状态一致。最后,服务器用新的 AOF 文件替换旧的 AOF 文件,以此来完成 AOF 文件重写操作
在执行 BGREWRITEAOF 命令时Redis 服务器会维护一个 AOF 重写缓冲区,该缓冲区会在子进程创建新 AOF 文件期间,记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后,服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾,使得新旧两个 AOF 文件所保存的数据库状态一致。最后,服务器用新的 AOF 文件替换旧的 AOF 文件,以此来完成 AOF 文件重写操作
### 15. Redis 事务