您现在的位置是：网站首页> 编程资料编程资料
Redis中常见的几种集群部署方案_Redis_
2023-05-27
493人已围观
简介 Redis中常见的几种集群部署方案_Redis_
前言
这里来了解一下，Redis 中常见的集群方案
几种常用的集群方案
- 主从集群模式
- 哨兵机制
- 切片集群(分片集群)
主从集群模式
主从集群，主从库之间采用的是读写分离
- 主库：所有的写操作都在读库发生，然后主库同步数据到从库，同时也可以进行读操作；
- 从库：只负责读操作；
主库需要复制数据到从库，主从双方的数据库需要保存相同的数据，将这种情况称为"数据库状态一致"
来看下如何同步之前先来了解下几个概念
1、服务器的运行ID(run ID)：每个 Redis 服务器在运行期间都有自己的run ID，run ID在服务器启动的时候自动生成。
从服务器会记录主服务器的run ID，这样如果发生断网重连，就能判断新连接上的主服务器是不是上次的那一个，这样来决定是否进行数据部分重传还是完整重新同步。
2、复制偏移量 offset：主服务器和从服务器都会维护一个复制偏移量
主服务器每次向从服务器中传递 N 个字节的时候，会将自己的复制偏移量加上 N。
从服务器中收到主服务器的 N 个字节的数据，就会将自己额复制偏移量加上 N。
通过主从服务器的偏移量对比可以很清楚的知道主从服务器的数据是否处于一致。
如果不一致就需要进行增量同步了，具体参加下文的增量同步
全量同步
从服务器首次加入主服务器中发生的是全量同步
如何进行第一次同步？
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这个缓冲区。
这里可能有点疑惑，已经有了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核心技术与实战的一张图片
刚开始主服务器的 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，然后发送到从服务器中。
repl_backlog_buffer中的缓冲空间要设置的大一点，如果从库读的过慢，因为是环形缓冲区，可能出现命令覆盖的情况，如果出现命令被覆盖了，从库的增量同步就无法进行了，这时候会进行一次全量的复制。
缓冲空间的计算公式是：缓冲空间大小 = 主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小。在实际应用中，考虑到可能存在一些突发的请求压力，我们通常需要把这个缓冲空间扩大一倍，即 repl_backlog_size = 缓冲空间大小 * 2，这也就是 repl_backlog_size 的最终值。
哨兵机制
对于主从集群模式，如果从库发生了故障，还有主库和其它的从库可以接收请求，但是如果主库挂了，就不能进行正常的数据写入，同时数据同步也不能正常的进行了，当然这种情况，我们需要想办法避免，于是就引入了下面的哨兵机制。
什么是哨兵机制
sentinel(哨兵机制)：是 Redis 中集群的高可用方式，哨兵节点是特殊的 Redis 服务，不提供读写，主要来监控 Redis 中的实例节点，如果监控服务的主服务器下线了，会从所属的从服务器中重新选出一个主服务器，代替原来的主服务器提供服务。
核心功能就是:监控，选主，通知。
监控：哨兵机制，会周期性的给所有主服务器发出 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。
- 横向扩展：通过添加或删除节点组（分片）来更改复制组中的节点组（分片）数量。
简单点讲就是：垂直扩容就是增加自身的容量，横向扩容就是加机器。
缺点对比
纵向扩容：
1、如果一味的增加自身的容量，意味着自身存储的数据将会越来越大，过大的数据，持久化时间将会变得很长，影响自身的响应速度；
2、同样堆硬件总归是有上线，达到一定量之后，还是要考虑进行横向扩容；
横向扩容：
横向扩容要面临的问题，如果发生了分片的扩容，就需要考虑数据的迁移，同时数据切片后，在多个实例之间如何分布？，客户端如何知道访问的数据在哪个实例中。。。
虽然有这些问题的存在，好在已经有一些成熟的方案来处理横向扩容所遇到的问题了
官方的集群解决方案就是Redis Cluster；社区的解决方案有 Codis 和 Twemproxy，Codis 是由我国的豌豆荚团队开源的，Twemproxy 是 Twitter 团队的开源的。
这里主要看下Redis Cluster是如何进行处理的
Redis Cluster方案
1、Redis Cluster方案采用哈希槽来处理 KEY 在不同实例中的分布，一个切片集群共有16384个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的key，被映射到一个哈希槽中。
2、一个 KEY ，首先会根据CRC16算法计
