Redis集群模式
1、常见的三种数据的集群存储模式
full-mirror：全量镜像模式，单纯备份模式，各个节点数据相同，都包含了全量数据，仅主节点可写，保证了数据冗余和读的负载均衡。数据安全性高，横向扩展能力差，资源利用率不高。
pure-sharding：数据分片，每个节点的数据不相同，所有节点中数据的并集就是全量数据。横向扩展能力强，资源利用率高，但是数据安全性低。
mirrored-sharding：结合两种模式的优点，既满足高数据安全性要求，又能实现规模的横向扩展。
2、Redis集群的必要性和分类
必要性：单实例服务存在单点故障，集群模式能提高服务的整体可用性。
分类：
主从复制（Replication）：数据在主从间全量镜像，仅主节点可写，所有节点都可读，但仍不具备横向扩展能力。
静态主从：在启动服务时，在配置文件中指定，给slave指定其从属的master，可以实现数据的备份和读操作的负载均衡，但是缺乏对master实例的高可用保障。
redis-server --port 6380 slavaof 127.0.0.1 6379 //将6379配置为本实例的master
还可以在服务运行过程中通过客户端命令手动改变实例的角色：
redis > slaveof 127.0.0.1 6381 //将本实例的master改为6381
redis > slaveof no one //将本实例从主从结构中独立出来，但会保留之前的数据
利用哨兵（Sentinel ）实现高可用：每个服务实例都启动一个哨兵守护进程，负责集群中节点状态的监控和主节点的选举，此时主节点也就实现了高可用。哨兵可以单实例管理单集群，也可以单实例管理多集群，还可以组成无中心哨兵集群，哨兵集群内部使用paxos理论进行协调管理。
分布式集群（Cluster）：
twemproxy：twitter开发的一个针对key提供路由功能的代理曾，代理层上方时客户端，下方是多个Redis服务实例，形成分片集群，客户端针对key的读写操作都必须经过代理层路由到分片集群中指定的服务实例上（key的hashcode对节点数量取模），这就实现了集群的横向扩展。
- 缺点：
- 存在数据倾斜问题，一旦发生倾斜将不能成分利用集群资源，消除倾斜需要额外设计算法，耗时耗力。
- 代理层存在单点缺陷。
- 节点数量变动后必须对历史数据全量再分发。
官方集群方案（3.x后）：将整个集群划分为16384个逻辑slot，每个服务实例集群构成master-slave分片，各分片各自来认领一批逻辑slot。所有的key都会被路由到某个逻辑slot上，计算公式为【slot_num = crc16(key) % 16384】，式中crc16函数是16位循环冗余校验和函数。
当需要横向扩容时，旧节点让出一部分slot给新节点，这部分数据也随slot迁移到新节点上，这就避免了全量数据的重分发。
当发生数据倾斜时可以手动瓜分较重节点上的slot，实现数据的分摊，从而解决了倾斜问题。
每个分片都是一个master-slave结构，保证本分片内的高可用（当前模式将sentinel进程融合到了server进程中，方便分片内节点的状态和角色管理）。
每个分片的主节点都具有slot计算能力，当某个主节点接收到一个key的添加时，都会计算其应该归属的slot，如果恰好命中本分片，就存储数据，如果未命中则会告诉客户端让其重新计算。读数据时，分片主节点会计算key的slot，如果恰好命中则返回value，如果未命中则会返给正确的存储节点位置。
部署时至少要启动6各节点，三个分片，每个分片内一主一从。
3、Redis主从复制（哨兵模式）
- 一个Redis主服务拥有多个副本服务，形成master-slave结构。
- 只要网络正常，master会一直将自己的数据更新同步给slave，保持主从数据一致。
- 只有master能接收写命令，master和slave都可以接收读命令，实现读操作的负载均衡。