--- title: Redis description: 复习用 categories: [bagu] --- ## 字符串 ### 实现使用**SDS（简单动态字符串）**，SDS不仅可以保存字符串还可以保存二进制数据，获取长度的时间复杂度是O(1)，SDS的API是安全的，比如拼接字符串不会造成缓冲区溢出，总的来说就是对数组封装，提供一系列方便操作的API。字符串对象有三种编码：**int、raw、embstr** - 整数：ptr从void*转换为long

- 短字符串（至于多短，每个redis版本不一样）：分配一块连续空间保存redisObject和SDS

- 长字符串：分别为redisObject和SDS分配两个内存，redisObject.ptr指向SDS

embstr如果要修改大小的话，只能重新分配空间。因此embstr实际上是只读的，当要修改embstr的长度，redis会先将其转换为raw再进行修改。 ### 使用场景缓存对象、常规计数（INCR）、分布式锁（SET-NX）、共享Session ## List 列表 List在使用上就是一个Deque双端队列，存字符串 ### 实现 - redis3.2之前：小列表使用压缩列表实现，大列表使用双向链表实现 - redis3.2之后：使用quicklist实现 ### 使用场景消息队列： - 保序：LPUSH+RPOP，但是RPOP需要轮询，浪费CPU性能，因此还提供了BRPOP阻塞式读取 - 处理重复：每条消息设置一个全局唯一ID，利用ID判断是否已经消费，List不会为消息生成ID，需要用户自己添加 - 保证可靠：BRPOPLPUSH，读取的同时将消息插入另一个List作为留存，如果用户处理消息时失败，下次从留存List重新读取作为消息队列的缺点： - 不支持消费者组 ## Hash 哈希适合存储对象 ### 实现 - redis7.0之前：小Hash使用压缩列表，大Hash使用哈希表 - redis7.0之后：小Hash使用listpack，大Hash使用哈希表 ### 使用场景缓存对象：一般可以用String+序列化存储对象，并将变化频繁的字段抽出来用Hash存储 ## Set 集合 ### 实现 - 元素都是整数的小Set：整数集合 - 否则：哈希表 ### 使用场景点赞：保证每个用户只能点一次赞共同关注（SINTER）推荐关注（SDIFF）抽奖（允许重复中奖SRANDMEMBER，不允许SPOP）潜在风险：「并、交、差」的计算复杂度高，数据量大的情况下会阻塞redis。可以用从库进行计算，或交给客户端来自行处理，从而不阻塞主库 ## ZSet 有序集合比Set多了一个score，按照score排序。ZSet不支持「差」运行 ### 实现 - redis7.0之前：小zset使用压缩列表，大zset使用跳表 - redis7.0之后：小zset使用listpack，大zset使用跳表 ### 使用场景排行榜：score最大的前几个（ZREVRANGE），范围score内最小的前几个（ZRANGEBYSCORE）电话排序：获取132、133开头的号码（ ZRANGEBYLEX phone [132 (134 ），**不要在分数不一致的 SortSet 集合中去使用 ZRANGEBYLEX和 ZREVRANGEBYLEX 指令，因为获取的结果会不准确** ## BitMap ### 实现 String ### 使用场景签到统计：比如一年的签到只需要365个bit 判断登陆态：用户ID作为offset，如果ID是连续的，5000 万用户只需要 6 MB 的空间（5000万位）连续签到用户总数：比如连续七天，需7个bitmap，对应位的位置则是用户id，将7个bitmap作与运算，并对结果BITCOUNT ## Stream 专门用于消息队列。Stream出来之前各种消息队列的缺陷： - pub/sub：不能持久化保存消息，离线重连的客户端不能读取历史消息 - List：无法重复消费，一个消息消费完就会被删除，生产者需要实现全局唯一ID Stream特点： - 持久化 - 自动生成全局唯一ID - ACK确认机制 - 消费组 ### 使用场景 Stream作为消息队列的时候，会面临： - 可能会丢数据 - 生产者：不会丢，提交给MQ后得到响应就代表发送成功 - 消费者：不会丢，pending list机制，消费者执行完逻辑后发送xack，确保消息不丢失 - 中间件（redis）：会丢失，AOF每秒异步写盘，redis宕机会造成数据丢失，主从复制也是异步的，当主从切换的时候也存在丢失数据的可能而专业的MQ部署的是一个集群，生产者在发布消息时，队列中间件通常会写「多个节点」，也就是有多个副本，这样一来，即便其中一个节点挂了，也能保证集群的数据不丢失。 - 消息堆积：Redis 的数据都存储在内存中，数据堆积会造成OOM，而专业的MQ数据最终都落盘。 ### pubsub为什么不能作为消息队列 - 无数据持久化：pubsub没有基于任何数据结构，不会写到RDB和AOF中 - 数据只能实时接收，消费者只能接收到订阅之后生产者发送的消息 - 消费者消费不过来的时候，消费者会被强行断开因此pubsub只适用于即时通讯的场景，比如构建哨兵集群 ## 机制

- redisDb 结构，表示 Redis 数据库的结构，结构体里存放了指向了 dict 结构的指针； - dict 结构，结构体里存放了 2 个哈希表，正常情况下都是用「哈希表1」，「哈希表2」用语rehash； - ditctht 结构，表示哈希表的结构，结构里存放了哈希表数组，数组中的每个元素都是指向一个哈希表节点结构（dictEntry）的指针； - dictEntry 结构，表示哈希表节点的结构，结构里存放了 **void * key 和 void * value 指针， *key 指向的是 String 对象，而 \*value 则可以指向 String 对象，也可以指向集合类型的对象，比如 List 对象、Hash 对象、Set 对象和 Zset 对象**。其中key和value指向的都是redisObject：

- type，标识该对象是什么类型的对象（String 对象、 List 对象、Hash 对象、Set 对象和 Zset 对象）； - encoding，标识该对象使用了哪种底层的数据结构； - **ptr，指向底层数据结构的指针**。 ## SDS 简单动态字符串在char buf[]的基础上增加了len（数据长度）、alloc（buf长度）、flags属性（sds类型），使其具有： - O(1)获取字符串长度 - 二进制安全：不再以末尾0判断字符串，而是len判断长度，使其能存储任意二进制内容 - 缓冲区安全：通过alloc - len计算剩余空间是否足够存储数据，不足的话会自动扩容 - 节省内存：比如sdshdr16和sdshdr32类型，最大只能存2\^16与2\^32，当字符串长度小的时候，可以减小结构头占用空间： ```c struct __attribute__ ((__packed__)) sdshdr16 { uint16_t len; uint16_t alloc; unsigned char flags; char buf[]; }; struct __attribute__ ((__packed__)) sdshdr32 { uint32_t len; uint32_t alloc; unsigned char flags; char buf[]; }; ``` 并且sdshdr取消了对齐，以时间换空间 ## 压缩列表结构：整个列表字节数 | 列表尾部字节距离起始地址的字节数｜列表的节点数量｜节点｜结束点0xFF

节点的结构：上一个节点的长度｜本节点的类型和长度｜节点数据 prevlen和encoding会根据节点数据的类型和大小来决定分配多少空间，redis这样做以尽量地节省内存压缩列表的优点： - 紧凑型的数据结构以利用 CPU 缓存 - 针对不同长度的数据进行相应编码，以节省内存压缩列表的缺点： - 除了第一个和最后一个节点，查找节点O(n)复杂度 - 连锁更新问题：某个节点扩容后，导致后一个节点的prevlen更新，并且如果prevlen不止是更新数值，占据的内存还变大了，那么后后一个节点的prevlen也要更新....最差情况下导致所有节点连锁更新，导致多次分配内存。综上，压缩列表不适宜保存过多元素 ## 哈希表 redis的哈希表采用拉链法解决哈希冲突，哈希表和节点结构如下 ```c typedef struct dictht { //哈希表数组 dictEntry **table; //哈希表大小 unsigned long size; //哈希表大小掩码，用于计算索引值 unsigned long sizemask; //该哈希表已有的节点数量 unsigned long used; } dictht; typedef struct dictEntry { //键值对中的键 void *key; //键值对中的值，可以是uint、int、double或指针 union { void *val; uint64_t u64; int64_t s64; double d; } v; //指向下一个哈希表节点，形成链表 struct dictEntry *next; } dictEntry; ``` 实际上是用的是dict结构，存储了两个哈希表，一个存储数据，一个备用用来rehash ```c typedef struct dict { … //两个Hash表，交替使用，用于rehash操作 dictht ht[2]; … } dict; ``` redis采用渐进式rehash，在rehash期间，进行**新增、删除、查找**的时候，会将hash1对应位置上的元素迁移到hash2，这样就将rehash这整个大操作，均摊到每次用户的增删改查上。 rehash条件： - 负载因子>=1并且没有执行RDB快照或AOF重写时，进行rehash操作 - 负载因子>=5，强制进行rehash ## 整数集合 ```c typedef struct intset { //编码方式 uint32_t encoding; //集合包含的元素数量 uint32_t length; //保存元素的数组 int8_t contents[]; } intset; ``` encoding表示contents内元素的大小（16、32或64位）整数集合的升级：比如当前encoding=16，当加入一个需要用32位才能表示的整数时，需要将所有元素大小扩容为32位，并将encoding改成32 ## 跳表 redis只有zset到了跳表（O(logn)范围查询），另外zset还用了哈希表（O(1)等值查询）： ```c // 当插入或者更新的时候需要同时维护dict和zsl typedef struct zset { dict *dict; zskiplist *zsl; // 大部分操作都是范围操作，使用跳表 } zset; ``` 跳表结构： ```c typedef struct zskiplist { struct zskiplistNode *header, *tail; unsigned long length; int level; } zskiplist; ``` 节点结构： ```c typedef struct zskiplistNode { //Zset 对象的元素值 sds ele; //元素权重值 double score; //后向指针 struct zskiplistNode *backward; //节点的level数组，保存每层上的前向指针和跨度 struct zskiplistLevel { struct zskiplistNode *forward; unsigned long span; } level[]; } zskiplistNode; ```

查找规则：从头节点的最高层开始，当forward != null，并且forward小于要找的节点时，则移动到forward，否则往下移动一层，判断forward != null，并且forward....（与上一层进行的步骤相同） - 先从头节点的最高层开始，L2 指向了「元素：abc，权重：3」节点，这个节点的权重比要查找节点的小，所以要访问该层上的下一个节点； - 但是该层的下一个节点是空节点（ leve[2]指向的是空节点），于是就会跳到「元素：abc，权重：3」节点的下一层去找，也就是 leve[1]; - 「元素：abc，权重：3」节点的 leve[1] 的下一个指针指向了「元素：abcde，权重：4」的节点，然后将其和要查找的节点比较。虽然「元素：abcde，权重：4」的节点的权重和要查找的权重相同，但是当前节点的 SDS 类型数据「大于」要查找的数据，所以会继续跳到「元素：abc，权重：3」节点的下一层去找，也就是 leve[0]； - 「元素：abc，权重：3」节点的 leve[0] 的下一个指针指向了「元素：abcd，权重：4」的节点，该节点正是要查找的节点，查询结束。 redis跳表不严格维持第k层和第k+1层之间节点的比例，而是设定一个等于这个比例的概率：**跳表在创建节点的时候，随机生成每个节点的层数**，当创建新节点的时候，会生成范围为0～1的随机数，如果随机数小于0.25则层数+1，重复这个过程直到随机数大于0.25或达到最大层高64。那么两层节点的概率为1/4、三层节点概率为1/16...以此类推跳表与常见的logn查找树相比： - **平衡树 VS 跳表**：跳表实现更简单，不需要旋转等操作维持平衡，并且在p=0.25下，每个节点平均的指针数量为1.33，而平衡树的指针为2，跳表更加节省内存，而且需要调整的话只需要修改p即可，更加灵活 - **红黑树 VS 跳表**：跳表实现更简单，不需要旋转/染色来保持平衡，并且范围查询没有跳表效率好 - **B+树 VS 跳表**：跳表实现更简单，不需要在节点分裂/合并来保持平衡，B+树更适用于数据保存在外存的应用，核心思想是通过在节点存储更多的索引信息，降低树高，以用更少的IO次数来查询到数据 ## quicklist 用于新版redis实现List列表。quicklist是「压缩列表+双链表」的结合，链表每个节点是一个压缩列表，压缩列表的大小限制在一定大小范围，大大减少了连锁更新带来的负面影响。

## listpack listpack用于替代压缩列表，解决连锁更新的问题：

len记录encoding+data的总长度，这样一来当某个节点的大小发生变化，不会影响到其他的节点的大小。 ## AOF (Append only file) AOF是记录所有「写操作」的日志。AOF的写是同步的，先进行写操作，再将该写操作写入AOF。每次写操作完成后都使用write函数将其写入AOF，但是此时只是写入了操作系统内核缓冲区，数据还没写到磁盘，可以通过fsync函数马上刷盘。可以配置三种刷盘策略： - No：不调用fsync，由操作系统来决定什么时候将内核缓冲区的内容写到磁盘 - Everysec：每秒fsync - Always：每次write都fsync 重写机制（实际上叫压缩机制更合理）：同一个键值只保留最后一个写操作（通过内存当前所有的数据），以去除冗余的写操作。重写过程中不改动原来的AOF，只是写到临时文件，重写完成后再覆盖原文件，否则，如果直接对原文件重写并且中途重写失败的话，则数据遭到破坏不可逆转。后台重写：创建bgrewriteaof子进程负责重写（*扫描数据库中所有数据，逐一把内存数据的键值对转换成一条命令写入日志*），主进程正常处理客户端请求，同时主进程开启AOF重写缓冲区用于保留新的写操作。子进程重写完成后向主线程发信号，此时主线程将AOF重写缓冲区内容追加到新的AOF文件中，并覆盖原有AOF文件。整个重写过程中主线程发生阻塞的情况有： - 主线程由于fork子线程后的内存是共享且只读的，因此修改key的时候会触发COW（copy on write），如果是复制大key则阻塞时间长 - 主线程处理重写完成的信号，将 AOF 重写缓冲区中的所有内容追加到新的 AOF 的文件中，并覆盖旧 AOF 文件 ## RDB (Redis Database) RDB记录某个时间点的全量数据快照。通过save（同步）或bgsave（子进程）来生成RDB，而RDB的加载是redis启动的时候自动执行的。混合持久化：混合持久化工作在AOF重写日志，子进程层重写AOF的时候不是将内存数据转换为写操作记录到AOF文件，而是以RDB的方式记录到AOF文件，最后主进程将RDB与重写缓冲区的AOF格式内容加入，最后文件内容为：

由于前半部份是RDB格式，因此下次加载的时候会很快。 ## 数据恢复优先加载AOF，因为AOF的数据更加完整，比如策略为Everysec的时候最多只会丢失一秒内的数据，如果AOF不存在的话再加载RDB。 ## 过期删除策略 - 定时：创建一个定时事件，事件到达时事件处理器删除key。优点是内存友好（及时删除key），缺点是CPU不友好（key较多的时候CPU还得花时间去删除暂时也不会用到的key） - 惰性：每次访问key的时候才去检查过期时间。优点是CPU友好，缺点是内存不友好 - 定期：每隔一段时间随机选出一批key，删除其中过期的key，优点是综合了内存和CPU友好，不过根据场景需要调参（触发删除的频率）选择惰性+定期比较好。 ## 内存淘汰策略八种策略：noeviction, volatile-(random/ttl/lru/lfu), allkeys-(random/lru/lfu) redis的lru：传统lru基于链表，而redis只是给每个key记录了最后一次访问时间，淘汰的时候随机选择一批key，淘汰访问时间最久远的，这样就不用维护链表，提升性能也节省空间。 redis的lfu：传统lfu基于双哈希+链表，而redis只是给每个key记录了最后一次访问时间和访问频次，淘汰的时候淘汰频次最低的，频次一样则淘汰访问时间最久远的。而频次的更新规则如下： - 先衰减：距离上一次访问时间越久，衰减越大 - 再增加：按照一定概率增加，频次越大的key，越难增加 ## 主从第一次同步：在从服务器上执行「replacaof 主服务器地址端口」，然后主从双方就会建立连接，主服务器bgsave子进程生成RDB文件并传给从服务器。生成RDB到从服务器加载完成RDB期间，主服务器新的写操作都写到缓存中。从服务器加载RDB完成后，主服务器发送缓存（新的写操作）给从服务器并执行，同步完成。命令传播：第一次同步后，TCP连接会一直维持着，后续主服务器的写操作命令都基于这个长链接传给从服务器。增量复制：主从意外断开重连之后，就会采取增量复制，使从服务器恢复断连到重连这段时间内未同步的数据。做法是：主服务器维护一个固定大小的环形缓冲区，维护一个master_repl_offset记录当前写到的位置，主服务器每次进行写操作时，除了将写操作命令发给从服务器，还会将其写入环形缓冲区中，并推进master_repl_offset，并且由于缓冲区大小有限，最新会覆盖最旧的数据。从服务器也维护一个slave_repl_offset记录当前读到的位置，每次接收主服务器同步过来的写命令，就会推进salve_repl_offset。重连后从服务器将自己的offset发给主服务器，主服务器检查「master_repl_offset - slave_repl_offset」如果小于缓冲区大小的话，那么就将这段缓冲区内容发给从缓冲区进行同步，否则就全量同步。

为了避免从服务器重连后全量同步开销太大，因此这个环形缓冲区最好根据实际情况设大些。 ## 哨兵由于主从模式是读写分离的，因此主节点挂了要重新选出新的主节点，哨兵节点就是用来监控主节点、选取新主节点以及通知新的主节点已经选出来了。 **客观下线**：哨兵每隔一秒ping所有主从节点，如果在规定时间内没收到pong的话就判定节点为「主观下线」。而对于主节点来说，还有「客观下线」，因为主节点可能只是因为网络拥塞或者压力大导致哨兵没及时收到pong。为了减少误判，哨兵一般设为集群，只有quorum数量的哨兵节点都认为主节点主观下线，此时客观下线才成立。 **leader选举**：判定客观下线后，还需要从哨兵中选出leader，由leader来执行主从切换。由判定客观下线的哨兵节点成为leader，比如哨兵B先发现主观下线，询问哨兵A和C是否也主观下线，收到超半数且达到quorum数量的赞成票后判定为客观下线并成为candidate，随后B先投自己一票，并且让A和C也投B一票，当票数超过半数则B成为leader，开始执行主从切换。 **主从切换**（由leader执行）: 1. 哨兵**选取新主节点** 1. 根据优先级配置选择**优先级**大的节点 2. 如果优先级相同，选择**slave_repl_offset**更靠近master_repl_offset的节点 3. 如果slave_repl_offset相同，那么选择**ID较小**的节点然后向该节点发送slaveof no one使其转换为主节点, 并每秒发送一次info，轮询其状态 2. 哨兵**通知其他从节点**，向其他从节点发送「slaveof 新主节点地址端口」 3. 哨兵**通知客户端主节点的改变（使用pub/sub）** 4. 哨兵**继续监视旧主节点**，发现其上线之后发送「slaveof 新主节点地址端口」 **哨兵集群的建立（使用pub/sub）**：通过在主节点上使用pub/sub，进行哨兵之间的通讯。比如哨兵A在频道上发布自己的地址和端口，其他哨兵就会收到并与A建立连接

**哨兵获取从节点信息**：哨兵向主节点发送info命令，主节点返回从节点信息，获取从节点信息后，哨兵就可以与从节点建立连接并监视从节点

总而言之，主节点作为通讯中介。 ## 集群其实就是将数据存储到不同的redis实例上，以降低对单主节点的依赖，提高redis服务的读写性能。一个redis切片集群有16384个哈希槽，要么平均要么手动将这些个哈希槽分配给集群中各个redis实例。当存储数据的时候，将key哈希到对应的哈希槽中，本质就是哈希到对应的redis节点中。脑裂：指的是集群出现多个主节点，比如某个集群的主节点被分区（暂时与其他节点无法连接，好比自己一个处于一个与世隔绝的分区），但主节点本身与客户端都不知情，并继续接收来自客户端的命令。接着哨兵从从节点中选出新的主节点，此时整个集群同时存在两个主节点。脑裂带来的问题：当被分区的主节点恢复并重新加入集群后，会被哨兵降级为从节点，并且数据被全量同步为新主节点的数据，导致旧主节点被分区这段时间内客户端写入的数据被丢失。解决方案：**为主节点接收客户端命令设定条件，即主节点保持连接的从库至少有N个，并且主从复制时从库的ACK消息延迟不能超过T秒，否则该主库就会直接返回错误给客户端，拒绝处理命令，直>到新主库上线** ## 缓存雪崩产生原因：大量key同时过期、redis宕机解决办法： - 大量key同时过期： - 过期时间+随机数：避免大量key同时失效 - 互斥锁：避免缓存重复构建 - 不设置过期时间，后台更新：让后台线程定时更新缓存。除了更新缓存，也要负责内存淘汰而重构缓存，有两种方法重构： - 频繁轮询，检测到缓存淘汰后马上重构（定期） - 业务线程发现缓存失效后，通过消息队列告知后台线程去重构（惰性） - redis宕机 - 服务熔断/限流，等到redis恢复并预热完成后再恢复 - 构建高可用集群 ## 缓存击穿产生原因：热点数据过期解决办法： - 互斥锁 - 后台更新 ## 缓存穿透产生原因：数据库根本没有这样的数据解决办法： - 检查请求参数，过滤非法请求 - 缓存空值 - 布隆过滤器：写入key的时候为key生成多个hash，并将这多个hash在哈希表对应的位置1。当读key的时候按同样方式生成多个hash，如果这些hash对应的位都为1，则判定为key存在。综上，判定为不存在一定不存在，但是判定存在不一定存在。

## 数据一致性先更新数据库再更新缓存的问题： - A更新数据库 - B更新数据库 - B更新缓存 - A更新缓存先更新缓存再更新数据库的问题： - A更新缓存 - B更新缓存 - B更新数据库 - A更新数据库无论是先更新数据库还是先更新缓存都会存在数据库和缓存不一致。先删缓存再更新数据库的问题： - A删缓存 - B读缓存未命中，重构缓存为旧值 - A更新数据库先更新数据库再删除缓存的问题1（假设当前缓存没有数据）： - A读缓存未命中，读取数据库 - B更新数据库，删除缓存 - A用旧值重建缓存但上述情况发生概率很低，因为A读完数据库后马上重建缓存，而「重建缓存」这个动作其实是很快的，一般在「B更新数据库，删除缓存」前就已经完成，**因此「先更新数据库再删除缓存」这个方案相比之下最好**。最后再加上过期时间兜底这种发生不一致的低概率情况。先更新数据库再删除缓存的问题2：若「删除缓存」这个操作失败的话，直到下次更新之前，读到的都是缓存中的旧值，解决办法有两种 - 重试：将「删除缓存操作」加入消息队列，重试直到成功，并向消息队列返回ack - 订阅mysql binlog：比如使用canal中间件，订阅binlog中数据的更新操作，并推送给缓存服务让其删除对应的缓存两者都是采用异步操作缓存，异步删除是为了快速响应客户端，但要求客户端对重试这段时间内容忍读到缓存中的旧值（即在consistency和 available之间选择后者）。再次探讨为什么是删除而不是更新缓存：缓存的数据可能与数据库多张表有关，更新缓存可能还需要查询多张表。另外写多读少的场景下，删除缓存比更新缓存更有性价比。还有一种是延迟双删：首先删除缓存中的对应数据，然后对数据库中的数据进行更新操作，在一个短暂的延迟（例如 1 秒或根据具体场景调整）之后，再次删除缓存中的数据，确保缓存中不残留过期的数据。 ## 线程模型 redis单线程指的是「接收客户端请求，数据读写，响应客户端」这个过程。而redis内部还会启动几个线程来处理其他事情： - 关闭文件的线程 - AOF刷盘线程 - lazyfree线程，比如执行unlink key / flushdb async / flushall async 等命令

该单线程采用多路复用IO来接收客户端的请求： - 创建epoll和socket，绑定「连接事件处理函数」并加入epoll，然后epoll_wait等待事件到来 - 如果是连接事件，accept这个连接，绑定「读事件处理函数」并加入epoll - 如果是读事件，读取客户端发来的请求并执行，然后将客户端对象添加到发送队列，将执行结果放到发送缓冲区，注册「写事件处理函数」并加入epoll - 如果是写事件，通过write将缓冲区的执行结果发送出去，如果这一轮没有发完，则继续注册「写事件处理函数」随着网络硬件性能的提升，性能瓶颈出现在网络IO上，因此新版redis又引入了多线程来读/写网络IO数据。至此，redis的线程有： - 主线程：负责执行命令 - 三个后台线程：分别处理文件关闭（bio_close_file）、AOF刷盘（bio_aof_fsync）、释放内存（bio_lazy_free） - IO线程（多线程）：读请求和写响应，分担网络IO压力 ## 处理过期key 从库不会自己主动写或删除任何key，而是主库发现key过期时，才会在AOF新增一条del，并同步到所有从库。 ## 处理大key 大key指的是value很大。带来的问题：对大key操作耗时、传输大key耗时、阻塞后续请求、切片集群数据倾斜查找bigkey的方法： - **redis-cli --bigkeys**：最好在从节点执行。这个方法只能返回每种类型中最大的那个 bigkey。对于集合类型来说，这个方法只统计集合元素个数的多少，而不是实际占用的内存量 - **scan + type + [strlen/llen/hlen/scard/zcard/memory usage]** - **使用第三方RDB分析工具查找大key** 删除bigkey的方法： - 分批次删除 - 异步删除：手动unlink，或者开启lazyfree（针对内存淘汰、过期删除、从节点清除自身数据，避免这些操作阻塞主线程） ## 事务实际上redis支持的不是事务而是批量执行队列，并且命令不作检查无脑入队，提交后正确的命令会被执行，错误的命令会报错，即不符合原子性（要么全部成功要么全部失败）： ```c #获取name原本的值 127.0.0.1:6379> GET name "xiaolin" #开启事务 127.0.0.1:6379> MULTI OK #设置新值 127.0.0.1:6379(TX)> SET name xialincoding QUEUED #注意，这条命令是错误的 # expire 过期时间正确来说是数字，并不是‘10s’字符串，但是还是入队成功了 127.0.0.1:6379(TX)> EXPIRE name 10s QUEUED #提交事务，执行报错 #可以看到 set 执行成功，而 expire 执行错误。 127.0.0.1:6379(TX)> EXEC 1) OK 2) (error) ERR value is not an integer or out of range #可以看到，name 还是被设置为新值了 127.0.0.1:6379> GET name "xialincoding" ``` ## 分布式锁 ### set nx 加锁： ```c SET lock_key unique_value NX PX 10000 ``` unique_value是客户端唯一标识释放锁：判断是否当前客户端+解锁（lua脚本保证原子性）： ``` lua // 释放锁时，先比较 unique_value 是否相等，避免锁的误释放 if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end ``` 优点：高性能、实现简单、避免单点故障缺点：超时事件不好设置、集群模式下分布式锁不可靠（锁还未同步到从节点时主节点宕机，选出新主节点后相当于锁就失效了） ## 集群模式下的分布式锁使用redlock，核心思想是向每个节点都申请锁（相当于所有节点都是主节点）： - 条件一：客户端从超过半数（大于等于 N/2+1）的 Redis 节点上成功获取到了锁； - 条件二：客户端从大多数节点获取锁的总耗时（t2-t1）小于锁设置的过期时间。 ## redis为什么这么快 - **内存存储**：访问内存比访问磁盘快 - **数据结构**：比如SDS、渐进式扩容哈希、压缩列表、优化的压缩列表listpack、结合链表和压缩列表的quicklist、跳表等 - **非阻塞IO**：基于IO多路复用的网络IO，将 epoll 中的读、写、关闭、连接都转化成了事件，利用 epoll 的多路复用特性，把 IO 操作时间优化到了极致 - **线程模型**：单线程执行命令，避免多线程同步和切换的开销。而且还有后台线程处理耗时操作 - 主线程：负责执行命令 - 三个后台线程：分别处理文件关闭（bio_close_file）、AOF刷盘（bio_aof_fsync）、释放内存（bio_lazy_free） - IO线程（多线程）：读请求和写响应，分担网络IO压力