这些你知道了吗？Redis 中常见的集群部署方案

Redis 的高可用集群

前言

这里来了解一下，Redis 中常见的集群方案

几种常用的集群方案

• 主从集群模式

• 哨兵机制

• 切片集群(分片集群)

主从集群模式

主从集群，主从库之间采用的是读写分离

• 主库：所有的写操作都在主库发生，然后主库同步数据到从库，同时也可以进行读操作；

• 从库：只负责读操作；

image.png

主库需要复制数据到从库，主从双方的数据库需要保存相同的数据，将这种情况称为"数据库状态一致"

来看下如何同步之前先来了解下几个概念

• 1、服务器的运行ID(run ID)：每个 Redis 服务器在运行期间都有自己的run ID，run ID在服务器启动的时候自动生成。

从服务器会记录主服务器的run ID，这样如果发生断网重连，就能判断新连接上的主服务器是不是上次的那一个，这样来决定是否进行数据部分重传还是完整重新同步。

• 2、复制偏移量 offset：主服务器和从服务器都会维护一个复制偏移量

主服务器每次向从服务器中传递 N 个字节的时候，会将自己的复制偏移量加上 N。

从服务器中收到主服务器的 N 个字节的数据，就会将自己额复制偏移量加上 N。

通过主从服务器的偏移量对比可以很清楚的知道主从服务器的数据是否处于一致。

如果不一致就需要进行增量同步了，具体参加下文的增量同步

全量同步

从服务器首次加入主服务器中发生的是全量同步

如何进行第一次同步？

image.png

1、从服务器连接到主服务器，然后发送 psync 到主服务器，因为第一次复制，不知道主库run ID,所以run ID为？；

2、主服务器接收到同步的响应，回复从服务器自己的run ID和复制进行进度 offset；

3、主服务器开始同步所有数据到从库中，同步依赖 RDB 文件，主库会通过 bgsave 命令，生成 RDB 文件，然后将 RDB 文件传送到从库中；

4、从库收到 RDB 文件,清除自己的数据，然后载入 RDB 文件；

5、主库在同步的过程中不会被阻塞，仍然能接收到命令，但是新的命令是不能同步到从库的，所以主库会在内存中用专门的 replication buffer，记录 RDB 文件生成后收到的所有写操作，然后在 RDB 文件，同步完成之后，再将replication buffer中的命令发送到从库中，这样就保证了从库的数据同步。

增量同步

如果主从服务器之间发生了网络闪断，从从服务将会丢失一部分同步的命令。

在旧版本，Redis 2.8之前，如果发生了网络闪断，就会进行一次全量复制。

在 2.8 版本之后，引入了增量同步的技术，这里主要是用到了 repl_backlog_buffer

Redis 主库接收到写操作的命令，首先会写入replication buffer(主要用于主从数据传输的数据缓冲)，同时也会把这些操作命令也写入repl_backlog_buffer这个缓冲区。

image.png

这里可能有点疑惑，已经有了replication buffer为什么还多余引入一个repl_backlog_buffer呢？

• repl_backlog_buffer一个主库对应一个repl_backlog_buffer，也就是所有从库对应一个repl_backlog_buffer，从库自己记录自己的slave_repl_offset。

• replication buffer用于主节点与各个从节点间，数据的批量交互。主节点为各个从节点分别创建一个缓冲区，由于各个从节点的处理能力差异，各个缓冲区数据可能不同。

如何主从断开了，当然对应的replication buffer也就没有了。这时候就依赖repl_backlog_buffer进行数据的增量同步了。

repl_backlog_buffer是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。

这里借用Redis核心技术与实战的一张图片

image.png

刚开始主服务器的 master_repl_offset 和从服务器 slave_repl_offset 的位置是一样的，在从库因为网络原因断连之后，随着主库写操作的进行，主从偏移量会出现偏移距离。

当从服务器连上主服务器之后，从服务把自己当前的 slave_repl_offset 告诉主服务器，然后主服务器根据自己的 master_repl_offset 计算出和从服务器之间的差距，然后把两者之间相差的命令操作同步给从服务器。

举个栗子

比如这里从服务器1，刚刚由于网络原因断连了一会，然后又恢复了连接，这时候，可能缺失了一段时间的命令同步，repl_backlog_buffer的增量同步机制就登场了。

repl_backlog_buffer会根据主服务器的master_repl_offset和从服务器slave_repl_offset，计算出两者命令之间的差距，之后把差距同步给replication buffer，然后发送到从服务器中。

image.png

repl_backlog_buffer中的缓冲空间要设置的大一点，如果从库读的过慢，因为是环形缓冲区，可能出现命令覆盖的情况，如果出现命令被覆盖了，从库的增量同步就无法进行了，这时候会进行一次全量的复制。

缓冲空间的计算公式是：缓冲空间大小 = 主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小。在实际应用中，考虑到可能存在一些突发的请求压力，我们通常需要把这个缓冲空间扩大一倍，即 repl_backlog_size = 缓冲空间大小 * 2，这也就是 repl_backlog_size 的最终值。

哨兵机制

对于主从集群模式，如果从库发生了故障，还有主库和其它的从库可以接收请求，但是如果主库挂了，就不能进行正常的数据写入，同时数据同步也不能正常的进行了，当然这种情况，我们需要想办法避免，于是就引入了下面的哨兵机制。

什么是哨兵机制

sentinel(哨兵机制)：是 Redis 中集群的高可用方式，哨兵节点是特殊的 Redis 服务，不提供读写，主要来监控 Redis 中的实例节点，如果监控服务的主服务器下线了，会从所属的从服务器中重新选出一个主服务器，代替原来的主服务器提供服务。

image.png

核心功能就是:监控，选主，通知。

监控：哨兵机制，会周期性的给所有主服务器发出 PING 命令，检测它们是否仍然在线运行，如果在规定的时间内响应了 PING 通知则认为，仍在线运行；如果没有及时回复，则认为服务已经下线了，就会进行切换主库的动作。

选主：当主库挂掉的时候，会从从库中按照既定的规则选出一个新的的主库，

通知：当一个主库被新选出来，会通知其他从库，进行连接，然后进行数据的复制。当客户端试图连接失效的主库时，集群也会向客户端返回新主库的地址，使得集群可以使用新的主库。

如何保证选主的准确性

哨兵会通过 PING 命令检测它和从库，主库之间的连接情况，如果发现响应超时就会认为给服务已经下线了。

当然这会存在误判的情况，如果集群的网络压力比较大，网路堵塞，这时候会存在误判的情况。

如果误判的节点是从节点，影响不会很大，拿掉一个从节点，对整体的服务，影响不大，还是会不间断的对外提供服务。

如果误判的节点是主节点，影响就很大了，主节点被标注下线了，就会触发后续的选主，数据同步，等一连串的动作，这一连串的动作很很消耗性能的。所以对于误判，应该去规避。

如何减少误判呢？

引入哨兵集群，一个哨兵节点可能会进行误判，引入多个少哨兵节点一起做决策，就能减少误判了。

当有多个哨兵节点的时候，大多数哨兵节点认为主库下线了，主库才会真正的被标记为下线了，一般来讲当有 N 个哨兵实例时，最好要有N/2 + 1个实例判断主库下线了，才能最终判定主库的下线状态。当然这个数值在 Redis 中是可以配置的。

如何选主

选举主节点的规则

1、过滤掉已经下线的服务器；

2、过滤掉最近5秒钟没有回复过主节点的 INFO(用于观察服务器的角色) 命令的服务器，保证选中的服务器都是最近成功通过信的；

3、过滤掉和下线主服务器连接超过down-after-milliseconds*10毫秒的从服务器，down-after-milliseconds是主服务器下线的时间，这一操作避免从服务器与主服务器过早的断开，影响到从库中数据同步，因为断开时间越久，从库里面的数据就越老旧过时。

然后对这些服务器根据slave-priority优先级(这个优先级是手动设置的，比如希望那个从服务器优先变成主服务器，优先级就设置的高一点) 进行排序。

如果几台从服务器优先级相同，然后根据复制偏移量从大到小进行排序，如果还有相同偏移量的从服务器，然后按照 runID 从小到大进行排序，直到选出一台从服务器。

哨兵进行主节点切换

当根据选举规则，选出了可以成为主节点的从节点，如何进行切换呢？

在哨兵中也是有一个 Leader 节点的，当一个从库被选举出来，从库的切换是由 Leader 节点完成的。

Leader 节点的选举用的是 Raft 算法，关于什么是 Raft 算法可参考Raft一致性算法原理

在raft算法中，在任何时刻，每一个服务器节点都处于这三个状态之一：

• Follower:追随者，跟随者都是被动的：他们不会发送任何请求，只是简单的响应来自领导者或者候选人的请求；

• Candidate:候选人，如果跟随者接收不到消息，那么他就会变成候选人并发起一次选举，获得集群中大多数选票的候选人将成为领导者。

• Leader:领导者，系统中只有一个领导人并且其他的节点全部都是跟随者，领导人处理所有的客户端请求（如果一个客户端和跟随者联系，那么跟随者会把请求重定向给领导人）

哨兵节点的选举总结起来就是：

1、每个做主观下线的sentinel节点向其他sentinel节点发送命令，要求将自己设置为领导者；

2、接收到的sentinel可以同意或者拒绝；

3、如果该sentinel节点发现自己的票数已经超过半数并且超过了 quorum，quorum 用来配置判断主节点宕机的哨兵节点数。简单点讲就是：如果 Sentinel 集群有 quorum 个哨兵认为 master 宕机了，就「客观」的认为 master 宕机了；

4、如果此过程选举出了多个领导者，那么将等待一段时重新进行选举；

故障转移

• sentinel的领导者从从机中选举出合适的丛机进行故障转移；

• 对选取的从节点进行slave of no one命令，（这个命令用来让从机关闭复制功能，并从从机变为主机）；

• 更新应用程序端的链接到新的主节点；

• 对其他从节点变更 master 为新的节点；

• 修复原来的 master 并将其设置为新的 master 的从机。

消息通知

哨兵和哨兵之前，哨兵和从库之间，哨兵和客户端是如何相互发现，进行消息传递？

哨兵和哨兵之间的相互发现，通过 Redis 提供的pub/sub机制实现，因为每个哨兵节点都会和主库进行连接，通过在主库中发布信息，订阅信息，就能找到其他实例的连接信息。

哨兵节点和从库，通过哨兵向主库发送 INFO 命令来完成，哨兵给主库发送 INFO 命令，主库接受到这个命令后，就会把从库列表返回给哨兵。接着，哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控。

哨兵和客户端之间：每个哨兵实例也提供pub/sub机制，客户端可以从哨兵订阅消息，来获知主从库切换过程中的不同关键事件。

哨兵提升一个从库为新主库后，哨兵会把新主库的地址写入自己实例的 pubsub（switch-master） 中。客户端需要订阅这 个pubsub，当这个 pubsub 有数据时，客户端就能感知到主库发生变更，同时可以拿到最新的主库地址，然后把写请求写到这个新主库即可，这种机制属于哨兵主动通知客户端。

如果客户端因为某些原因错过了哨兵的通知，或者哨兵通知后客户端处理失败了，安全起见，客户端也需要支持主动去获取最新主从的地址进行访问。

切片集群

对于数据库我们知道，如果数据量大会进行分库分表，一般有两种方案纵向拆分和横向拆分。这在 Redis 中，同样适用。

Redis 中的扩展

• 纵向扩展：更改节点类型以调整集群大小，升级单个Redis实例的资源配置，包括增加内存容量、增加磁盘容量、使用更高配置的CPU。

• 横向扩展：通过添加或删除节点组（分片）来更改复制组中的节点组（分片）数量。

image.png

简单点讲就是：垂直扩容就是增加自身的容量，横向扩容就是加机器。

缺点对比

纵向扩容：

1、如果一味的增加自身的容量，意味着自身存储的数据将会越来越大，过大的数据，持久化时间将会变得很长，影响自身的响应速度；

2、同样堆硬件总归是有上线，达到一定量之后，还是要考虑进行横向扩容；

横向扩容：

横向扩容要面临的问题，如果发生了分片的扩容，就需要考虑数据的迁移，同时数据切片后，在多个实例之间如何分布？，客户端如何知道访问的数据在哪个实例中。。。

虽然有这些问题的存在，好在已经有一些成熟的方案来处理横向扩容所遇到的问题了

官方的集群解决方案就是Redis Cluster；社区的解决方案有 Codis 和 Twemproxy，Codis 是由我国的豌豆荚团队开源的，Twemproxy 是 Twitter 团队的开源的。

这里主要看下Redis Cluster是如何进行处理的

Redis Cluster方案

1、Redis Cluster方案采用哈希槽来处理 KEY 在不同实例中的分布，一个切片集群共有16384个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的key，被映射到一个哈希槽中。

2、一个 KEY ，首先会根据CRC16算法计算一个16 bit的值；然后，再用这个 16bit 值对 16384 取模，得到0~16383范围内的模数，每个模数代表一个相应编号的哈希槽。

3、然后把哈希槽分配到所有的实例中，例如，如果集群中有N个实例，那么，每个实例上的槽个数为16384/N个。

当然这是平均分配的，如果平均分配额哈希槽中，某一个实例中 KEY，存储的数据比较大，造成某一个实例的内存过大，这时候可以通过cluster addslots手动调节哈希槽的分配。

当手动分配哈希槽时，需要把16384个槽都分配完，否则Redis集群无法正常工作。

客户端中的 KEY 如何找到对应的实例

在集群刚刚创建的时候，每个实例只知道自己被分配了哪些哈希槽，是不知道其他实例拥有的哈希槽信息的。但是，Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例，来完成哈希槽分配信息的扩散。

所以当客户端和集群实例连接后，就可以知道所有的哈希槽的映射，客户端会把哈希槽的映射保存在本地，这样如果客户端响应一个 KEY ，计算出哈希槽，然后就可以向对应的实例发送请求了。

哈希槽重新分配

数据在可能发生迁移，这时候哈希槽就会重新分配了

栗如：

1、集群中的实例，有增加或减少；

2、引入了负载均衡，需要重新分配哈希槽；

因为重新分配了哈希槽，所以原来的映射关系可能发生了改变，实例之间可以通过相互通知，快速的感知到映射关系的变化。但是，客户端无法主动感知这些变化，客户端对 KEY 的响应，可能依旧映射到了之前的实例节点，面对这种情况，如何处理呢？

1、如果数据已经迁移完了

Redis Cluster中提供重定向机制，如果一个实例接收到客户端的请求，但是对应的 KEY 已经转移到别的实例节点中了，这时候会计算出 KEY 当前所处实例的地址，然后返回给客户端，客户端拿到最新的实例地址，重新发送请求就可以了。

$ GET hello
(error) MOVED 12320 172.168.56.111:6379

2、数据迁移了一半

如果在迁移的过程中，只迁移了一半的数据，这时候服务器端就会返回 ASK 告知客户端

GET hello
(error) ASK 1332 012320 172.168.56.111:6379

ASK 就表示当前正在迁移中，客户端需要访问数据，就还需要向返回的地址信息，发送一条 ASKING 命令，让这个实例允许客户端的访问请求，然后客户端再发送具体的业务操作命令。

避免 Hot Key

Hot Key就是采用切片集群部署的 Redis ,出现的集群访问倾斜。

切片集群中的 Key 最终会存储到集群中的一个固定的 Redis 实例中。某一个 Key 在一段时间内访问远高于其它的 Key,也就是该 Key 对应的 Redis 实例,会收到过大的流量请求，该实例容易出现过载和卡顿现象，甚至还会被打挂掉。

常见引发热点 Key 的情况：

1、新闻中的热点事件；

2、秒杀活动中的，性价比高的商品；

如何发现 Hot Key

• 1、提现预判；

根据业务经验进行提前预判；

• 2、在客户端进行收集；

通过在客户端增加命令的采集，来统计发现热点 Key;

• 3、使用 Redis 自带的命令排查；

使用monitor命令统计热点key（不推荐，高并发条件下会有造成redis 内存爆掉的隐患）；

hotkeys参数，redis 4.0.3提供了redis-cli的热点key发现功能，执行redis-cli时加上–hotkeys选项即可。但是该参数在执行的时候，如果key比较多，执行起来比较慢。

• 4、在Proxy层做收集

如果集群架构引入了 proxy，可以在 proxy 中做统计

• 5、自己抓包评估

Redis客户端使用TCP协议与服务端进行交互，通信协议采用的是RESP。自己写程序监听端口，按照RESP协议规则解析数据，进行分析。缺点就是开发成本高，维护困难，有丢包可能性。

Hot Key 如何解决

知道了Hot Key如何来应对呢

• 1、对 Key 进行分散处理；

举个栗子

有一个热 Key 名字为Hot-key-test,可以将其分散为Hot-key-test1，Hot-key-test2...然后将这些 Key 分散到多个实例节点中，当客户端进行访问的时候，随机一个下标的 Key 进行访问，这样就能将流量分散到不同的实例中了，避免了一个缓存节点的过载。

一般来讲，可以通过添加后缀或者前缀，把一个 hotkey 的数量变成 redis 实例个数 N 的倍数 M，从而由访问一个redis key变成访问N * M个redis key。 N*M个redis key经过分片分布到不同的实例上，将访问量均摊到所有实例。

const M = N * 2
//生成随机数
random = GenRandom(0, M)
//构造备份新key
bakHotKey = hotKey + “_” + random
data = redis.GET(bakHotKey)
if data == NULL {
    data = GetFromDB()
    redis.SET(bakHotKey, expireTime + GenRandom(0,5))
}

• 2、使用本地缓存;

业务端还可以使用本地缓存，将这些热 key 记录在本地缓存，来减少对远程缓存的冲击。

避免 Big Key

什么是 Big Key：我们将含有较大数据或含有大量成员、列表数的Key称之为大Key。

• 一个STRING类型的Key，它的值为5MB（数据过大）

• 一个LIST类型的Key，它的列表数量为20000个（列表数量过多）

• 一个ZSET类型的Key，它的成员数量为10000个（成员数量过多）

• 一个HASH格式的Key，它的成员数量虽然只有1000个但这些成员的value总大小为100MB（成员体积过大）

Big Key 存在问题

• 内存空间不均匀：如果采用切片集群的部署方案，容易造成某些实例节点的内存分配不均匀；

• 造成网络拥塞：读取 bigkey 意味着需要消耗更多的网络流量，可能会对 Redis 服务器造成影响；

• 过期删除：big key 不单读写慢，删除也慢，删除过期 big key 也比较耗时；

• 迁移困难：由于数据庞大，备份和还原也容易造成阻塞，操作失败；

如何发现 Big Key

• 使用 redis-cli 客户端的命令 --bigkeys;

• 生成 rdb 文件，离线分析 rdb 文件。比如：redis-rdb-cli，rdbtools;

• 通过 scan 命令，对扫描出来的key进行类型判断，例如：string长度大于10K，list长度大于10240认为是big bigkeys;

Big Key 如何避免

对于Big Key可以从以下两个方面进行处理

• 合理优化数据结构：

1、对较大的数据进行压缩处理；

2、拆分集合：将大的集合拆分成小集合（如以时间进行分片）或者单个的数据。

• 选择其他的技术来存储 big key：

使用其他的存储形式，考虑使用 cdn 或者文档性数据库 MongoDB。

Big Key 如何删除

直接使用 DEL 命令会发生什么？危险：同步删除 bigkey 会阻塞 Redis 其他命令，造成 Redis 阻塞。

推荐使用 UNLINK 命令，异步删除 bigkey，不影响主线程执行其他命令。

在业务的低峰期使用 scan 命令查找 big key，对于类型为集合的key，可以使用脚本逐一删除里面的元素。

参考

【Redis核心技术与实战】https://time.geekbang.org/column/intro/100056701
【Redis设计与实现】https://book.douban.com/subject/25900156/
【估算两台服务器同时故障的概率】https://disksing.com/failure-probability-analysis/
【Redis中哨兵选举算法】https://blog.csdn.net/weixin_44324174/article/details/108939199
【如何处理redis集群中hot key和big key】https://juejin.cn/post/6844903743083773959
【谈谈redis的热key问题如何解决】https://www.cnblogs.com/rjzheng/p/10874537.html
【Redis 中常见的集群部署方案】https://boilingfrog.github.io/2022/02/20/redis中常见的集群部署方案/#主从集群模式
【Redis学习笔记】https://github.com/boilingfrog/Go-POINT/tree/master/redis