最近离职后还没开始找工作，在找工作前去学习一下Redis高可用方案。
目录
- Redis高可用
- 高可用的概念
- 实现方式
- 持久化
- 主从复制
- 简单结构
- 优化结构
- 优缺点
- 哨兵模式（Sentinel）
- 哨兵进程的作用
- 自动故障迁移(Automatic failover)
- 优缺点
- 集群
- 优缺点
Redis高可用
高可用的概念
通过尽量缩短日常维护操作和突发的系统崩溃所导致的停机时间，以提高系统和应用的可用性。
实现方式
Redis高可用的实现方式有：
- 持久化
- 主从复制
- 哨兵
- 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查询
