本文是对Redis Cluster（集群）一文的补充。
1 集群功能的限制
(1) key批量操作支持有限。如mset、mget，目前支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于执行mget、mset等操作可能存在多个节点上因此不被支持。
(2) key事务操作支持有限。同理只支持多key在同一个节点上的事务操作，当多个key分布在不同的节点上时无法使用事务功能。
(3) key作为数据分区最小粒度，因为不能将一个大的键值对象如hash、list等映射到不同的节点。
(4) 不支持多数据库空间。单机下的Redis可以支持16个数据库，集群模式下只能使用一个数据库空间，即db 0.
(5) 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。
2 节点通信
2.1通信流程
在分布式存储中需要提供维护节点元数据信息的机制，所谓元数据是指：节点负责哪些数据，是否出现故障等信息。常见的元数据维护方式有：集中式和P2P方式。Redis集群采用P2P的Gossip（流言）协议，Gossip协议工作原理就是节点彼此不断通信交换信息，一段时间后所有节点都会知道集群完整信息。
通信过程说明：
(1) 集群中的每个节点都会单独开辟一个TCP通信，用于节点之间彼此通信，通信端口号在基础端口上加10000。
(2) 每个节点在固定周期内通过特定规则选择几个节点发送ping消息。
(3) 接收到ping消息的节点用pong消息作为相应。
集群中每个节点通过一定规则挑选要通信的节点，每个节点可能全部节点，也可能仅知道部分节点，只要这些节点可以正常通信，最终它们回达到一致的状态。当节点故障、新节点加入、主从角色发生变化、槽信息变更等事件发生时，通过不断的ping/pong消息通信，经过一段时间所有节点都会知道整个集群全部节点的最新状态，从而达到集群状态同步的目的。
2.2节点选择
虽然Gossip协议的信息交换机制具有天然的分布式特性，但是它有成本的。由于内部需要频繁的进行信息通信，而ping/pong消息会携带当前节点和部分其他节点的状态数据，势必会加重带宽和计算的负担。Redis集群内通信采用固定频率（定时任务每秒执行10次）。因此节点每次选择需要通信的节点列表变得十分重要，节点过多会导致成本过高，节点过少会影响集群信息交换的频率，从而影响故障判定、新节点发现等需求的速度。
选择节点的规则：
(1) 每秒在节点列表中随机选出5个节点，并选出最久没有通信的节点发送ping消息，用于保证Gossip信息交换的随机性。
(2) 每100毫秒都会扫描本地节点列表，如果发现节点最近一次接受pong消息的时间大于cluster-node-timeout/2，则立刻发送ping消息，防止节点消息太长时间没有更新。所以cluster-node-timeout值的大小对集群内信息交换频率有很大的影响，不宜过大和过小。
3 集群运维
3.1 集群的完整性
为了保证集群完整性，默认情况下当集群16384个槽任何一个没有指派到节点时整个集群不可用。执行任何键命令返回（error）CLUSTERDOWN Hash slot not served错误。这是对集群完整性的一种保护措施，保证所有的槽都指派给在线的节点。但是当持有槽的主节点下线时，从故障发现到自动完成转移期间整个集群是不可用状态，对于大多数业务无法容忍这种情况，因此建议将参数cluster-require-full-coverage配置为no，当主节点故障时只影响它负责槽的相关命令执行，不会影响其他主节点的可用性。
3.2 带宽消耗
集群带宽消耗主要分为：读写命令消耗、Gossip消息消耗。
搭建Redis集群应根据数据规模和消息通信成本做出合理规划：
(1) 在满足业务的情况下尽量避免大集群。
(2) 适度提高cluster-node-timeout降低消息发送频率，同时cluster-node-timeout还影响故障转移速度，因此需要根据业务场景兼顾二者的平衡。
(3) 如果条件允许集群尽量均匀部署在更多机器上。
3.3 集群倾斜
集群倾斜是指不同节点之间数据量和请求量出现明显差异。
3.1.1 数据倾斜：
(1) 节点和槽分配验证不均。
(2) 不同槽对应的键差异过大。
(3) 集合对象包含大量元素。
(4) 内存相关配置不一致。
3.1.2 请求倾斜：
集群内特定节点请求量/流量过大将导致节点之间负载不均。常出现在热点键场景，当键命令消耗较低时如小对象的get、set、incr等，即使请求量差异较大一般也不会产生负载严重不均。但是当热点键对应高算法复杂度的命令或者是大对象操作如hgetall、semebers等，会导致节点负载过高。避免方式如下：
(1) 合理设计键，热点大集合对象做拆分或使用hmget替代hgetall避免整体读。
(2) 不要使用热键作为hash_tag，避免映射到同一个槽。
(3) 对于一致性要求不高的场景，客户端可使用本地缓存减少热键调用。
3.4 集群读写分离
3.4.1 只读连接
集群模式下从节点不接受任何读写命令，发送过来的键命令会重定向到负责槽的主节点上（其中包括它的主节点）。当需要使用从节点分担主节点读压力时，可以使用readonly命令打开客户端连接的只读状态。readonly命令是连接级别生效。
3.4.2读写分离
集群的读写分离同样会有复制延迟、读取过期数据、从节点故障等问题。且集群模式下读写分离成本比较高，可以直接扩展主节点数量集群性能，一般不建议使用集群模式下的读写分离。集群读写分离有时用于特殊场景：
(1) 利用复制的最终一致性使用多个从节点做跨机房部署降低读命令网络延迟。
(2) 主节点故障转移时间过长，业务端把读请求路由给从节点保证读操作可用。
