Redis高可用

最近离职后还没开始找工作，在找工作前去学习一下Redis高可用方案。

Redis高可用

高可用的概念

通过尽量缩短日常维护操作和突发的系统崩溃所导致的停机时间，以提高系统和应用的可用性。

实现方式

Redis高可用的实现方式有：

1. 持久化
2. 主从复制
3. 哨兵
4. Cluster集群

持久化

通过AOF和RDB实现持久化，服务器宕机后可以快速找回之前的数据，防止大量请求打入数据库，防止服务或系统宕机导致数据丢失。
具体看Redis入门（二）——持久化

主从复制

将一台Redis作为主节点（Master），将上面的数据复制到其他Redis，其他的Redis就是从节点（Slave）。

Master节点提供数据的事务性操作（增删改），Slave只提供读操作。

简单结构

将Slave都挂在Master节点上

优点：

Slave节点与master节点的数据延迟较小

缺点：

Slave节点较多时，Master同步一次数据较久

优化结构

为了提高Master同步数据的效率，只在Master下挂一个Slave节点，其他节点挂载到这个Slave节点上。
通过传递完成数据同步，减少Master性能消耗

优缺点

优点

• 实现读写分离，降低Master的读数据压力，提高系统性能
• 配置简单，容易搭建

缺点

• Master宕机时，无法选择哪台Slave作为新的Master节点，保证不了高可用
• 写压力都集中到Master节点上

哨兵模式（Sentinel）

基于主从复制，解决Master宕机时不知道选择哪台Slave作为新的Master节点。
对每个节点进行监控，Master宕机时通过投票机制选择新的Master节点，并将其他Slave节点连接到新的Master节点。

哨兵进程的作用

监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移(Automatic failover)

当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作：

• 将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；
• Client试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master

优缺点

优点

• 保证高可用

缺点

• 中心化集群实现方式，基于主从模式，切换节点时，会发生数据的丢失。
• 集群里所有节点保存的都是全量数据，浪费内存空间，没有真正实现分布式存储。数据量过大时，主从同步严重影响master的性能。
• 数据写的操作都集中在master上，仍然没有解决master写数据的压力。

集群

哨兵实现了高可用，但是每个节点存储的都是相同的内容，浪费内存。同时也没有解决master写数据的压力。

集群模式，能自动将数据进行分片，实现分布式储存，每个节点存储不同的数据。

架构如下：

优缺点

优点

• 无中心架构;
• 数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布;
• 可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除;
• 高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升;
• 降低运维成本，提高系统的扩展性和可用性。

缺点

• 节点会因为某些原因发生阻塞（阻塞时间大于 cluster-node-timeout）,被判断下线，这种failover是没有必要的
• 数据通过异步复制，不能保证数据一致性
• 多个业务使用同一个集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况
• 不支持多数据库空间，单机时可以选择16个数据库，集群只能选择一个数据库，即db0
• key批量操作限制，如mget、mset，目前只支持相同slot值的key执行批量操作，不同的slot不支持跨slot查询