本文主要是介绍Redis三种集群模式，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

一.主从模式

Redis的主从模式指的就是主从复制。

优点:

①同一个Master可以同步多个Slaves。
Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。

②Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

③Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

④为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高。

Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作。
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离

缺点:

①Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

②网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦。Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

1.Redis如何实现主从模式？

Redis的从服务器在向主服务器发起同步时，一般会使用 SYNC 或 PSYNC 命令。

2.初次同步

当从服务器收到 SLAVEOF 命令后，会向其主服务器执行同步操作，进入主从复制流程。

3.SYNC 与 PSYNC的区别

SYNC
从服务器重新向主服务器发起 SYNC命令，主服务器将所有数据再次重新生成RDB快照发给从服务器开始同步

PSYNC
从服务器重新向主服务器发起 PSYNC命令。主服务器根据双方数据的偏差量判断是否是需要完整重同步还是仅将断线期间执行过的写命令发给从服务器。

明显可以发先PSYNC相比SYNC效率好很多，要知道同步所有数据是一个非常费资源(磁盘IO,网络)的操作，而如果只是因为短暂网络不稳定就同步所有资源是非常不值的。因此Redis在2.8版本后都开始使用PSYNC进行复制

二.Redis哨兵模式(Sentinel)

Redis主从模式虽然能做到很好的数据备份，但是他并不是高可用的。一旦主服务器点宕机后，只能通过人工去切换主服务器。因此Redis的哨兵模式也就是为了解决主从模式的高可用方案。

哨兵模式引入了一个Sentinel系统去监视主服务器及其所属的所有从服务器。一旦发现有主服务器宕机后，会自动选举其中的一个从服务器升级为新主服务器以达到故障转义的目的。

同样的Sentinel系统也需要达到高可用，所以一般也是集群，互相之间也会监控。而Sentinel其实本身也是一个以特殊模式允许Redis服务器。

实现原理

1.Sentinel与主从服务器建立连接

• Sentinel服务器启动之后便会创建于主服务器的命令连接，并订阅主服务器的**sentinel:hello频道以创建订阅连接**
• Sentinel默认会每10秒向主服务器发送 INFO 命令，主服务器则会返回主服务器本身的信息，以及其所有从服务器的信息。
• 根据返回的信息，Sentinel服务器如果发现有新的从服务器上线后也会像连接主服务器时一样，向从服务器同时创建命令连接与订阅连接。

2.判定主服务器是否下线

每一个Sentinel服务器每秒会向其连接的所有实例包括主服务器，从服务器，其他Sentinel服务器)发送 PING命令，根据是否回复 PONG 命令来判断实例是否下线。

①判定主观下线

如果实例在收到 PING命令的down-after-milliseconds毫秒内(根据配置)，未有有效回复。则该实例将会被发起 PING命令的Sentinel认定为主观下线。

②判定客观下线

当一台主服务器没某个Sentinel服务器判定为客观下线时，为了确保该主服务器是真的下线，Sentinel会向Sentinel集群中的其他的服务器确认，如果判定主服务器下线的Sentinel服务器达到一定数量时(一般是N/2+1)，那么该主服务器将会被判定为客观下线，需要进行故障转移。

3.选举领头Sentinel

当有主服务器被判定客观下线后，Sentinel集群会选举出一个领头Sentinel服务器来对下线的主服务器进行故障转移操作。整个选举其实是基于RAFT一致性算法而实现的，大致的思路如下：

• 每个发现主服务器下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel。
• 接收到的Sentinel可以同意或者拒绝
• 如果有一个Sentinel得到了半数以上Sentinel的支持则在此次选举中成为领头Sentinel。
• 如果给定时间内没有选举出领头Sentinel，那么会再一段时间后重新开始选举，直到选举出领头Sentinel。

4.选举新的主服务器

领头服务器会从从服务中挑选出一个最合适的作为新的主服务器。挑选的规则是：

• 选择健康状态的从节点，排除掉断线的，最近没有回复过 INFO命令的从服务器。
• 选择优先级配置高的从服务器
• 选择复制偏移量大的服务器（表示数据最全）

挑选出新的主服务器后，领头服务器将会向新主服务器发送 SLAVEOF no one命令将他真正升级为主服务器，并且修改其他从服务器的复制目标，将旧的主服务器设为从服务器，以此来达到故障转移。

三.Redis Cluster

Redis哨兵模式实现了高可用，读写分离，但是其主节点仍然只有一个，即写入操作都是在主节点中，这也成为了性能的瓶颈。

因此Redis在3.0后加入了Cluster模式，它采用去无心节点方式实现，集群将会通过分片方式保存数据库中的键值对

1.节点

一个Redis集群中会由多个节点组成，每个节点都是互相连接的，会保存自己与其他节点的信息。节点之间通过gossip协议交换互相的状态，以及保新加入的节点信息。

2.数据的Sharding

Redis Cluster的整个数据库将会被分为16384个哈希槽，数据库中的每个键都属于这16384个槽中的其中一个，集群中的每个节点可以处0个或者最多16384个槽。也就是说Redis最多可以设置16384个节点,每个节点有一个槽,最少可以配置一个节点,这个节点有16384个槽.

redis cluster节点分配
现在我们是三个主节点分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以

是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：节点A覆盖()0－5460),节点B覆盖(5461－10922),节点C覆盖(10923－16383).

获取数据:
如果存入一个值，按照redis cluster哈希槽的算法： CRC16('key')384 = 6782。 那么就会把这个key 的存储分配到 B 上了。同样，当我连接(A,B,C)任何一个节点想获取'key'这个key时，也会这样的算法，然后内部跳转到B节点上获取数据

新增一个主节点:
新增一个节点D，redis cluster的这种做法是从各个节点的前面各拿取一部分slot到D上，我会在接下来的实践中实验。大致就会变成这样：节点A覆盖(1365-5460),节点B覆盖(6827-10922),节点C覆盖(12288-16383),节点D覆盖(0-1364,5461-6826,10923-12287)

同样删除一个节点也是类似，移动完成后就可以删除这个节点了

哈希槽相当于一个桶的概念,加入现在Redis有6000个键值对,三个节点,平均每个节点分为2000个键值对.

3.Redis Cluster的高可用

Redis的每个节点都可以分为主节点与对应从节点。主节点负责处理槽，从节点负责复制某个主节点，并在主节点下线时，代替下线的主节点。

4.何实现故障转移

其实与哨兵模式类似，Redis的每个节点都会定期向其他节点发送Ping消息，以此来检测对方是否在线。当一个节点检测到另一个节点下线后，会将其设置为疑似下线。如果一个机器中，有半数以上的节点将某个主节点设为疑似下线，则该节点将会被标记为已下线状态，并开始执行故障转移。

①通过raft算法从下线主节点的从节点中选出新的主节点

②被选中的从节点执行 SLAVEOF no one 命令，成为新的主节点

③新的主节点撤销掉已下线主节点的槽指派，并将这些槽指给自己

④新的主节点向集群中广播自己由从节点变为主节点

⑤新的主节点开始接受和负责自己处理槽的有关命令请求

这篇关于Redis三种集群模式的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！