1、主从同步
增量同步
增量同步指令集。主节点把指令集缓存到本地内存Buffer，然后异步将buffer同步给从节点。<br>Ruffer为定长的环形数组，如果数组满了就会从头开始覆盖前面内容。将会引发快照同步
快照同步
主节点当前内存的数据全部快照到磁盘文件，传送到从节点，从节点执行全量加载（加载前清空当前内存）。<br>快照同步的过程中，会继续增量同步
2、哨兵模式—Sentinel
哨兵模式一般采用3个以上Sentinel节点作为集群来监控redis主从状态。当主节点挂掉时，自动选择一个最优的从节点切换成为主节点。客户端来连接redis集群时会首先连接哨兵集群，通过哨兵集群来获取主节点地址，然后再连接主节点进行数据交互。当主节点发生故障时，客户端会重新向哨兵要替换地址，哨兵会将最新的主节点地址告诉客户端。
3、Codis代理
出身
中国人开源的，使用Go语言开发，前豌豆荚中间件团队。（后项目带头人刘奇又开发出TiDB）
Codis自身是无状态，只是转发客户端请求，可以集群。
分片原理
默认将所有key划分为1024个槽位。首先将客户端传过来的key进行crc32运算计算hash值，<br>再将hash后的整数值对1024这个整数进行取模得到一个余数，这个余数就是对应key的槽位。<br>
槽位默认1024，支持设置，如2048，4096等
槽位信息存储
Codis需要个分布式配置存储数据库专门用来持久化槽位关系，目前支持zookeeper和etcd
分片扩容
Codis支持自动均衡功能，在系统空闲时观察每个Redis实例对应的slot数量，如果不平衡就自动就行迁移
缺点
不支持事务，事务只能在单个Redis实例中完成（所有分片方案的通病）
增加了Proxy中转层，网络开销比单个Redis大
集群配置中心使用zookeeper来实现，在部署上增加了运维代价
4、Cluster分片
出身
Redis的“亲儿子”，Redis作者自己提供的集群化方案
分片原理
Cluster将数据划分为16384个槽位，每个节点负责其中一部分槽位。
每个节点负责整个集群的一部分数据，节点间相互连接组成一个对等的集群，节点间通过一种特殊的二进制协议交互集群信息（Raft和Gossip）
默认对key值使用crc16算法进行hash，再将hash后的整数值对16384进行取模来得到具体槽位
槽位信息存储
槽位的位置信息存储于每个节点中，不像Codis需要额外的分布式存储
分片扩容
Cluster提供了工具redis-trib可以让运维人员手动调整槽位分配，使用Ruby语言开发，通过组合各种原生的cluster指令来实现。<br>redis-trib提供了UI界面来操作迁移，同事提供自动化平衡槽位工具，无需人工干预就可以均衡集群负载
数据迁移过程中源节点主线程会处于阻塞状态，直到key被删除。源节点获取key内容->存到目标节点->源节点删除key
容错性
Cluster的每个分片节点都可以是主从同步结构，当主节点故障，从节点提升为主节点
由于Cluster是去中心化的，只有大多数节点都认定某个节点失联了，集群才认为该节点需要进行主从切换来容错
