Redis集群Cluster

　　Redis Cluster 是社区版推出的 Redis 分布式集群解决方案，主要解决 Redis 分布式方面的需求，比
如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster 能起到很好的负载均衡的目的。
Redis Cluster 集群节点最小配置 6 个节点以上（3 主 3 从），其中主节点提供读写操作，从节点作为
备用节点，不提供请求，只作为故障转移使用。

　　Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0～16383 个整数槽内，每个节点负责维
护一部分槽以及槽所映射的键值数据

原理

 redis-cluster设计 Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都
和其他所有节点连接。

　　其结构特点：

　　1、所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。

　　2、节点的fail是通过集群中超过半数的节点检测失效时才生效。

　　3、客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

　　4、redis-cluster把所有的物理节点映射到[0-16383]slot上（不一定是平均分配）,cluster 负责维护node<->slot<->value。

　　5、Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据CRC16(key) mod 16384的值，决定将一个key放到哪个桶中。

　　　　　
a.redis cluster节点分配 现在我们是三个主节点分别是：A, B, C 三个节点，它们可以是一台机器上的
　　三个端口，也可以是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的
　　话，它们三个节点分别承担的slot 区间是：
　　　　节点A覆盖0－5460;
　　　　节点B覆盖5461－10922;
　　　　节点C覆盖10923－16383.
　　　　获取数据: 如果存入一个值，按照redis cluster哈希槽的算法： CRC16('key')384 = 6782。 那么就
　　会把这个key 的存储分配到 B 上了。同样，当我连接(A,B,C)任何一个节点想获取'key'这个key时，
　　也会这样的算法，然后内部跳转到B节点上获取数据
　　新增一个主节点: 新增一个节点D，redis cluster的这种做法是从各个节点的前面各拿取一部分slot
　　到D上，我会在接下来的实践中实验。大致就会变成这样：
　　　　节点A覆盖1365-5460
　　　　节点B覆盖6827-10922
　　　　节点C覆盖12288-16383
　　　　节点D覆盖0-1364,5461-6826,10923-12287
　　同样删除一个节点也是类似，2移动完成后就可以删除这个节点了。
b.Redis Cluster主从模式 redis cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应
　　一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，
　　就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉
　　上面那个例子里, 集群有ABC三个主节点, 如果这3个节点都没有加入从节点，如果B挂掉了，我们就无法
　　访问整个集群了。A和C的slot也无法访问。
　　所以我们在集群建立的时候，一定要为每个主节点都添加了从节点, 比如像这样, 集群包含主节点A、B、
　　C, 以及从节点A1、B1、C1, 那么即使B挂掉系统也可以继续正确工作。
　　B1节点替代了B节点，所以Redis集群将会选择B1节点作为新的主节点，集群将会继续正确地提供服
　　务。 当B重新开启后，它就会变成B1的从节点。
　　不过需要注意，如果节点B和B1同时挂了，Redis集群就无法继续正确地提供服务了。

 

优点：
无中心架构；
数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布；
可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除；
高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故
障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角
色提升；
降低运维成本，提高系统的扩展性和可用性。

缺点：
Client 实现复杂，驱动要求实现 Smart Client，缓存 slots mapping 信息并及时更新，提高了开发
难度，客户端的不成熟影响业务的稳定性。目前仅 JedisCluster 相对成熟，异常处理部分还不完
善，比如常见的“max redirect exception”。
节点会因为某些原因发生阻塞（阻塞时间大于 clutser-node-timeout），被判断下线，这种
failover 是没有必要的。
数据通过异步复制，不保证数据的强一致性。
多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的
情况。
Slave 在集群中充当“冷备”，不能缓解读压力，当然可以通过 SDK 的合理设计来提高 Slave 资源的
利用率。