定位思路与快速判断
- 明确“message”的类型：是本地进程间通信的System V 消息队列/ POSIX 消息队列，还是分布式消息中间件（如 RabbitMQ、Kafka、RocketMQ）。两者的瓶颈点完全不同。
- 用系统指标快速定位维度：
- CPU：关注 %user + %sys，持续高于 85% 多为 CPU 瓶颈；
- 内存：关注 si/so（swap in/out），不为 0 表示内存紧张；
- 磁盘：iowait %，高于 35% 常见磁盘瓶颈；
- 网络：带宽打满、丢包/重传、连接队列满（如 net.core.somaxconn 不足）。
- 用工具确认：先用 top/vmstat/sar/iostat/netstat 看全局，再用 perf/strace 抓热点函数与系统调用，定位到具体组件与代码路径。
本地 System V 或 POSIX 消息队列的常见瓶颈
- 内核参数限制：单条消息上限 kernel.msgmax、队列最大字节数 kernel.msgmnb、队列数量 kernel.msgmni 过小，会触发频繁错误/阻塞与扩容重试，形成吞吐天花板。
- 消息尺寸与拷贝：消息过大或频繁在用户/内核态拷贝，导致 CPU sys 升高；小消息高 QPS 场景下，系统调用与队列锁竞争会放大。
- 并发与调度：多进程/线程争抢队列锁与 CPU 时间片，单队列难以吃满多核；需要按业务拆分队列或改为多队列并行。
- 资源与配置：文件描述符上限、内存不足引发 page reclaim 抖动，都会转化为时延尖峰与吞吐下降。
分布式消息中间件在 CentOS 的常见瓶颈
- 硬件与网络：CPU、内存、磁盘 I/O 不足或网络带宽/时延不够，直接限制吞吐与延迟；跨机房/广域网集群表现更明显。
- 持久化与存储：开启消息持久化会放大磁盘 I/O；PageCache 回收不及时会引发 OOM/Killer 或吞吐“毛刺”，表现为周期性 TPS 抖动。
- 队列与镜像：队列积压、消费者数量/处理能力不匹配；RabbitMQ 的镜像队列在同步复制时占用大量内网带宽并降低性能。
- 配置不当：RabbitMQ 的 prefetch_count、内存水位 vm_memory_high_watermark、磁盘/惰性队列策略等未调优；Kafka 的 num.partitions、网络/IO 线程数不合理，都会限制并行度与稳定性。
面向 CentOS 的优化要点
- 本地消息队列：
- 适度调大 kernel.msgmax / kernel.msgmnb / kernel.msgmni，避免队列/消息规模触顶；
- 控制消息体大小与批量发送，减少系统调用次数；
- 按业务拆分多个队列，提升并发度与缓存命中。
- RabbitMQ：
- 合理设置 prefetch_count（如 100–300），平衡吞吐与内存；
- 非关键场景可关闭持久化以降 I/O；按负载设置 vm_memory_high_watermark；
- 优先使用 Lazy Queue 降低内存压力；谨慎使用镜像队列，避免跨节点同步放大带宽占用。
- Kafka：
- 主题 分区数≈2–3×Broker 数 提升并行度；
- 增加 num.network.threads / num.io.threads 以支撑高并发请求。
- 系统与网络：
- 优化 TCP：net.core.somaxconn=65535、net.ipv4.tcp_tw_reuse=1、net.ipv4.tcp_fin_timeout=30；
- 监控 iowait、si/so、带宽/丢包，必要时升级磁盘/网卡或做队列削峰。
