redis的三种集群方式

redis有三种集群方式：主从复制，哨兵模式和集群。

1.主从复制

主从复制原理：

• 从服务器链接主服务器，发送SYNC命令； 
• 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的全部写命令； 
• 主服务器BGSAVE执行完后，向全部从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 
• 从服务器收到快照文件后丢弃全部旧数据，载入收到的快照； 
• 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 
• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）
• 主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操做）

主从复制优缺点：

优势：

• 支持主从复制，主机会自动将数据同步到从机，能够进行读写分离
• 为了分载Master的读操做压力，Slave服务器能够为客户端提供只读操做的服务，写服务仍然必须由Master来完成
• Slave一样能够接受其它Slaves的链接和同步请求，这样能够有效的分载Master的同步压力。
• Master Server是以非阻塞的方式为Slaves提供服务。因此在Master-Slave同步期间，客户端仍然能够提交查询或修改请求。
• Slave Server一样是以非阻塞的方式完成数据同步。在同步期间，若是有客户端提交查询请求，Redis则返回同步以前的数据

缺点：

• Redis不具有自动容错和恢复功能，主机从机的宕机都会致使前端部分读写请求失败，须要等待机器重启或者手动切换前端的IP才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，下降了系统的可用性。
• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

2.哨兵模式

当主服务器中断服务后，能够将一个从服务器升级为主服务器，以便继续提供服务，可是这个过程须要人工手动来操做。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的做用就是监控Redis系统的运行情况。它的功能包括如下两个。

    （1）监控主服务器和从服务器是否正常运行。 
    （2）主服务器出现故障时自动将从服务器转换为主服务器。

哨兵的工做方式：

• 每一个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其余Sentinel（哨兵）进程发送一个 PING 命令。
• 若是一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
• 若是一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的全部 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
• 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）
• 在通常状况下， 每一个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的全部Master主服务器、Slave从服务器发送 INFO 命令。
• 当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的全部 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改成每秒一次。
• 若没有足够数量的 Sentinel（哨兵）进程赞成 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器从新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

 哨兵模式的优缺点

优势：

• 哨兵模式是基于主从模式的，全部主从的优势，哨兵模式都具备。
• 主从能够自动切换，系统更健壮，可用性更高。

缺点：

• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

3.Redis-Cluster集群

redis的哨兵模式基本已经能够实现高可用，读写分离 ，可是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，因此在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不一样的内容。

 Redis-Cluster采用无中心结构,它的特色以下：

• 全部的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。

• 节点的fail是经过集群中超过半数的节点检测失效时才生效。

• 客户端与redis节点直连,不须要中间代理层.客户端不须要链接集群全部节点,链接集群中任何一个可用节点便可。

工做方式：

在redis的每个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，能够理解为是一个集群管理的插件。当咱们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，而后把结果对 16384 求余数，这样每一个 key 都会对应一个编号在 0-16383 之间的哈希槽，经过这个值，去找到对应的插槽所对应的节点，而后直接自动跳转到这个对应的节点上进行存取操做。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，若是半数以上的主节点与A通讯超时，那么认为主节点A宕机了。若是主节点A和它的从节点A1都宕机了，那么该集群就没法再提供服务了。

 

Redis集群设计包括2部分：哈希Slot和节点主从，本篇博文经过3张图来搞明白Redis的集群设计。

 

节点主从：

主从设计不算什么新鲜玩意，在数据库中咱们也常常用主历来作读写分离，直接上图：

 

 

图上能看获得的信息：

1， 只有1个Master，能够有N个slaver，并且Slaver也能够有本身的Slaver，因为这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。

2， 读写分离，Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，因此Slaver的扩容只能提升读效率不能提升写效率。

3， Slaver先将Master那边获取到的信息压入磁盘，再load进内存，client端是从内存中读取信息的，因此Redis是内存数据库。

当一个新的Slaver加入到这个集群时，会主动找Master来拜码头，Master发现新的小弟后将全量数据发送给新的Slaver，数据量越大性能消耗也就越大，因此尽可能避免在运行时作Slaver的扩容。

简单总结下主从模式的设计：

优势：读写分离，经过增长Slaver能够提升并发读的能力。

缺点：Master写能力是瓶颈。

          虽然理论上对Slaver没有限制可是维护Slaver开销总将会变成瓶颈。

          Master的Disk大小也将会成为整个Redis集群存储容量的瓶颈。

 

 

哈希Slot：

这个艺名看起来很文艺，但也不是什么新技术，他的真名就叫分表分库，再上一个图：

 

 

图上能看到的信息：

1， 对象保存到Redis以前先通过CRC16哈希到一个指定的Node上，例如Object4最终Hash到了Node1上。

2， 每一个Node被平均分配了一个Slot段，对应着0-16384，Slot不能重复也不能缺失，不然会致使对象重复存储或没法存储。

3， Node之间也互相监听，一旦有Node退出或者加入，会按照Slot为单位作数据的迁移。例如Node1若是掉线了，0-5640这些Slot将会平均分摊到Node2和Node3上,因为Node2和Node3自己维护的Slot还会在本身身上不会被从新分配，因此迁移过程当中不会影响到5641-16384Slot段的使用。

简单总结下哈希Slot的优缺点：

缺点：每一个Node承担着互相监听、高并发数据写入、高并发数据读出，工做任务繁重

优势：将Redis的写操做分摊到了多个节点上，提升写的并发能力，扩容简单。

 

双剑合并：

看到这里你们也就发现了，主从和哈希的设计优缺点正好是相互弥补的，将图一每一套主从对应到图二中的每个Node，就是Redis集群的终极形态，先Hash分逻辑节点，而后每一个逻辑节点内部是主从，如图：

 

 

想扩展并发读就添加Slaver，想扩展并发写就添加Master，想扩容也就是添加Master，任何一个Slaver或者几个Master挂了都不会是灾难性的故障。
---------------------
版权声明：本文为CSDN博主「牛麦康纳」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处连接及本声明。
原文连接：https://blog.csdn.net/yejingtao703/article/details/78484151

原文连接 http://www.javashuo.com/article/p-wscvvdqc-bk.html