一,引言
集群虽然具备高可用特性,能实现自动故障恢复,但是如果使用不当,也会存在一些问题:
-
集群完整性问题
-
集群带宽问题
-
数据倾斜问题
当数据出现BigKey,进行数据处理使用了Hash_tag都会出现数据倾斜问题,导致部分节点负担少,部分节点负担中。
-
客户端性能问题
客户端在访问集群时,需要做节点的选择,读写分离的判断,插槽的判断,这些会影响客户端的性能。
-
命令的集群兼容性问题
在集群模式下Mset,Mget无法正常运行,因为他要求这些key在同一个插槽。
-
lua和事务问题
集群模式下无法运行lua和事务,因为是多个命令
二,集群完整性问题
三,集群带宽问题
集群节点之间会不断的互相ping来确定集群中其他节点的状态。每次Ping携带的信息至少包含:
- 插槽信息
- 集群状态信息
集群中节点越多,集群状态信息数据量也越大,10个节点的相关信息可能达到1kb,此时每次集群互通需要的带宽会非常高。
解决途径:
- 避免大集群,集群节点数不要太多,最好少于1000,如果业务庞大,则建立多个集群。
- 避免在单个物理机中运行太多Redis实例
- 配置合适的
cluster-node-timeout值
四,集群还是主从
单体Redis(主从Redis)已经能达到万级别的QPS,也具备很强的高可用特性。如果主从能够满足业务需求的情况下,尽量不要搭建Redis集群。
-
QPS(Queries Per Second, 每秒查询数)是衡量系统处理能力的一个重要指标。它表示一个服务器或系统每秒钟能够处理的查询或请求的数量。
-
在数据库或缓存系统(如Redis)中,QPS通常用来衡量系统在高并发情况下的性能。例如,如果一个Redis服务器的QPS为10,000,这意味着它每秒可以处理10,000次读写请求。
-
QPS越高,系统的吞吐量就越大,处理请求的能力也就越强。然而,QPS并不是唯一的性能指标,还需要结合延迟(Latency)、并发连接数等其他指标来全面评估系统的性能。