作者：neoremind
出处:http://neoremind.com/2018/03/…

音讯队列作为服务 / 利用之间的通信中间件，能够起到业务耦合、播送音讯、保障最终一致性以及错峰流控（克服短板瓶颈）等作用。本文不打算具体深刻解说音讯队列，而是体系化的梳理音讯队列可能波及的技术点，起到提纲挈领的作用，结构一个宏观的概念，应用思维导图梳理。

再介绍之前，先简短比拟下 RPC 和音讯队列。RPC 大多属于申请 - 应答模式，也包含越来越多响应式范式，对于须要点对点交互、强事务保障和提早敏感的服务 / 利用之间的通信，RPC 是优于音讯队列的。那么音讯队列（下文也简称 MQ，即 Message Queueu）能够看做是一种异步 RPC，把一次 RPC 变为两次，进行内容转存，再在适合的机会投递进来。音讯队列中间件往往是一个分布式系统，外部组件间的通信依然会用到 RPC。

目前开源界用的比拟多的选型包含，ActiveMQ、RabbitMQ、Kafka、阿里巴巴的 Notify、MetaQ、RocketMQ。下文的技术点梳理也是学习借鉴了这些开源组件，而后萃取出一些通用技术点。

对于音讯队列的体系化认知，见下方的思维导图。

1. 整体架构

个别分为 producer，broker，consumer 三者。

2. RPC 通信

具体参考《体系化意识 RPC》（http://www.infoq.com/cn/artic…）。

3. 高性能保障

次要思考 MQ 的提早和吞吐。

高性能投递方面，分为 producer 和 broker 思考。producer 能够同步变异步、单条变批量保障发送端高性能，批量发送的触发条件能够分为 buffer 满或者工夫窗口到了。broker 能够进行多 topic 划分，再多分区 /queue 来进行分治（Divide and Conquer）策略，加大并行度，扩散投递压力。另外 broker 对于须要长久化的音讯，能够应用程序 IO，page cache，异步刷盘等技术进步性能，然而异步刷盘在掉电的状况下，可能会失落数据，能够联合上面的高可用计划，在数据严格不丢和高性能吞吐之间做折中。

高性能生产，即 consumer 和 broker 通信，进行推、拉音讯。应用 consumer group 程度扩大生产能力，须要依照业务场景应用分区有序或者无序生产。零拷贝技术节俭 broker 端用户态到内核态的数据拷贝，间接从 page cache 发送到网络，从而最大化发送性能。consumer 批量 pull，broker 批量 push。broker 端还能够做音讯过滤，可通过 tag 或者插件实现。

4. 高可用保障

次要针对 broker 而言。

集群高可用，producer 通过 broker 投递音讯，所以必然有且仅有一个 broker 主负责“写”，选主策略分为主动选主和非被动抉择，主动选主应用散布一致性组件实现，例如 Kafka 应用 zookeeper，非主动选主，例如 RocketMQ 依赖多个无状态的 name server。

数据高可用，针对 broker 长久化积压音讯场景。可借助分布式存储实现，然而往往性能上是个短板，所以大多数主流产品都进行本地 IO 程序写，进行主从备份，多正本拷贝保障可用性，例如 RocketMQ 分为同步双写和异步复制，前者像 HDFS 一样，写完多个正本再返回 producer 胜利，有肯定性能损失，但不大，后者最大化性能，然而当主挂的时候，数据有失落危险。

同样，MQ 集群也须要思考跨机房高可用（非“异地多活”），broker 的写高可用，要思考最小化 MTTR，同时不阻塞 consumer 生产。

5. 扩展性保障

采纳分治（Divide and Conquer）策略，加大投递和生产的并行度，多个 topic、多个分区 /queue、多个正本、多个 slave 或者镜像。

6. 协定

producer、consumer 和 broker 通信的协定，包含 AMQP、STOMP、MQTT、HTTP、OpenWire（ActiveMQ）、XMPP、自定义等等。

AMQP 是比拟全面和简单的一个协定，包含协定自身以及模型（broker、exchange、routing key 等概念），目前 RabbitMQ 是 AMQP 音讯队列最有名的开源实现，有十分多语言曾经反对基于 AMQP 协定与音讯队列通信，同时还能够通过插件反对 STOMP、MQTT 等协定接入。Kafka、RocketMQ 均应用自定义的协定。

7. 生产关系

包含三种

1) 点对点，也就是 P2P，FIFO 的队列，能够看做单播。

2) Topic 模式，Pub/Sub 公布订阅。

3) fanout 播送模式。

8. 音讯沉积能力

长久化音讯，如果存储在本地磁盘，能够应用同步刷盘和异步刷盘两种策略。磁盘不能有限沉积，会有清理策略，例如 Kafka、RocketMQ 都依照工夫、数据量进行 retention。

非长久化，仅放在内存，消费者解决完可抉择删除掉。

9. 牢靠投递

对于 producer，从 API 和 I / O 层面可应用同步、异步，对于吞吐层面可应用单条、批量。fire-and-forget 模式，相似 UDP，只管发送即可。针对可能产生的谬误，例如连贯 broker 失败，RPC 超时、公布音讯失败、公布后无响应，可抉择疏忽或者重发，所以往往反复投递的状况不可避免。

对于 broker，如果要保证数据 100% 不丢，是可能的，然而须要就义下性能和吞吐，应用同步多写、多正本策略 + 同步刷盘长久化音讯，能够严格保障不丢。另外，broker 对于写入音讯的 payload，也会做完整性校验，例如 CRC 等。

10. 牢靠生产

生产次数，包含 at most once、at least once、exactly once，其中前两个比拟好做到，最初的 exactly once 须要 streaming consumer 零碎和 broker 端合作实现，例如 storm 的 trident 和 flink。

推拉模式，push or pull。推模式最小化投递提早，然而没有思考 consumer 的承载能力，拉个别是轮询接管 broker 的数据，依照 consumer 本人的能力生产。

生产记录点，个别每个音讯都有一个 offset、ID 或者工夫戳，consumer 能够依照这个 offset 来进行定点生产以及音讯重放。

音讯确认，consumer 生产实现 ACK 回调 broker 或者集群高可用中间件（zk）告诉生产进度。

错误处理，对于生产失败的状况，能够回复 NACK，要求重发 /requeue 音讯，当谬误超多肯定阈值时候，放到死信队列中。

音讯反复生产，这和生产次数有关系，consumer 在某些时候须要做到幂等性，保障反复生产不会引起业务异样。

11. 音讯类型

程序音讯，有序的话，分为分区有序或者全局有序，前者能够依照某个业务 ID 取模，在发送端发到不同的分区 /queue 即可，后者往往须要单个队列才能够满足。无序生产则可最大化吞吐。

定时音讯，事务音讯，例如 RocketMQ 均反对。

12. 音讯查问

目前 RocketMQ 反对音讯依据 msgId 查问。

13. 生态交融

客户端语言的丰富性，与其余零碎的集成度，例如 Kafka 和大数据技术栈交融很严密，Spark、Storm、Flink、Kylin 都有对应的 connector。

14. 管理工具

分布式系统的治理是进步生产效率的必备保障，一个好的零碎，如果周边工具不欠缺，对于使用者会很不敌对，推广也会有艰难。

对于音讯队列，能够从 topic 治理、broker 治理、集群治理、权限 / 配额治理、多租户、客户端工具、监控、报警、控制台 Console UI 来全方位进行治理。