一，引言

集群虽然具备高可用特性，能实现自动故障恢复，但是如果使用不当，也会存在一些问题：

1. 集群完整性问题

2. 集群带宽问题

3. 数据倾斜问题

   当数据出现 BigKey，进行数据处理使用了 Hash_tag 都会出现数据倾斜问题，导致部分节点负担少，部分节点负担中。

4. 客户端性能问题

   客户端在访问集群时，需要做节点的选择，读写分离的判断，插槽的判断，这些会影响客户端的性能。

5. 命令的集群兼容性问题

   在集群模式下 Mset，Mget 无法正常运行，因为他要求这些 key 在同一个插槽。

6. lua 和事务问题

   集群模式下无法运行 lua 和事务，因为是多个命令

二，集群完整性问题

三，集群带宽问题

集群节点之间会不断的互相 ping 来确定集群中其他节点的状态。每次 Ping 携带的信息至少包含：

• 插槽信息
• 集群状态信息

集群中节点越多，集群状态信息数据量也越大，10 个节点的相关信息可能达到 1kb，此时每次集群互通需要的带宽会非常高。

解决途径：

1. 避免大集群，集群节点数不要太多，最好少于1000，如果业务庞大，则建立多个集群。
2. 避免在单个物理机中运行太多Redis实例
3. 配置合适的cluster-node-timeout值

四，集群还是主从

单体 Redis（主从 Redis）已经能达到万级别的 QPS，也具备很强的高可用特性。如果主从能够满足业务需求的情况下，尽量不要搭建 Redis 集群。

• QPS（Queries Per Second， 每秒查询数）是衡量系统处理能力的一个重要指标。它表示一个服务器或系统每秒钟能够处理的查询或请求的数量。

• 在数据库或缓存系统（如 Redis）中，QPS 通常用来衡量系统在高并发情况下的性能。例如，如果一个 Redis 服务器的 QPS 为 10,000，这意味着它每秒可以处理 10,000 次读写请求。

• QPS 越高，系统的吞吐量就越大，处理请求的能力也就越强。然而，QPS 并不是唯一的性能指标，还需要结合延迟（Latency）、并发连接数等其他指标来全面评估系统的性能。