分布式架构核心组件之消息队列

消息队列已经逐渐成为分布式应用场景、内部通讯、以及秒杀等高并发业务场景的核心手段，它具备低耦合、可靠投递、广播、流量控制、最终一致性 等一系列功能。

不管是 RabbitMQ、RocketMQ、ActiveMQ、Kafka仍是其它等，都有的一些基本原理、术语、机制等，总结分享出来，但愿你们在使用消息队列技术的时候可以快速理解。

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.消息队列的选型和应用场景

以上是就是消息队列MQ技术的一些梳理和概括，但愿对你们有帮助。更多Redis系列、Dubbo微服务系列、数据库系列等高并发架构设计，具体请参考高并发架构专题。

若是对java微服务、分布式、高并发、高可用、大型互联网架构技术、面试经验交流。

能够加我架构圈子群:692-845-439 领取资料，群内天天更新资料，免费领取。