joeyhhhhh的博客

在上一篇文章认识redis的cluster(1)中介绍了Redis Cluster 中两个节点之间握手的核心流程，这也是搭建 Redis Cluster 的第一步让各个 Cluster 节点之间感知到彼此的存在。我们知道, Redis Cluster中每个Master节点至少会有一个Slave节点, 所以设置 Redis Cluster 中每个节点的主从角色就是启动 Redis Cluster第二步要做的事情。

Redis Cluster 内部按照 slot 对数据进行切分的，每个 Master 节点只负责维护一部分 slot 以及落到这些 slot 上的 KV 数据，但是 Redis Cluster 中每个节点都有全量的 slot 信息，这样的话，客户端无论连接到哪个节点，都可以知道自己访问的 Key 落到哪个 slot 里面以及这个 slot 位于哪个节点中。继续上面的示例，在节点 A 处理完节点 B 返回的 PONG 消息之后，就已经可以正确感知到节点 B 了，并且明确知晓自己与节点 B 之间网络连接。

Sentinel 是 Redis 提供的高可用解决方案之一。一个 Sentinel 服务进程其实本身就是 Redis 实例，只不过这个 Redis 服务实例是以 Sentinel 模式运行的，它不对外提供读写键值对的服务，而是监控其他 Redis 服务实例是否运行正常，有点类似现实生活中监工的感觉。为了防止 Sentinel 本身出现单点问题，一般会将多个 Sentinel 实例组成一个 Sentinel 集群,一般推荐 Sentinel 集群的实例个数为奇数。

Redis 中的主从复制协议有多次升级，所以这里我们从 2.8 版本开始一步步介绍 Redis 主从复制协议的升级和优化过程。在 Redis 2.8 版本之前，主从复制的核心流程如下：这里简单描述一下上图的流程。首先，在从库启动之后，会根据配置主动请求主库，建立网络连接。连接完成之后，从库会向主库发送 SYNC 命令，发起数据同步的请求。

Redis 最常见的应用场景就是缓存，我们在使用缓存的时候，一般不会存储 DB 里面全量的数据，而只用于缓存一部分 DB 热点数据，对于非热点数据，需要进行定期删除，防止 Redis 内存被撑爆，也就是我们常说“在 Redis 3.0 中，近似 LRU 算法进行了一次升级，引入了一个维护淘汰 Key 的候选池，这样可以提高筛选 Key 的精准度，使得近似 LRU 算法的效果更加接近于真正的 LRU 算法。：Redis 会按照近似 LRU 的算法，从设置了过期时间的 Key 中，选取 Key 进行淘汰。

RDB 是一个类似于快照的持久化方式，它会一次性将 Redis 内存中的全部数据写入到 RDB 文件中。AOF（Append Only File）持久化则是类似于增量的持久化，其核心思路是将 Redis 执行过的每条修改命令都保存到 AOF 文件中，从而实现持久化效果。当故障恢复的时候，Redis 可以根据 AOF 文件回放曾经执行过的每一条命令，这样的话，Redis 中的数据也就恢复到故障前的状态了。在实际生产环境中，一般会使用AOF + RDB。

RDB全称是 Redis DatabaseRDB 持久化就像是。Redis 在重启时，可以通过加载 RDB 文件快速恢复 Redis 内存数据，但是需要说明的是，由于 RDB 持久化的快照特性，Redis 会丢失最后一次 RDB 文件到重启之间的数据，如下图所示，蓝色部分的数据在 RDB 持久化的时候已经被保存下来了，但是红色部分的数据，会因为宕机而丢失。所以需要后面介绍的另一种持久化方式，也就是。

redis 从 5.0 版本开始支持提供 stream 数据类型，它可以用来保存消息数据，进而能帮助我们实现一个带有消息读写基本功能的消息队列，并用于日常的分布式程序通信当中。其中，为了节省内存空间，在 stream 数据类型的底层数据结构中，采用了radix tree和listpack两种数据结构来保存消息。listpack 是一个紧凑型列表，在保存数据时会非常节省内存；radix tree，这个数据结构的最大特点是适合保存具有相同前缀的数据，从而实现节省内存空间的目标，以及支持范围查询。

Zset，即有序集合（Sorted Set），是 Redis 提供的一种复杂数据类型。Zset 是 set 的升级版，它在 set 的基础上增加了一个权重参数 double类型的分数值(即score)，使得集合中的元素能够按 score 进行有序排列。zset的listpack结构当满足以下两个条件时, zset采用listpack结构存储数据存储结构如下两个条目为一组, 分别存储实际值和score, 同时listpack也支持查询步长+1的跨越条目查询, listpack本身是无序的,但默认最多只会存储

在 Java 里面，HashSet 底层是用 HashMap 实现的。在 Redis 里面也是类似的，Redis 里面的 Hash 底层结构是 dict，Set 底层的结构也是 dict。但是，在元素都是整数值的时候，Set 可以用一种更省空间的方式来存数据，这种省空间的方式就是这一节要说的 intset。元素都是整数类型这个 Set 里面的元素个数，要少于配置指定的这个值，这个值默认是 512一旦这个 Set 集合不满足这两个条件，就会切换成 dict 作为底层存储。

dict使用key-value形式存储数据结构, hash使用的hashDictType只能存储字符串(sds结构)redis的hash集合在7.0版本之前value使用的是ziplist和dict存储数据,在7.0及以后就是listpack+dict结构默认ziplist(listpack)单个元素大于64字节或者hash中元素大于512个会转为dictdict使用两个数组来完成存储和rehash动作, 采用头插法转移数据。

quicklist 是一个类似于 Java 里面 LinkedList 的双向链表，大概结构如下图所示：quicklist 里面的节点是 quicklistNode 类型，quicklistNode 里面维护了 next、prev 指针，指向前后两个 quicklistNode 节点；然后还有一个 entry 指针，指向了一个 listpack 实例。真正的元素是存储在这个 listpack 里面的，那就是说，多个元素存储在一个 quicklistNode 里面。

前面介绍了string的结构类型, 那么Redis 为什么不用 C 语言的字符串，而非要自己搞一个出来呢？第一个原因是“安全的二进制存储”，在有的场景里面，我们在字符串里可能需要存\0这种特殊字符。比如说，\0这种数据，如下：如果直接用 C 语言字符串的话，\0表示字符串结尾，那我就会认为是到 Hello 字符串就完了，对不对？为了要存\0这种特殊字符，sds 就不再把\0当作字符串的结尾，而是明确地记录字符串的长度，比如说存个 length 字段，我就知道到第一个\0的时候，字符串还没结束。