一、redis集群介绍：
1、为什么需要redis集群？
在讲redis集群架构之前，我们先简单讲下redis单实例的架构，从最开始的一主n从，到读写分离，再到sentinel哨兵机制，单实例的redis缓存足以应对大多数的使用场景，也能实现主从故障迁移。
但是，在某些场景下，单实例存redis缓存会存在的几个问题：
（1）写并发：
redis单实例读写分离可以解决读操作的负载均衡，但对于写操作，仍然是全部落在了master节点上面，在海量数据高并发场景，一个节点写数据容易出现瓶颈，造成master节点的压力上升。
（2）海量数据的存储压力：
单实例redis本质上只有一台master作为存储，如果面对海量数据的存储，一台redis的服务器就应付不过来了，而且数据量太大意味着持久化成本高，严重时可能会阻塞服务器，造成服务请求成功率下降，降低服务的稳定性。
针对以上的问题，redis集群提供了较为完善的方案，解决了存储能力受到单机限制，写操作无法负载均衡的问题。
2、什么是redis集群？
redis3.0加入了redis的集群模式，实现了数据的分布式存储，对数据进行分片，将不同的数据存储在不同的master节点上面，从而解决了海量数据的存储问题。
redis集群采用去中心化的思想，没有中心节点的说法，对于客户端来说，整个集群可以看成一个整体，可以连接任意一个节点进行操作，就像操作单一redis实例一样，不需要任何代理中间件，当客户端操作的key没有分配到该node上时，redis会返回转向指令，指向正确的node。
redis也内置了高可用机制，支持n个master节点，每个master节点都可以挂载多个slave节点，当master节点挂掉时，集群会提升它的某个slave节点作为新的master节点。
如上图所示，redis集群可以看成多个主从架构组合起来的，每一个主从架构可以看成一个节点（其中，只有master节点具有处理请求的能力，slave节点主要是用于节点的高可用）
二、redis集群的数据分布算法：哈希槽算法
1、什么是哈希槽算法？
前面讲到，redis集群通过分布式存储的方式解决了单节点的海量数据存储的问题，对于分布式存储，需要考虑的重点就是如何将数据进行拆分到不同的redis服务器上。常见的分区算法有hash算法、一致性hash算法，关于这些算法这里就不多介绍。
- 普通hash算法：将key使用hash算法计算之后，按照节点数量来取余，即hash(key)%n。优点就是比较简单，但是扩容或者摘除节点时需要重新根据映射关系计算，会导致数据重新迁移。
- 一致性hash算法：为每一个节点分配一个token，构成一个哈希环；查找时先根据key计算hash值，然后顺时针找到第一个大于等于该哈希值的token节点。优点是在加入和删除节点时只影响相邻的两个节点，缺点是加减节点会造成部分数据无法命中，所以一般用于缓存，而且用于节点量大的情况下，扩容一般增加一倍节点保障数据负载均衡。
redis集群采用的算法是哈希槽分区算法。redis集群中有16384个哈希槽（槽的范围是 0 -16383，哈希槽），将不同的哈希槽分布在不同的redis节点上面进行管理，也就是说每个redis节点只负责一部分的哈希槽。在对数据进行操作的时候，集群会对使用crc16算法对key进行计算并对16384取模（slot = crc16(key)383），得到的结果就是 key-value 所放入的槽，通过这个值，去找到对应的槽所对应的redis节点，然后直接到这个对应的节点上进行存取操作。
使用哈希槽的好处就在于可以方便的添加或者移除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；哈希槽数据分区算法具有以下几种特点：
- 解耦数据和节点之间的关系，简化了扩容和收缩难度；
- 节点自身维护槽的映射关系，不需要客户端代理服务维护槽分区元数据
- 支持节点、槽、键之间的映射查询，用于数据路由，在线伸缩等场景
槽的迁移与指派命令：cluster addslots 0 1 2 3 4 ... 5000
默认情况下，redis集群的读和写都是到master上去执行的，不支持slave节点读和写，跟redis主从复制下读写分离不一样，因为redis集群的核心的理念，主要是使用slave做数据的热备，以及master故障时的主备切换，实现高可用的。redis的读写分离，是为了横向任意扩展slave节点去支撑更大的读吞吐量。而redis集群架构下，本身master就是可以任意扩展的，如果想要支撑更大的读或写的吞吐量，都可以直接对master进行横向扩展。
2、redis中哈希槽相关的数据结构：
（1）clusternode数据结构：保存节点的当前状态，比如节点的创建时间，节点的名字，节点当前的配置纪元，节点的ip和地址，等等。
（2）clusterstate数据结构：记录当前节点所认为的集群目前所处的状态。
（3）节点的槽指派信息：
clusternode数据结构的slots属性和numslot属性记录了节点负责处理那些槽：slots属性是一个二进制位数组(bit array)，这个数组的长度为16384/8=2048个字节，共包含16384个二进制位。master节点用bit来标识对于某个槽自己是否拥有，时间复杂度为o(1)
（4）集群所有槽的指派信息：
当收到集群中其他节点发送的信息时，通过将节点槽的指派信息保存在本地的clusterstate.slots数组里面，程序要检查槽i是否已经被指派，又或者取得负责处理槽i的节点，只需要访问clusterstate.slots[i]的值即可，时间复杂度仅为o(1)
如上图所示，clusterstate 中保存的 slots 数组中每个下标对应一个槽，每个槽信息中对应一个 clusternode 也就是缓存的节点。这些节点会对应一个实际存在的 redis 缓存服务，包括 ip 和 port 的信息。redis cluster 的通讯机制实际上保证了每个节点都有其他节点和槽数据的对应关系。无论redis 的客户端访问集群中的哪个节点都可以路由到对应的节点上，因为每个节点都有一份 clusterstate，它记录了所有槽和节点的对应关系。
3、集群的请求重定向：
前面讲到，redis集群在客户端层面没有采用代理，并且无论redis 的客户端访问集群中的哪个节点都可以路由到对应的节点上，下面来看看 redis 客户端是如何通过路由来调用缓存节点的：
（1）moved请求：
如上图所示，redis 客户端通过 crc16(key)383 计算出 slot 的值，发现需要找“缓存节点1”进行数据操作，但是由于缓存数据迁移或者其他原因导致这个对应的 slot 的数据被迁移到了“缓存节点2”上面。那么这个时候 redis 客户端就无法从“缓存节点1”中获取数据了。但是由于“缓存节点1”中保存了所有集群中缓存节点的信息，因此它知道这个 slot 的数据在“缓存节点2”中保存，因此向 redis 客户端发送了一个 moved 的重定向请求。这个请求告诉其应该访问的“缓存节点2”的地址。redis 客户端拿到这个地址，继续访问“缓存节点2”并且拿到数据。
（2）ask请求：
上面的例子说明了，数据 slot 从“缓存节点1”已经迁移到“缓存节点2”了，那么客户端可以直接找“缓存节点2”要数据。那么如果两个缓存节点正在做节点的数据迁移，此时客户端请求会如何处理呢？
redis 客户端向“缓存节点1”发出请求，此时“缓存节点1”正向“缓存节点 2”迁移数据，如果没有命中对应的 slot，它会返回客户端一个 ask 重定向请求并且告诉“缓存节点2”的地址。客户端向“缓存节点2”发送 asking 命令，询问需要的数据是否在“缓存节点2”上，“缓存节点2”接到消息以后返回数据是否存在的结果。
（3）频繁重定向造成的网络开销的处理：smart客户端
① 什么是 smart客户端：
在大部分情况下，可能都会出现一次请求重定向才能找到正确的节点，这个重定向过程显然会增加集群的网络负担和单次请求耗时。所以大部分的客户端都是smart的。所谓 smart客户端，就是指客户端本地维护一份hashslot => node的映射表缓存，大部分情况下，直接走本地缓存就可以找到hashslot => node，不需要通过节点进行moved重定向，
② jediscluster的工作原理：
- 在jediscluster初始化的时候，就会随机选择一个node，初始化hashslot => node映射表，同时为每个节点创建一个jedispool连接池。
- 每次基于jediscluster执行操作时，首先会在本地计算key的hashslot，然后在本地映射表找到对应的节点node。
- 如果那个node正好还是持有那个hashslot，那么就ok；如果进行了reshard操作，可能hashslot已经不在那个node上了，就会返回moved。
- 如果jediscluter api发现对应的节点返回moved，那么利用该节点返回的元数据，更新本地的hashslot => node映射表缓存
- 重复上面几个步骤，直到找到对应的节点，如果重试超过5次，那么就报错，jedisclustermaxredirectionexception
③ hashslot迁移和ask重定向：
如果hashslot正在迁移，那么会返回ask重定向给客户端。客户端接收到ask重定向之后，会重新定位到目标节点去执行，但是因为ask发生在hashslot迁移过程中，所以jediscluster api收到ask是不会更新hashslot本地缓存。
虽然ask与moved都是对客户端的重定向控制，但是有本质区别。ask重定向说明集群正在进行slot数据迁移，客户端无法知道迁移什么时候完成，因此只能是临时性的重定向，客户端不会更新slots缓存。但是moved重定向说明键对应的槽已经明确指定到新的节点，客户端需要更新slots缓存。
三、redis集群中节点的通信机制：goosip协议
redis集群的哈希槽算法解决的是数据的存取问题，不同的哈希槽位于不同的节点上，而不同的节点维护着一份它所认为的当前集群的状态，同时，redis集群是去中心化的架构。那么，当集群的状态发生变化时，比如新节点加入、slot迁移、节点宕机、slave提升为新master等等，我们希望这些变化尽快被其他节点发现，redis是如何进行处理的呢？也就是说，redis不同节点之间是如何进行通信进行维护集群的同步状态呢？
在redis集群中，不同的节点之间采用gossip协议进行通信，节点之间通讯的目的是为了维护节点之间的元数据信息。这些元数据就是每个节点包含哪些数据，是否出现故障，通过gossip协议，达到最终数据的一致性。
gossip协议，是基于流行病传播方式的节点或者进程之间信息交换的协议。原理就是在不同的节点间不断地通信交换信息，一段时间后，所有的节点就都有了整个集群的完整信息，并且所有节点的状态都会达成一致。每个节点可能知道所有其他节点，也可能仅知道几个邻居节点，但只要这些节可以通过网络连通，最终他们的状态就会是一致的。gossip协议最大的好处在于，即使集群节点的数量增加，每个节点的负载也不会增加很多，几乎是恒定的。
redis集群中节点的通信过程如下：
- 集群中每个节点都会单独开一个tcp通道，用于节点间彼此通信。
- 每个节点在固定周期内通过待定的规则选择几个节点发送ping消息
- 接收到ping消息的节点用pong消息作为响应
使用gossip协议的优点在于将元数据的更新分散在不同的节点上面，降低了压力；但是缺点就是元数据的更新有延时，可能导致集群中的一些操作会有一些滞后。另外，由于 gossip 协议对服务器时间的要求较高，时间戳不准确会影响节点判断消息的有效性。而且节点数量增多后的网络开销也会对服务器产生压力，同时结点数太多，意味着达到最终一致性的时间也相对变长，因此官方推荐最大节点数为1000左右。
redis cluster架构下的每个redis都要开放两个端口号，比如一个是6379，另一个就是加1w的端口号16379。
- 6379端口号就是redis服务器入口。
- 16379端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用的是一种叫gossip 协议的二进制协议
1、gossip协议的常见类型：
gossip协议常见的消息类型包含： ping、pong、meet、fail等等。
（1）meet：主要用于通知新节点加入到集群中，通过「cluster meet ip port」命令，已有集群的节点会向新的节点发送邀请，加入现有集群。
（2）ping：用于交换节点的元数据。每个节点每秒会向集群中其他节点发送 ping 消息，消息中封装了自身节点状态还有其他部分节点的状态数据，也包括自身所管理的槽信息等等。
- 因为发送ping命令时要携带一些元数据，如果很频繁，可能会加重网络负担。因此，一般每个节点每秒会执行 10 次 ping，每次会选择 5 个最久没有通信的其它节点。
- 如果发现某个节点通信延时达到了 cluster_node_timeout / 2，那么立即发送 ping，避免数据交换延时过长导致信息严重滞后。比如说，两个节点之间都 10 分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题。所以 cluster_node_timeout 可以调节，如果调得比较大，那么会降低 ping 的频率。
- 每次 ping，会带上自己节点的信息，还有就是带上 1/10 其它节点的信息，发送出去，进行交换。至少包含 3 个其它节点的信息，最多包含 （总节点数 - 2）个其它节点的信息。
（3）pong：ping和meet消息的响应，同样包含了自身节点的状态和集群元数据信息。
（4）fail：某个节点判断另一个节点 fail 之后，向集群所有节点广播该节点挂掉的消息，其他节点收到消息后标记已下线。
由于redis集群的去中心化以及gossip通信机制，redis集群中的节点只能保证最终一致性。例如当加入新节点时(meet)，只有邀请节点和被邀请节点知道这件事，其余节点要等待 ping 消息一层一层扩散。除了 fail 是立即全网通知的，其他诸如新节点、节点重上线、从节点选举成为主节点、槽变化等，都需要等待被通知到，也就是gossip协议是最终一致性的协议。
2、meet命令的实现：
（1）节点a会为节点b创建一个clusternode结构，并将该结构添加到自己的clusterstate.nodes字典里面。
（2）节点a根据cluster meet命令给定的ip地址和端口号，向节点b发送一条meet消息。
（3）节点b接收到节点a发送的meet消息，节点b会为节点a创建一个clusternode结构，并将该结构添加到自己的clusterstate.nodes字典里面。
（4）节点b向节点a返回一条pong消息。
（5）节点a将受到节点b返回的pong消息，通过这条pong消息，节点a可以知道节点b已经成功的接收了自己发送的meet消息。
（6）之后，节点a将向节点b返回一条ping消息。
（7）节点b将接收到的节点a返回的ping消息，通过这条ping消息节点b可以知道节点a已经成功的接收到了自己返回的pong消息，握手完成。
（8）之后，节点a会将节点b的信息通过gossip协议传播给集群中的其他节点，让其他节点也与节点b进行握手，最终，经过一段时间后，节点b会被集群中的所有节点认识。
四、集群的扩容与收缩：
作为分布式部署的缓存节点总会遇到缓存扩容和缓存故障的问题。这就会导致缓存节点的上线和下线的问题。由于每个节点中保存着槽数据，因此当缓存节点数出现变动时，这些槽数据会根据对应的虚拟槽算法被迁移到其他的缓存节点上。所以对于redis集群，集群伸缩主要在于槽和数据在节点之间移动。
1、扩容：
- （1）启动新节点
- （2）使用cluster meet命令将新节点加入到集群
- （3）迁移槽和数据：添加新节点后，需要将一些槽和数据从旧节点迁移到新节点
如上图所示，集群中本来存在“缓存节点1”和“缓存节点2”，此时“缓存节点3”上线了并且加入到集群中。此时根据虚拟槽的算法，“缓存节点1”和“缓存节点2”中对应槽的数据会应该新节点的加入被迁移到“缓存节点3”上面。
新节点加入到集群的时候，作为孤儿节点是没有和其他节点进行通讯的。因此需要在集群中任意节点执行 cluster meet 命令让新节点加入进来。假设新节点是 192.168.1.1 5002，老节点是 192.168.1.1 5003，那么运行以下命令将新节点加入到集群中。
192.168.1.1 5003> cluster meet 192.168.1.1 5002
这个是由老节点发起的，有点老成员欢迎新成员加入的意思。新节点刚刚建立没有建立槽对应的数据，也就是说没有缓存任何数据。如果这个节点是主节点，需要对其进行槽数据的扩容；如果这个节点是从节点，就需要同步主节点上的数据。总之就是要同步数据。
如上图所示，由客户端发起节点之间的槽数据迁移，数据从源节点往目标节点迁移。
- （1）客户端对目标节点发起准备导入槽数据的命令，让目标节点准备好导入槽数据。使用命令：cluster setslot {slot} importing {sourcenodeid}
- （2）之后对源节点发起送命令，让源节点准备迁出对应的槽数据。使用命令：cluster setslot {slot} migrating {targetnodeid}
- （3）此时源节点准备迁移数据了，在迁移之前把要迁移的数据获取出来。通过命令 cluster getkeysinslot {slot} {count}。count 表示迁移的 slot 的个数。
- （4）然后在源节点上执行，migrate {targetip} {targetport} “” 0 {timeout} keys {keys} 命令，把获取的键通过流水线批量迁移到目标节点。
- （5）重复 3 和 4 两步不断将数据迁移到目标节点。
- （6）完成数据迁移到目标节点以后，通过 cluster setslot {slot} node {targetnodeid} 命令通知对应的槽被分配到目标节点，并且广播这个信息给全网的其他主节点，更新自身的槽节点对应表。
2、收缩：
- 迁移槽。
- 忘记节点。通过命令 cluster forget {downnodeid} 通知其他的节点
为了安全删除节点，redis集群只能下线没有负责槽的节点。因此如果要下线有负责槽的master节点，则需要先将它负责的槽迁移到其他节点。迁移的过程也与上线操作类似，不同的是下线的时候需要通知全网的其他节点忘记自己，此时通过命令 cluster forget {downnodeid} 通知其他的节点。
五、集群的故障检测与故障转恢复机制：
1、集群的故障检测：
redis集群的故障检测是基于gossip协议的，集群中的每个节点都会定期地向集群中的其他节点发送ping消息，以此交换各个节点状态信息，检测各个节点状态：在线状态、疑似下线状态pfail、已下线状态fail。
（1）主观下线（pfail）：当节点a检测到与节点b的通讯时间超过了cluster-node-timeout 的时候，就会更新本地节点状态，把节点b更新为主观下线。
主观下线并不能代表某个节点真的下线了，有可能是节点a与节点b之间的网络断开了，但是其他的节点依旧可以和节点b进行通讯。
（2）客观下线：
由于集群内的节点会不断地与其他节点进行通讯，下线信息也会通过 gossip 消息传遍所有节点，因此集群内的节点会不断收到下线报告。
当半数以上的主节点标记了节点b是主观下线时，便会触发客观下线的流程（该流程只针对主节点，如果是从节点就会忽略）。将主观下线的报告保存到本地的 clusternode 的结构fail_reports链表中，并且对主观下线报告的时效性进行检查，如果超过 cluster-node-timeout*2 的时间，就忽略这个报告，否则就记录报告内容，将其标记为客观下线。
接着向集群广播一条主节点b的fail 消息，所有收到消息的节点都会标记节点b为客观下线。
2、集群地故障恢复：
当故障节点下线后，如果是持有槽的主节点则需要在其从节点中找出一个替换它，从而保证高可用。此时下线主节点的所有从节点都担负着恢复义务，这些从节点会定时监测主节点是否进入客观下线状态，如果是，则触发故障恢复流程。故障恢复也就是选举一个节点充当新的master，选举的过程是基于raft协议选举方式来实现的。
2.1、从节点过滤：
检查每个slave节点与master节点断开连接的时间，如果超过了cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成master
2.2、投票选举：
（1）节点排序：
对通过过滤条件的所有从节点进行排序，按照priority、offset、run id排序，排序越靠前的节点，越优先进行选举。
- priority的值越低，优先级越高
- offset越大，表示从master节点复制的数据越多，选举时间越靠前，优先进行选举
- 如果offset相同，run id越小，优先级越高
（2）更新配置纪元：
每个主节点会去更新配置纪元（clusternode.configepoch），这个值是不断增加的整数。这个值记录了每个节点的版本和整个集群的版本。每当发生重要事情的时候（例如：出现新节点，从节点精选）都会增加全局的配置纪元并且赋给相关的主节点，用来记录这个事件。更新这个值目的是，保证所有主节点对这件“大事”保持一致，大家都统一成一个配置纪元，表示大家都知道这个“大事”了。
（3）发起选举：
更新完配置纪元以后，从节点会向集群发起广播选举的消息（clustermsg_type_failover_auth_request），要求所有收到这条消息，并且具有投票权的主节点进行投票。每个从节点在一个纪元中只能发起一次选举。
（4）选举投票：
如果一个主节点具有投票权，并且这个主节点尚未投票给其他从节点，那么主节点将向要求投票的从节点返回一条clustermsg_type_failover_auth_ack消息，表示这个主节点支持从节点成为新的主节点。每个参与选举的从节点都会接收clustermsg_type_failover_auth_ack消息，并根据自己收到了多少条这种消息来统计自己获得了多少主节点的支持。
如果超过(n/2 1)数量的master节点都投票给了某个从节点，那么选举通过，这个从节点可以切换成master，如果在 cluster-node-timeout*2 的时间内从节点没有获得足够数量的票数，本次选举作废，更新配置纪元，并进行第二轮选举，直到选出新的主节点为止。
在第(1)步排序领先的从节点通常会获得更多的票，因为它触发选举的时间更早一些，获得票的机会更大
2.3、替换主节点：
当满足投票条件的从节点被选出来以后，会触发替换主节点的操作。删除原主节点负责的槽数据，把这些槽数据添加到自己节点上，并且广播让其他的节点都知道这件事情，新的主节点诞生了。
（1）被选中的从节点执行slaveof no one命令，使其成为新的主节点
（2）新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己
（3）新的主节点对集群进行广播pong消息，告知其他节点已经成为新的主节点
（4）新的主节点开始接收和处理槽相关的请求
备注：如果集群中某个节点的master和slave节点都宕机了，那么集群就会进入fail状态，因为集群的slot映射不完整。如果集群超过半数以上的master挂掉，无论是否有slave，集群都会进入fail状态。
六、redis集群的搭建：
该部分可以参考这篇文章：https://juejin.cn/post/6922690589347545102#heading-1
redis集群的搭建可以分为以下几个部分：
1、启动节点：将节点以集群模式启动，读取或者生成集群配置文件，此时节点是独立的。
2、节点握手：节点通过gossip协议通信，将独立的节点连成网络，主要使用meet命令。
3、槽指派：将16384个槽位分配给主节点，以达到分片保存数据库键值对的效果。
七、redis集群的运维：
1、数据迁移问题：
redis集群可以进行节点的动态扩容缩容，这一过程目前还处于半自动状态，需要人工介入。在扩缩容的时候，需要进行数据迁移。而 redis为了保证迁移的一致性，迁移所有操作都是同步操作，执行迁移时，两端的 redis均会进入时长不等的阻塞状态，对于小key，该时间可以忽略不计，但如果一旦key的内存使用过大，严重的时候会接触发集群内的故障转移，造成不必要的切换。
2、带宽消耗问题：
redis集群是无中心节点的集群架构，依靠gossip协议协同自动化修复集群的状态，但goosip有消息延时和消息冗余的问题，在集群节点数量过多的时候，goosip协议通信会消耗大量的带宽，主要体现在以下几个方面：
- 消息发送频率：跟cluster-node-timeout密切相关，当节点发现与其他节点的最后通信时间超过 cluster-node-timeout/2时会直接发送ping消息
- 消息数据量：每个消息主要的数据占用包含：slots槽数组（2kb）和整个集群1/10的状态数据
- 节点部署的机器规模：机器的带宽上限是固定的，因此相同规模的集群分布的机器越多，每台机器划分的节点越均匀，则整个集群内整体的可用带宽越高
集群带宽消耗主要分为：读写命令消耗 gossip消息消耗，因此搭建redis集群需要根据业务数据规模和消息通信成本做出合理规划：
- 在满足业务需求的情况下尽量避免大集群，同一个系统可以针对不同业务场景拆分使用若干个集群。
- 适度提供cluster-node-timeout降低消息发送频率，但是cluster-node-timeout还影响故障转移的速度，因此需要根据自身业务场景兼顾二者平衡
- 如果条件允许尽量均匀部署在更多机器上，避免集中部署。如果有60个节点的集群部署在3台机器上每台20个节点，这是机器的带宽消耗将非常严重
3、pub/sub广播问题：
集群模式下内部对所有publish命令都会向所有节点进行广播，加重带宽负担，所以集群应该避免频繁使用pub/sub功能
4、集群倾斜：
集群倾斜是指不同节点之间数据量和请求量出现明显差异，这种情况将加大负载均衡和开发运维的难度。因此需要理解集群倾斜的原因
（1）数据倾斜：
- 节点和槽分配不均
- 不同槽对应键数量差异过大
- 集合对象包含大量元素
- 内存相关配置不一致
（2）请求倾斜：
合理设计键，热点大集合对象做拆分或者使用hmget代替hgetall避免整体读取
5、集群读写分离：
集群模式下读写分离成本比较高，直接扩展主节点数量来提高集群性能是更好的选择。