高并发架构演进：Redis 三主三从 Cluster 极限压测与性能瓶颈剖析

继上一篇完成了 Redis 三主三从 Cluster 集群 的本地搭建与核心机制解析后，这套架构已经具备了理论上的高可用与数据分片能力。但纸上得来终觉浅，真正的架构必须要在高并发的炮火中去检验。

这期博客，我将直接进入实战：对这套三主三从集群进行千万级请求的极限压力测试，并借助可视化工具深度“解剖”集群在面对超高并发时的物理特征与性能瓶颈。

🚀 集群启动与状态检查

首先，我依然使用之前编写好的脚本，一键拉起所有 6 个 Redis 实例：

1	bash start_redis_cluster.sh

启动完成后，需要确认集群的健康状态以及哈希槽的分配情况。使用以下命令查看主从关系和 Slot 分布：

1	redis-cli -p 7001 cluster nodes

集群启动和状态检查

确认无误后，真正的考验开始了。

为了模拟真实企业级微服务场景下的大流量洪峰，我准备使用 Redis 自带的压测工具 redis-benchmark 对集群发起高强度的读写测试。

执行以下疯狂写入的压测命令：

1	redis-benchmark -h 192.168.121.140 -p 7001 -c 1000 -n 2000000 --cluster

压力测试命令

top命令数据

压测期间，我使用 Redis Insight 实时连接到了集群，抓取了测试前与测试峰值时期的数据看板。

Redis Insight 压测前数据面板

Redis Insight 压测时数据对比面板

通过把并发连接数拉升到 1000，这套 Redis 集群展现出了与平稳期完全不同的物理特征。我们来深度“解剖”一下这张图里隐藏的技术细节，里面有几个非常经典的现象：

看图说话：看压测时的数据面板最右侧的 Clients 列，三个主节点的连接数分别是 334, 335, 334。
原理解析：它们加起来正好是 1003（包含了 1000 个压测并发 + 3 个后台监控连接）。这完美地证明了 --cluster 参数在高效工作，它像一个公平的发牌员，把 1000 个高并发长连接均匀地分摊给了三台机器，没有任何一个节点被“偏袒”或“撑爆”。在企业生产环境中，这正是我们梦寐以求的健康状态。

看图说话：注意看压测时面板左侧的 Memory 圆环，总内存达到了 67.328 MB（每个节点平均约 22.4 MB）。而在压测前的平稳状态下，集群的总内存仅有 7.817 MB（每个节点约 2.6 MB）。
原理解析：这就是非常典型的“基础内存占用”。虽然业务 Key 的数量总共只有 12 个（几乎不占空间），但为了维持这多出来的 1000 个并发连接，Redis 必须在 CentOS 的内存里为每一个连接开辟专属的输入/输出缓冲区（Buffer）。在生产环境中排查内存泄漏或内存不足时，千万不要忘了算这笔昂贵的“连接费”。

这是一个极其宝贵的性能拐点现象！

看图说话：在 1000 并发下，顶部的数据看板显示总请求频率（Commands/s）定格在了 27,361 QPS。
原理解析：回忆一下，在 100 并发的时候，测试跑出的 QPS 大概在 34,000 左右。现在并发量翻了 10 倍，为什么处理速度不仅没有成倍增长，反而还出现了一定程度的下降？
答案是：CPU 的上下文切换（Context Switch）瓶颈。 虚拟机的 CPU 现在太忙了，它要在 1000 个不同的网络 Socket 之间疯狂切换来读取数据。这种底层切换消耗的算力，甚至超过了 Redis 真正执行 SET/GET 命令的算力。虚拟机的性能极限，在这个配置下，大概就是 3 万 QPS 左右。

这是一个非常中规中矩且极具代表性的场景。在真实的微服务业务中，1000 个并发连接是非常常见的。目前的测试表明，集群表现非常稳定（没有崩溃，内存分配均匀，路由精准），但同时也彻底暴露出了当前虚拟机 CPU 处理网络 I/O 的极限。

接下来的思考与架构演进：

既然我们已经看清了本地环境在高并发下的物理天花板(我的个人PC)，与其继续在 QPS 的吞吐量上死磕，不如回到分布式架构中最核心、最惊心动魄的命题——集群的高可用与容灾自愈（Failover）。

在真实的生产环境中，高并发往往伴随着机器宕机的风险。如果这三个主节点中的某一个突然“掉线”，整个集群将会迎来怎样的考验？

下一期博客，我将直接切断节点网络，深度探究以下三个核心问题：