Redis深度解析：实现高可用性的策略

Redis属于纯内存数据库，那么高性能就是最重要的优点，最常见的使用场景是用作缓存。

一套成熟的缓存系统，除了高性能，也还有其它的要求，比如数据安全性、数据存储的规模、高并发读写等，Redis在这些要求下，也同样具备高可用的解决方案。

• 主从复制：

主从复制是Redis高可用的基础，下面要讲的哨兵和集群都是在主从复制的基础上实现高可用的。主从复制主要实现了数据多机备份，读数据的负载均衡和简单的故障恢复。优点是部署简单，缺点是故障恢复无法自动化，需要人工介入；写数据无法负载均衡；数据存储规模受到单机容量的限制。

• 哨兵：

在主从复制的基础上，哨兵实现了故障自动化恢复。缺点是上文提到的主从复制的另外两个缺点哨兵模式依然存在，同时呢哨兵只能够在Master节点出现故障的时候，从Slave节点自动选举出一个作为主节点，从节点发生故障时候，哨兵就无能为力，读负载均衡情况下，可能会导致读服务不可用。

哨兵如何发现故障呢？每个哨兵节点会定时向主节点、从节点和哨兵节点发送ping命令做心跳检测，当主节点超时或者回复错误命令时，此哨兵就认为主节点出现故障了，当半数以上哨兵节点认为这个主节点有故障了，那么这个主节点就主观下线了，哨兵会启动选举，重新确认主节点，原来的主节点就算恢复了，也只能是从节点了。

因为需要Raft算法的选举机制，所以哨兵的数量必须是奇数，至少3个。哨兵其实也是redis节点，由于其的存在，也会有一定的资源浪费。

• 集群：

Redis Cluster，3.0版本开始引入的分布式存储方案。整个集群由多个节点组成，数据分散的分布在这些节点中，只有主节点负责数据的读写，从节点只负责主节点数据和状态信息的复制。

那么数据是如何 分散存储的呢？集群引入哈希槽的概念，共有16384个哈希槽，每个主节点负责一部分，数据通过CRC16算法校验后决定存储在哪个哈希槽上，也就决定了放在哪个主节点上。

一致性哈希算法的引入解决了增加或减少节点时候，数据的影响面较小；虚拟节点的引入避免了数据集中在某一个节点上，使其分布均衡。