共计 2386 个字符，预计需要花费 6 分钟才能阅读完成。
音讯队列曾经逐步成为分布式应用场景、外部通信、以及秒杀等高并发业务场景的外围伎俩，它具备低耦合、牢靠投递、播送、流量管制、最终一致性 等一系列性能。
无论是 RabbitMQ、RocketMQ、ActiveMQ、Kafka 还是其它等，都有的一些基本原理、术语、机制等，总结分享进去，心愿大家在应用音讯队列技术的时候可能疾速了解 @mikechen
1. 音讯生产者、音讯者、队列
- 音讯生产者 Producer：发送音讯到音讯队列。
- 音讯消费者 Consumer：从音讯队列接管音讯。
- Broker：概念来自与 Apache ActiveMQ，指 MQ 的服务端，帮你把音讯从发送端传送到接收端。
- 音讯队列 Queue：一个先进先出的音讯存储区域。音讯依照程序发送接管，一旦音讯被生产解决，该音讯将从队列中删除。
2. 设计 Broker 次要思考
1）音讯的转储：在更适合的工夫点投递，或者通过一系列伎俩辅助音讯最终能送达消费机。
2）标准一种范式和通用的模式，以满足解耦、最终一致性、错峰等需要。
3）其实简略了解就是一个音讯转发器，把一次 RPC 做成两次 RPC。发送者把音讯投递到 broker，broker 再将音讯转发一手到接收端。
总结起来就是两次 RPC 加一次转储，如果要做生产确认，则是三次 RPC。
3. 点对点音讯队列模型
点对点模型 用于 音讯生产者 和 音讯消费者 之间 点到点 的通信。
点对点模式蕴含三个角色：
- 音讯队列 （Queue）
- 发送者 (Sender)
- 接收者 (Receiver)
每个音讯都被发送到一个特定的队列，接收者从队列中获取音讯。队列保留着音讯，能够放在 内存 中也能够 长久化，直到他们被生产或超时。
特点
- 每个音讯只有一个消费者（Consumer）(即一旦被生产，音讯就不再在音讯队列中)
- 发送者和接收者之间在工夫上没有依赖性
- 接收者在胜利接管音讯之后需向队列应答胜利
4. 公布订阅音讯模型 Topic
公布订阅模型蕴含三个角色：
- 主题 （Topic）
- 发布者 （Publisher）
- 订阅者 （Subscriber）
多个发布者将音讯发送到 Topic, 零碎将这些消息传递给多个订阅者。
特点
- 每个音讯能够有多个消费者：和点对点形式不同，公布音讯能够被所有订阅者生产
- 发布者和订阅者之间有工夫上的依赖性。
- 针对某个主题（Topic）的订阅者，它必须创立一个订阅者之后，能力生产发布者的音讯。
- 为了生产音讯，订阅者必须放弃运行的状态。
5. 点对点和公布订阅的区别
生产者发送一条音讯到队列 queue，只有一个消费者能收到。
发布者发送到 topic 的音讯，只有订阅了 topic 的订阅者才会收到音讯。
6. 音讯的程序性保障
基于 Queue 音讯模型，利用 FIFO 先进先出的个性，能够保障音讯的程序性。
7. 音讯的 ACK 机制
即音讯的 Ackownledge 确认机制，
为了保障音讯不失落，音讯队列提供了音讯 Acknowledge 机制，即 ACK 机制，当 Consumer 确认音讯曾经被生产解决，发送一个 ACK 给音讯队列，此时音讯队列便能够删除这个消
息了。如果 Consumer 宕机 / 敞开，没有发送 ACK，音讯队列将认为这个音讯没有被解决，会将这个音讯从新发送给其余的 Consumer 从新生产解决。
8. 最终一致性的设计思路
次要是用“记录”和“弥补”的形式。
本地事务保护业务变动和告诉音讯，一起落地，而后 RPC 达到 broker，在 broker 胜利落地后，RPC 返回胜利，本地音讯能够删除。否则本地音讯始终靠定时工作轮询一直重发，这样就保障了音讯牢靠落地 broker。
broker 往 consumer 发送音讯的过程相似，始终发送音讯，直到 consumer 发送生产胜利确认。
咱们先不理睬反复音讯的问题，通过两次音讯落地加弥补，上游是肯定能够收到音讯的。而后依赖状态机版本号等形式做判重，更新本人的业务，就实现了最终一致性。
如果呈现生产方解决过慢生产不过去，要容许生产方被动 ack error，并能够与 broker 约定下次投递的工夫。
对于 broker 投递到 consumer 的音讯，因为不确定失落是在业务处理过程中还是音讯发送失落的状况下，有必要记录下投递的 IP 地址。决定重发之前询问这个 IP，音讯解决胜利了吗？如果询问无果，再重发。
事务：本地事务，本地落地，弥补发送。本地事务做的，是业务落地和音讯落地的事务，而不是业务落地和 RPC 胜利的事务。音讯只有胜利落地，很大水平上就没有失落的危险。
9. 音讯的事务反对
音讯的收发解决反对事务，例如：在工作核心场景中，一次解决可能波及多个音讯的接管、解决，这应该处于同一个事务范畴内，如果一个音讯解决失败，事务回滚，音讯从新回到队列中。
10. 音讯的长久化
音讯的长久化，对于一些要害的外围业务来说是十分重要的，启用音讯长久化后，音讯队列宕机重启后，音讯能够从长久化存储复原，音讯不失落，能够持续生产解决。
11. 音讯队列的高可用性
在理论生产环境中，应用单个实例的音讯队列服务，如果遇到宕机、重启等零碎问题，音讯队列就无奈提供服务了，因而很多场景下，咱们心愿音讯队列有高可用性反对，例如
RabbitMQ 的镜像集群模式的高可用性计划，ActiveMQ 也有基于 LevelDB+ZooKeeper 的高可用性计划，以及 Kafka 的 Replication 机制等。
12. 音讯队列的选型和利用场景
具体请参考：高并发架构系列：分布式之音讯队列的特点、选型、及利用场景详解
以上
作者简介
陈睿 |mikechen,10 年 + 大厂架构教训,《BAT 架构技术 500 期》系列文章作者，分享十余年架构教训以及面试心得!
浏览 mikechen 的互联网架构更多技术文章合集
Java 并发 |JVM|MySQL|Spring|Redis| 分布式 | 高并发 | 架构师
关注「mikechen 的互联网架构」公众号，回复 【架构】 支付我原创的《300 期 + BAT 架构技术系列与 1000 + 大厂面试题答案》
