redis高可用

Redis 实现高可用主要有三种方式：主从复制、哨兵模式，以及 Redis 集群，参考：https://mp.weixin.qq.com/s/ft0oCq_FMO71lG6IVHywdw

1）主从复制

详见主从复制的文章

 

2）哨兵模式

使用 Redis 主从服务的时候，会有一个问题，就是当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复，为了解决这个问题，Redis 增加了哨兵模式，可以进行存活检测，故障转移，在master节点故障后能自动将slave节点提升成master节点，哨兵模式的作用：

1、监控：不断检查主服务器和从服务器是否正常运行。

2、通知：当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本向管理员或者其他应用程序发出通知

3、自动故障转移 ：当主节点不能正常工作时，Sentinel 会开始一次自动的故障转移操作，可以在master节点故障后能自动将salve节点提升成master节点，并且将其他的slave节点指向新的主节点，这样人工干预就可以免了。

哨兵模式工作流程：

1、每个Sentinel节点都需要定期执行以下任务：每个Sentinel以每秒一次的频率，向它所知的主服务器、从服务器以及其他的Sentinel实例发送一个PING命令

2、如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds所指定的值，那么这个实例会被Sentinel标记为主观下线

3、如果一个主服务器被标记为主观下线，并且有足够数量的Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线 (只有主节点才有客观下线，是因为有可能「主节点」其实并没有故障，可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的PING命令。通过多个哨兵节点一起判断，就可以就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低)

4、Sentinel和其他Sentinel协商客观下线的主节点的状态，如果处于SDOWN状态，则投票自动选出新的主节点

5、如果之后其他Sentinel不再报告master已下线， 那么客观下线状态就会被移除。当主服务器重新向Sentinel的PING命令返回有效回复时，主服务器的主观下线状态就会被移除

哨兵模式缺点：详见下文redis集群描述。主从模式或哨兵模式每个节点存储的数据都是全量的数据，数据量过大时，就需要对存储的数据进行分片后存储到多个redis实例上。此时就要用到Redis 集群技术。

哨兵模式下选举策略，怎么决定哪个slave选为master？

    哨兵从其他slave选举时，先进行过滤，将下线断线节点过滤掉，还会评估过往的网络连接情况。然后就是三个维度的评估，
1）根据slave优先级判断，配置文件中可以给不同slave配置优先级，优先级高的优先成为master。
2）选择数据偏移量差距最小slave，即比较slave和master的复制进度差距，避免slave成为master，master成为slave后，产生全量复制丢失过多数据
3）毕竟slave的runid，如果前两个指标都一样，runid越小说明创建时间越早，优先选为master

  

3）redis集群

Redis Cluster 是一种分布式去中心化的运行模式，是在 Redis 3.0 版本中推出的 Redis 集群方案，它将数据分布在不同的服务器上，每台redis节点存储不同数据，以此来降低系统对单主节点的依赖，从而提高 Redis 服务的读写性能。集群模式有多个分片，每个分片都是一个主机和多个从机组成，分片之间是互相平行的关系。每一个master节点负责维护一部分槽，以及槽所映射的键值数据；集群中每个节点会把自己的哈希槽广播给集群中其他节点，所以集群中每个节点都保存哈希槽与节点之间的映射关系，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。当客户端连接任何一个节点，节点就将哈希槽与节点的映射关系响应给客户端，客户端就会将哈希槽与实例映射信息缓存在本地。当客户端请求时，会计算出键所对应的哈希槽，再通过本地缓存的哈希槽实例映射信息定位到数据所在实例上，再将请求发送给对应的实例

问：使用哨兵模式在数据上有副本数据做保证，在可用性上又有哨兵监控，一旦master宕机会选举slave节点为master节点，这种已经满足了我们的生产环境需要，那为什么还需要使用集群模式呢 ？
答：1）哨兵模式下如果数据量太大，主从同步会严重影响master性能。2）哨兵模式每个从机和主机的耦合度很高，从master宕机到把slave选举到master期间，redis会开启保护机制，禁止写操作。3）哨兵模式可以通过增加slave节点扩展并发读能力，但始终只有一个Redis主机来接收和处理写请求，写操作和存储能力还是受单机瓶颈影响，为了扩展写能力和存储能力，就需要引入集群模式。
问：集群中那么多 Master 节点，Redis Cluster在存储的时候如何确定选择哪个节点呢
答：Redis Cluster 采用的是类一致性哈希算法实现节点选择的，Redis Cluster 将自己分成了 16384 个 Slot（槽位），假如你有三个master节点 ABC，则每个Redis节点负责处理一部分槽位，至于怎么瓜分，可以直接均分，也可以手动设置每个Redis实例的哈希槽，全由我们来决定。为什么是16384个哈希槽：16384个既能让Redis实例分配到的数据相对均匀，又不会影响Redis实例之间交互槽信息产生严重的网络性能开销问题

 　　

每当客户端有数据写入，客户端会把它的key按照CRC16算法计算一个16bit的值，再用16bit值对16384取模，得到0~16383范围内的模数，根据取模结果确定映射到哪个节点。 　　
　　要想组成分片集群，那就需要对不同的key进行路由，现在一般的路由方案有两种：客户端路由和服务端路由。客户端路由的代表（Redis Cluster），服务端路由的代表（Codis）。Redis Cluster的路由是在客户端做的。客户端路由的大致流程如上所述。服务端路由的大致原理：
　　服务端路由一般指的就是，有个代理层专门对接客户端的请求，然后再转发到Redis集群进行处理。现在比较流行的是Codis，它与Redis Cluster最大的区别就是，Redis Cluster是客户端直连Redis服务端的，而Codis则客户端直连Proxy，再由Proxy进行分发到不同的Redis实例进行处理。在Codis中Key路由的方案跟Redis Cluster很类似，Codis初始化出1024个哈希槽，然后分配到不同的Redis服务器中。哈希槽与Redis实例的映射关系由Zookeeper进行存储和管理，Proxy会通过Codis DashBoard得到最新的映射关系，并缓存在本地上。扩容Codis Redis实例大概的过程就是：1.「原实例」某一个Solt的部分数据发送给「目标实例」。2.「目标实例」收到数据后，给「原实例」返回ack。3.「原实例」收到ack之后，在本地删除掉刚刚给「目标实例」的数据。4.不断循环1、2、3步骤，直至整个solt迁移完毕

     集群模式如何实现故障转移？Redis集群每个节点采用都广播自己的状态，比如一个节点发现某个节点失联了，它会将这条信息向整个集群广播，其它节点也就可以收到这个节点失联信息。redis集群对该失联节点进行主从切换

    哨兵模式和cluster模式的区别？

1、哨兵模式是基于主从复制实现的，可以实现读写分离。cluster中的slave节点只是冷备作用，读写都打到master上，slave只有在master宕机后才会工作

2、哨兵模式无法在线扩容，服务瓶颈受限于单台机器，cluster模式可以在线扩容，只需涉及slot数据迁移

3、哨兵模式是一主多从，cluster模式是多主多从机制

 

    redis重定向：

1）moved重定向：客户端向目标master发送获取key命令，如果该节点的slot中有这个key则直接返回key的value。如果key不在这个节点中，则节点会想客户端返回moved，客户端会更新本地映射的缓存，然后根据moved中的内容找到新的目标节点，再一次发送获取key的命令。

2）ask重定向：集群伸缩的时候，会导致key迁移。此时slot中部分key在本节点上，部分key在其他节点上。此时请求key则数据可能数据已经迁移到了其他节点，此时本节点会返回ack，客户端根据ack中的内容找到新的目标节点，再一次发送获取key的命令。