音讯队列曾经逐步成为分布式应用场景、外部通信、以及秒杀等高并发业务场景的外围伎俩，它具备低耦合、牢靠投递、播送、流量管制、最终一致性 等一系列性能。

无论是 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 + 大厂面试题答案》