Linux-redis哨兵(sentinel)

redis 集群介绍

主从架构无法实现master和slave角色的自动切换，即当master出现redis服务异常、主机断电、磁盘损 坏等问题导致master无法使用，而redis主从复制无法实现自动的故障转移(将slave 自动提升为新 master)，需要手动修改环境配置,才能切换到slave redis服务器，另外也无法横向扩展Redis服务的并行 写入性能，当单台Redis服务器性能无法满足业务写入需求的时候,也需要解决以上的两个核心问题， 即：

1.master和slave角色的无缝切换，让业务无感知从而不影响业务使用

2.可横向动态扩展Redis服务 器，从而实现多台服务器并行写入以实现更高并发的目的。

Redis 集群实现方式：

 客户端分片: 由应用决定将不同的KEY发送到不同的Redis服务器

代理分片: 由代理决定将不同的KEY发送到不同的Redis服务器,代理程序如:codis,twemproxy等

Redis Cluster

 

哨兵 (Sentinel) 工作原理

sentinel 架构和故障转移

• Sentinel 进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时 候，可以实现Master和Slave服务器的切换，保证系统的高可用，此功能在redis2.6+的版本已引用， Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis的2.8版本的以后版 本
• 哨兵(Sentinel) 是一个分布式系统，可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言 协议(gossip protocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master
• 每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活” 着，如果发现对方在指定配置时间(此项可配置)内未得到回应，则暂时认为对方已离线，也就是所谓的” 主观认为宕机” (主观:是每个成员都具有的独自的而且可能相同也可能不同的意识)，英文名称： Subjective Down，简称SDOWN
• 有主观宕机，对应的有客观宕机。当“哨兵群”中的多数Sentinel进程在对Master主服务器做出SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线 判断，这种方式就是“客观宕机”(客观:是不依赖于某种意识而已经实际存在的一切事物)，英文名称是： Objectively Down， 简称 ODOWN
• 通过一定的vote算法，从剩下的slave从服务器节点中，选一台提升为Master服务器节点，然后自动修 改相关配置，并开启故障转移（failover）
• Sentinel 机制可以解决master和slave角色的自动切换问题，但单个 Master 的性能瓶颈问题无法解决, 类似于MySQL中的MHA功能
• Redis Sentinel中的Sentinel节点个数应该为大于等于3且最好为奇数
• 客户端初始化时连接的是Sentinel节点集合，不再是具体的Redis节点，但Sentinel只是配置中心不是代 理。
• Redis Sentinel 节点与普通redis 没有区别,要实现读写分离依赖于客户端程序
• redis 3.0 之前版本中,生产环境一般使用哨兵模式,但3.0后推出redis cluster功能后,可以支持更大规模的 生产环境

sentinel中的三个定时任务

• 每10秒每个sentinel对master和slave执行info
  • 发现slave节点
  • 确认主从关系
• 每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
  • 通过sentinel__:hello频道交互
  • 交互对节点的“看法”和自身信息
• 每1秒每个sentinel对其他sentinel和redis执行ping

 Redis Cluster

Redis Cluster 工作原理

在哨兵sentinel机制中，可以解决redis高可用问题，即当master故障后可以自动将slave提升为 master，从而可以保证redis服务的正常使用，但是无法解决redis单机写入的瓶颈问题，即单机redis写 入性能受限于单机的内存大小、并发数量、网卡速率等因素。

早期Redis 分布式集群部署方案：

1. 客户端分区：由客户端程序决定key写分配和写入的redis node，但是需要客户端自己处理写入分 配、高可用管理和故障转移等
2. 代理方案：基于三方软件实现redis proxy，客户端先连接之代理层，由代理层实现key的写入分 配，对客户端来说是有比较简单，但是对于集群管节点增减相对比较麻烦，而且代理本身也是单点 和性能瓶颈。

redis 3.0版本之后推出了无中心架构的redis cluster机制，在无中心的redis集群当中，其每个节点保存 当前节点数据和整个集群状态,每个节点都和其他所有节点连接

Redis Cluster特点如下：

• 所有Redis节点使用(PING机制)互联
• 集群中某个节点的是否失效，是由整个集群中超过半数的节点监测都失效，才能算真正的失效
• 客户端不需要proxy即可直接连接redis，应用程序中需要配置有全部的redis服务器IP
• redis cluster把所有的redis node 平均映射到 0-16383个槽位(slot)上，读写需要到指定的redis node上进行操作，因此有多少个redis node相当于redis 并发扩展了多少倍，每个redis node 承担 16384/N个槽位
• Redis cluster预先分配16384个(slot)槽位，当需要在redis集群中写入一个key -value的时候，会使 用CRC16(key) mod 16384之后的值，决定将key写入值哪一个槽位从而决定写入哪一个Redis节点 上，从而有效解决单机瓶颈。

Redis cluster 基本架构

假如三个主节点分别是：A, B, C 三个节点，采用哈希槽 (hash slot)的方式来分配16384个slot 的话

它们三个节点分别承担的slot 区间可以是：

节点A覆盖 0－5460
节点B覆盖 5461－10922
节点C覆盖 10923－16383