消息队列MQ
参考资料：https://cloud.tencent.com/developer/article/2335397
https://www.cnblogs.com/hahaha111122222/p/18457859
消息队列是大型分布式系统不可缺少的中间件，也是高并发系统的基石中间件
消息队列
消息队列 Message Queue
消息队列是利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的构建。
消息队列主要解决应用解耦，异步消息，流量削峰等问题，实现高性能，高可用，可伸缩和最终一致性的系统架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。
异步处理
业务可并行，并且不需要阻塞等待处理的结果。
应用解耦
模块之间不需要直接通知，而是通过消息队列。
流量削峰
像秒杀活动，一般流量过大会导致应用挂掉。
而应用服务通过消息队列接收消息，消息队列就可以进行请求控制，比如可以设置最大接收数目，抛弃多余请求。
消息通讯
应用间数据通信。
常用消息队列比较
| 特性 | Kafka | RocketMQ | RabbitMQ | ActiveMQ |
|---|---|---|---|---|
| 单机吞吐量 | 10万级（极限可更高） | 10万级 | 万级（性能相对较低） | 千级到万级（性能一般） |
| 开发语言 | Scala（核心），Java | Java | Erlang | Java |
| 高可用 | 分布式，依赖 ZooKeeper（新版可选） | 分布式，支持多副本 | 支持集群和镜像队列（主从） | 支持主从、副本集群 |
| 消息延迟 | ms 级（堆积时可能升高） | ms 级 | us 级（低延迟） | ms 级 |
| 消息丢失 | 理论上不会丢失（开启 ACK 和持久化） | 理论上不会丢失（支持多副本 + 持久化） | 配置合理下可靠，默认情况存在丢失风险 | 默认持久化支持较弱，存在一定丢失可能 |
| 消费模式 | 拉取模式 | 推+拉模式 | 推+拉模式 | 推+拉模式 |
| 持久化 | 文件系统（顺序写入，性能高） | 文件为主，内存缓存 | 内存、磁盘，可接入数据库 | 文件为主 |
| 支持协议 | 自定义协议 | 自定义协议 | AMQP、XMPP、SMTP、STOMP | AMQP、MQTT、OpenWire、STOMP 等多协议支持 |
| 社区活跃度 | 高（Confluent 等活跃） | 中（阿里主导，国内活跃） | 高（社区大，文档丰富） | 较低（活跃度不如前几者） |
| 管理界面 | 第三方工具（如 Kafka Manager、Control Center） | 官方控制台，功能丰富 | 自带 Web 管理界面，功能强 | 自带 Web 控制台，功能一般 |
| 部署难度 | 中（原生依赖 ZooKeeper，需调优） | 低（部署简单，结构清晰） | 低（配置灵活，上手快） | 低（部署最为简单） |
| 部署方式 | 独立运行 | 独立运行 | 独立运行 | 独立运行或嵌入到应用中 |
| 成熟度 | 成熟（大规模使用，如 LinkedIn） | 成熟（阿里巴巴开源，国内支持好） | 成熟（广泛使用，AMQP 标准） | 成熟（历史悠久，但逐渐被替代） |
| 综合评价 | ✅ 优点：超高吞吐量、支持大数据处理场景； ❌ 缺点：延迟可能高，学习曲线略陡。 | ✅ 优点：性能强，稳定可靠，中文文档多； ❌ 缺点：协议不标准，兼容性差。 | ✅ 优点：部署简单，协议标准，路由机制灵活； ❌ 缺点：吞吐量低，性能瓶颈明显。 | ✅ 优点：历史悠久，协议支持多，语言兼容广； ❌ 缺点：社区活跃度低，可靠性一般。 |