Redis集群分片原理
集群的目的：
横向伸缩。实现扩展数据库大小、带宽、计算能力。
分片理解：
类似数据库分库分表设计，需要实现分片路由。
分片路由可以简单分为服务端路由、客户端路由 或第三方服务路由。
客户端路由：
客户端自己计算将请求路由到哪个服务器上
优点：降低服务端集群的复杂度。服务器间是独立的，无需任何联系。
缺点：客户端需要实时知道服务器集群节点信息。如果新增一个节点，客户端需要支持动态sharding，否则需要重启redis。以及redis集群的高可用方面需要额外考虑。
服务端路由：
客户端可以和集群内任意节点通信，服务端负责将请求路由到相应的机器上，是一个重定向的过程。
优点：支持高可用，任意节点都有主从，主挂了，其从会自动接管。
缺点：需要客户端语言实现服务器集群的协议（但是目前多数语言都有其客户端实现版本）
服务端路由算法：
1）有 0-16383 地址位置（Slot），每个节点对应其中一段地址范围。比如：
slots: 0-5460 (5461 slots) 节点1
slots: 5461-10922 (5462 slots) 节点2
slots: 10923-16383 (5461 slots) 节点3
2）将key映射到 16384 个地址范围之内（Slot），并分配到其值对应区间的机器。
负载均衡：集群内各节点之间是可以迁移数据的，以 Slot 为单位。需要手动触发。
集群管理：集群内节点两两之间定期交换节点信息并且更新（节点ip、端口、名称、状态、角色）
可用性：分主从。节点之间本身是有互相发送心跳，并且通过 cluster-node-timeout 配置多少时间没有收到回复即可认为该节点为 PFAIL。这里还有一个法定人数（quorum）的概念，即如果有 n 个节点都认为这个节点为 PFAIL，则最终标记该节点为FAIL。并广播给其他所有节点，其他节点收到后即认为该节点宕机。所以从这里就可以看出，主宕机后，至少在一个心跳检测周期内，该主所负责的 Slots 的读写服务不可用。
代理服务路由：
客户端与proxy联系，proxy计算集群节点信息，并将请求发送到对应的集群节点。
redis 3.0之前官方推荐的方式：proxy + redis-sentinel
