前言

Redis 作为最罕用的 key-value 服务，始终为咱们带来了高性能的保障。但程序嘛，总不可能始终运行上来，而咱们所要做的就是将这些危险降到最低。

所以，高可用也是 Redis 必然要思考的了，而随着 Redis 的宽泛应用，市面上也呈现了有很多高可用计划。明天，就来好好意识下这些计划，或者也能够为咱们本人的程序带来灵感。

高可用机制

Redis 的高可用从总体上来讲是通过 冗余 + 故障转移 来实现的，而对于冗余和故障转移又能够细化为：全副冗余或局部冗余；手动转移或主动转移。

全副冗余 + 手动转移的计划就是咱们最相熟的 主从模式 了；当手动转移变为主动转移时即 哨兵模式 。最初局部冗余 + 主动转移则是 集群模式。

因为 Redis 不像 mysql，在数据的完整性、一致性上是没有比拟好的保障的，所以当咱们在应用高可用计划时，对数据的一致性就冀望不了那么高了，这是须要提前留神的。

主从模式

主从模式在高可用计划中是最罕用的一种。往往咱们会在不同的机器上部署着同一 Redis 程序。在这多台机器里，咱们会抉择一个节点作为主节点，它负责数据的写入。其余节点作为从节点，定时的和主节点同步数据。一旦主节点不能应用了，那么就能够在从节点中筛选一个作为主节点，从新上岗服务。

主从模式往往还能进行读写拆散，将读取数据的压力扩散到多个从节点上。

在 Redis 进行主从数据同步时，会执行 bgsave 命令以生成 RDB 文件，同时会在缓冲区记录增量的命令。

当 Redis 将 RDB 文件同步给 Slave 后，会再次的将 缓冲区 的增量命令发送给从节点，从节点接管到这些数据后，就能够复原到内存里了。

从节点除了复原数据外，它还保护了一个复制偏移量，示意主节点向从节点传递命令的字节总数。这个复制偏移量会定时同步给主节点。

而主节点也有属于本人的一个写入偏移量，有了这 2 个参数后，主节点就晓得要进行局部复制还是要全量复制了。

主从模式在呈现故障时，须要人为进行干涉，而且从节点一多，主节点的同步压力就会很大了。

哨兵模式

下面的主从模式须要人工的进行故障节点切换，这种形式对于谋求完满的程序员来说，必定是不够的。所以有了主动切换的哨兵模式。

哨兵模式次要实现了上面几个性能：

• 监控：一直的检测主从节点是否能失常工作。
• 主动转移故障：当某个 master 不能失常工作时，Sentinel 会启动一个故障转移过程，将其中的一个正本晋升为 master，并告诉其余从节点对应新的 master 相干信息。
• 告诉：当某个节点出问题时，会告知所有节点。如果是新的主节点被选举进去，还会告知已连贯过去的客户端程序对于主节点新的地址。

在哨兵模式中，会有一个或多个哨兵程序，对以后的 Redis 集群进行监控。哨兵服务之间通过 gossip 协定 进行通信。当须要进行故障转移时，会通过选举算法，选出一个 leader 来主导过程。

而这也意味着，Sentinel 程序不能选举出 leader 的话，则不能继续执行后续动作了。包含客户端的申请，也会被阻塞住。

集群

主从模式和哨兵模式都会在多台机器中存储着同一份数据，这样对于内存的利用率并不高。如果可能将数据扩散到各个节点上，同时配上主从模式，那么就能高效应用内存了。集群就是这么个机制。

Redis 的集群采纳了哈希槽的概念，总共会有 16384 个哈希槽。这些哈希槽会被调配到各个节点上，比方：

• 节点 1 调配了 0 至 5500 的哈希槽。
• 节点 2 调配了 5501 至 11000 的哈希槽。
• 节点 3 调配了 11001 至 16384 的哈希槽。

当有 key 过去时，Redis 会对其进行 CRC16(key) % 16384 的运算，看以后的 key 要扩散到哪个哈希槽上，再依据以后的哈希槽定位到对应的节点上。这样就实现了一次 key-value 的存储了。

读取也是按这规定来，不同的是，如果运算后果所对应的节点不在以后节点上，则会转发给对应的节点去解决。

当有节点进行新增或删除时，会从新划分这些哈希槽，当然，影响的只会是四周节点，不会造成整个集群不可用。

在这些节点背地还有属于它们的从节点，一旦主节点不可用，那么这些从节点就会被启用，以保证系统的失常运行。

总结

从主从到哨兵再到集群，它们的施行难度是从易到难。个别对于大多数我的项目来讲，主从模式就足够应酬了。如果并发量比拟高，数据量也很大，那再来思考集群。毕竟，我的项目架构是在一直演变的，往往有了具体的应用场景，好的计划能力施展出对应的价值。

感兴趣的敌人能够搜一搜公众号「阅新技术」，关注更多的推送文章。
能够的话，就顺便点个赞、留个言、分享下，感激各位反对！
阅新技术，浏览更多的新常识。