2. 妨碍转移
集群只实现了主节点的妨碍转移；从节点妨碍时只会被下线，不会举办妨碍转移。因此，利用集群时，应审慎利用读写疏散技能，因为从节点妨碍会导致读处事不行用，可用性变差。
这里不再具体先容妨碍转移的细节，只对重要事项举办说明：
节点数量：在妨碍转移阶段，需要由主节点投票选出哪个从节点成为新的主节点；从节点选举胜出需要的票数为N/2+1；个中N为主节点数量(包罗妨碍主节点)，但妨碍主节点实际上不能投票。因此为了可以或许在妨碍产生时顺利选出从节点，集群中至少需要3个主节点(且陈设在差异的物理机上)。
妨碍转移时间：从主节点妨碍产生到完成转移，所需要的时间主要耗损在主观下线识别、主观下线流传、选举延迟等几个环节；详细时间与参数cluster-node-timeout有关，一般来说：
妨碍转移时间(毫秒) ≤ 1.5 * cluster-node-timeout + 1000
cluster-node-timeout的默认值为15000ms(15s)，因此妨碍转移时间会在20s量级
3. 集群的限制及应对要领
由于集群中的数据漫衍在差异节点中，导致一些成果受限，包罗：
（1）key批量操纵受限：譬喻mget、mset操纵，只有当操纵的key都位于一个槽时，才气举办。针对该问题，一种思路是在客户端记录槽与key的信息，每次针对特定槽执行mget/mset；别的一种思路是利用Hash Tag，将在下一小节先容。
（2）keys/flushall等操纵：keys/flushall等操纵可以在任一节点执行，可是功效只针对当前节点，譬喻keys操纵只返回当前节点的所有键。针对该问题，可以在客户端利用cluster nodes获取所有节点信息，并对个中的所有主节点执行keys/flushall等操纵。
（3）事务/Lua剧本：集群支持事务及Lua剧本，但前提条件是所涉及的key必需在同一个节点。Hash Tag可以办理该问题。
（4）数据库：单机Redis节点可以支持16个数据库，集群模式下只支持一个，即db0。
（5）复制布局：只支持一层复制布局，不支持嵌套。
4. Hash Tag
Hash Tag道理是：当一个key包括 {} 的时候，差池整个key做hash，而仅对 {} 包罗的字符串做hash。
Hash Tag可以让差异的key拥有沟通的hash值，从而分派在同一个槽里；这样针对差异key的批量操纵(mget/mset等)，以及事务、Lua剧本等都可以支持。不外Hash Tag大概会带来数据分派不均的问题，这时需要：(1)调解差异节点中槽的数量，使数据漫衍只管匀称；(2)制止对热点数据利用Hash Tag，导致请求漫衍不均。
下面是利用Hash Tag的一个例子；通过对product加Hash Tag，可以将所有产物信息放到同一个槽中，便于操纵。
5. 参数优化
cluster_node_timeout
cluster_node_timeout参数在前面已经劈头先容；它的默认值是15s，影响包罗：
（1）影响PING动静吸收节点的选择：值越大对延迟容忍度越高，选择的吸收节点越少，可以低落带宽，但会低落收敛速度；应按照带宽环境和应用要求举办调解。
（2）影响妨碍转移的鉴定和时间：值越大，越不容易误判，但完成转移耗损时间越长；应按照网络状况和应用要求举办调解。
cluster-require-full-coverage
前面提到，只有当16384个槽全部门配完毕时，集群才气上线。这样做是为了担保集群的完整性，但同时也带来了新的问题：当主节点产生妨碍而妨碍转移尚未完成，原主节点中的槽不在任何节点中，此时集中群处于下线状态，无法响应客户端的请求。
cluster-require-full-coverage参数可以改变这一设定：假如配置为no，则当槽没有完全分派时，集群仍可以上线。参数默认值为yes，假如应用对可用性要求较高，可以修改为no，但需要本身担保槽全部门配。
6. redis-trib.rb
redis-trib.rb提供了浩瀚实用东西：建设集群、增减节点、槽迁移、查抄完整性、数据从头均衡等；通过help呼吁可以查察具体信息。在实践中假如能利用redis-trib.rb东西则只管利用，不单利便快捷，还可以大大低落堕落概率。