集群完整性检查

默认情况下，redis集群会进行虚拟slot的完整性检查，如果不完整集群不可提供服务。那么在集群故障转移期间，redis集群没法提供服务，这在有些业务场景下是没法接受的。为此我们一般将参数cluster-require-full-coverage设置为no。这样只有故障的节点负责的slot不可用。

pubsub广播

Redis集群为了实现所有订阅的客户端都可以接收到发布的消息，但是不同的客户端可能连接的是不同的主节点，为此redis会广播所有的发布的消息到所有的节点，如果发布的消息较大，网络开销将会很大。需要避免发送大消息。

数据倾斜

数据倾斜主要发生在如下的情况：
1、slot分配不均。运维人员可能会给部分实例分配多一些slot，那么多分配一些slot的redis实例，可能就会占用大量的内存，造成数据倾斜。运维上需要规范。
2、hash_tag。由于redis集群不支持扩节点的事务与管道。开发人员就会使用hash_tag使其能映射到相同的节点。如果拥有大量的这种key映射到相同的slot或几个slot，那么就会导致数据倾斜。开发同学需要尽量避免使用hash_key或者使得hash_tag能离散分布于不同的slot。
3、Bigkey。Bigkey非常容易引起数据倾斜。如果bigkey是一个string，我们可以通过某种机制将其拆分成多个key。如果bigkey是集合类型，可以将其拆分成多个集合，每个集合保存一部分数据。

访问倾斜

通过如上的方式，虽然数据都均匀的分布到各个节点了。但是集群中可能包含热点数据，而热点数据可能不多，可能他们都分布到了一个或某几个节点上了。那么就会造成访问倾斜。如果热点key是只读的，那么我们简单的将数据保存到多个节点。但如果数据有读有写就比较麻烦，特别是极热点数据，可能需要单独一个redis主从集群处理，做到数据隔离，如秒杀场景。

数据迁移中

如果数据迁移的是bigkey，迁移过程中节点会堵塞，需要避免bigkey。迁移过程不支持批量处理的命令如果跨多个节点，很难处理，会出现报错。但是管道会按顺序返回报错，为此集群下优先使用管道功能。

带宽消耗

在我的博客Redis集群–水平扩展redis的读写性能中介绍了redis集群通过ping pong消息互相通信与交换数据。当集群规模很大时，网络带宽的占用将非常可观。如果某台主机部署了过多redis实例，那么这台主机也将占用大量的带宽。如果你的集群规模过大，可以按照业务逻辑将集群划分为多个小集群，同时适当的调大cluster-node-timeout的值，减少网络通信的开销。同时将集群节点均匀的部署到更多的主机上。

故障转移异常

故障转移失败主要包括如下的情况：
1、集群主节点过少，如只有2个，那么故障的节点如果是主节点，将无法客观下线，从而无法完成故障转移。我们一般需要至少配置3个主节点，允许至少一个主节点故障。
2、故障转移在如下的场景可能失败：
1）redis会检查从节点与主节点的断开时间，有可能会导致所有的节点都没有资格当选主节点，为此需要合理设置cluster-slave-validity-factor参数的值。
2）主节点与全部从节点都故障，比如网络分区，主节点与从节点一般需要部署到不同的主机不同的机架甚至不同的机房。但是即使这样部署还是有概率出现全部故障。
3）网络不稳定故障转移总是失败。
4）大部分主节点故障。
为此Redis还提供了如下的命令

cluster failover force：适用于第一与第二种情况，执行命令的从节点会立即发起选举，选举成功后替换为主节点。
cluster failover takeover：适用于第三与第四种情况，不会走正常的故障转移流程，会导致配置纪元冲突。不建议使用

另外添加主节点的时候，与raft类型，只能单节点添加