Redis主要有三种部署形式来保证高可用：主从、哨兵、集群
一、主从
1.sync
Redis2.8之前的版本，主从间的数据同步主要使用sync命令，步骤如下：
①从节点向主节点发送sync(数据同步)命令。
②主节点接收同步命令后，会保存快照，创建一个RDB文件。
③当节点执行完保存快照后，会向从从节点发送RDB文件，从节点会接收并载入该文件。
④主节点将缓冲区的所有写命令发给从节点执行。
⑤以上处理结束，之后主节点每执行一个写命令，都会将它发送给从数据库，保持数据同步。
2.psync
Redis2.8版本之后，主要使用psync命令做数据同步，也是我们需要重点关注的。
sync命令只支持全量复制，psync命令支持全量复制和增量复制。一般来说，第一次建立主从连接进行全量复制，出现网络闪断或者其他异常之后重新连接进行的是增量复制。
sync命令需要三个组件来支持其完成数据同步：
- 主从节点各自的复制偏移量
- 主节点复制积压缓冲区
- 主节点运行ID
主从节点各自的复制偏移量
参与复制的主从节点都会维护自身的复制偏移量。
主节点在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在 info replication 中的 master_repl_offset 指标中。
从节点每秒钟上报自身的的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量。
从节点在接收到主节点发送的命令后，也会累加自身的偏移量，统计信息在 info replication 中。
通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。
主节点复制积压缓冲区
复制积压缓冲区是一个保存在主节点的一个固定长度的先进先出的队列。默认大小 1MB。
这个队列在 slave 连接时创建。这时主节点响应写命令时，不但会把命令发送给从节点，也会写入复制缓冲区。
作用就是用于部分复制和复制命令丢失的数据补救。
主节点运行 ID
每个 redis 启动的时候，都会生成一个 40 位的运行 ID。
运行 ID 的主要作用是用来识别 Redis 节点。如果使用 ip+port 的方式，那么如果主节点重启修改了 RDB/AOF 数据，从节点再基于偏移量进行复制将是不安全的。所以，当运行 id 变化后，从节点将进行全量复制。也就是说，redis 重启后，默认从节点会进行全量复制。
如何在重启时不改变运行 ID 呢？
可以通过 debug reload 命令重新加载 RDB 并保持运行 ID 不变。从而有效的避免不必要的全量复制。
这种方式会阻塞当前 Redis 节点主线程，因此对于大数据量的主节点或者无法容忍阻塞的节点，需要谨慎使用。
3.心跳
主从节点在建立复制后，他们之间维护着长连接并彼此发送心跳命令。
心跳的关键机制如下：
主节点默认每隔 10 秒对从节点发送 ping 命令，可修改配置 repl-ping-slave-period 控制发送频率。
从节点在主线程每隔一秒发送 replconf ack{offset} 命令，给主节点上报自身当前的复制偏移量。
主节点收到 replconf 信息后，判断从节点超时时间，如果超过 repl-timeout 60 秒，则判断节点下线。
二、哨兵（sentinal）
哨兵模式主要解决了主从复制出现故障时需要人为干预的问题。
1.主要功能
集群监控：负责监控Redis master和slave进程是否正常工作
消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
故障转移：如果master node挂掉了，会自动转移到slave node上
配置中心：如果故障转移发生了，通知client客户端新的master地址
2.原理
当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
①哨兵机制建立了多个哨兵节点(进程)，共同监控数据节点的运行状况。
②同时哨兵节点之间也互相通信，交换对主从节点的监控状况。
③每隔1秒每个哨兵会向整个集群：Master主服务器+Slave从服务器+其他Sentinel（哨兵）进程，发送一次ping命令做一次心跳检测。
涉及两个新的概念：主观下线和客观下线。
主观下线：一个哨兵节点判定主节点down掉是主观下线。
客观下线：只有半数哨兵节点都主观判定主节点down掉，此时多个哨兵节点交换主观判定结果，才会判定主节点客观下线。
基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制Raft算法（选举算法），最终被投为领导者的哨兵节点完成主从自动化切换的过程。
三、集群
Redis集群的实现大致有三种形式：
- 客户端分片，如redis的Java客户端jedis也是支持的，使用一致性hash
- 基于代理的分片，如codis和Twemproxy
- 路由查询， redis-cluster
下面分别来做介绍。
1.客户端分片
这是Redis cluster出来前业界普遍使用的方式。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。
Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。在主Redis宕机时，备Redis接管过来，上升为主Redis，继续提供服务。主备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性。
优势：简单，服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。
劣势：分片处理放到客户端，规模进一步扩大时给运维带来挑战。不支持动态增删节点。服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化。
关于一致性Hash算法详解，请参考：面试必备：什么是一致性Hash算法？
2.基于代理的分片
客户端发送请求到一个代理组件，代理解析客户端的数据，并将请求转发至正确的节点，最后将结果回复给客户端。
该模式的特性如下：
- 透明接入，业务程序不用关心后端Redis实例，切换成本低。
- Proxy 的逻辑和存储的逻辑是隔离的。
- 代理层多了一次转发，性能有所损耗。
简单的结构图如下：
主流的代理组件有：Twemproxy和Codis。
3.路由查询
Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。
Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽，将每个key映射到每一个具体的槽上，而每个redis节点可以负责管理一定数量的槽。
当客户端操作的key分配到该node上时，就像操作单一Redis实例一样;当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这有点儿像浏览器页面的302 redirect跳转。
Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。
优势：
- 无中心架构，支持动态扩容，对业务透明
- 具备Sentinel的监控和故障转移能力
- 客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
- 高性能，客户端直连redis服务，免去了proxy代理的损耗
劣势：运维复杂，数据迁移需要人工干预，只能使用0号数据库，不支持批量操作，分布式逻辑和存储模块耦合等。
