初探消息队列 ｜ 青训营笔记

这是我参与「第三届青训营-后端场」笔记创作活动的的第5篇笔记

RPC（Remote Procedure Call）即远程过程调用，简单的说就是在A机器上去调用B机器上的某个方法，在分布式系统中极其常用。

消息队列是用来处理系统出现高并发导致消息阻塞的情况，如果你的系统不存在高并发或者不会出现消息阻塞，那你就不需要消息队列。

概述

消息队列中间件是分布式系统中的重要组件，可帮助解决应用耦合、消息异步、流量削峰等问题。

因为其高性能、高可用性及可伸缩性，消息队列已经成为大型分布式系统不可缺少的中间件。目前常用的ActiveMQ\RabbitMQ\Kafka\ZeroMQ等。

应用场景

1. 异步处理：例如短信通知、终端状态推送、App推送、用户注册等
2. 数据同步：业务数据推送同步
3. 重试补偿：记账失败重试
4. 系统解耦：通讯上下行、终端异常监控、分布式事件中心
5. 流量消峰：秒杀场景下的下单处理
6. 发布订阅：HSF的服务状态变化通知、分布式事件中心
7. 高并发缓冲：日志服务、监控上报

这个地方总结的比较简练，如果不是很理解细节可以看看其他博客，会有图文并茂的解释。

　　

消息模型 

有两种消息模型P2P（Point to Point）m,Publish/Subscribe(Pub/Sub)。

P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。

P2P的特点：

1. 每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
2. 发送者和接收者之间在时间上没有依赖性，也就是说发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
3. 接收者在成功接收消息之后需向队列应答成功 如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式。

Pub/Sub模式

包含三个角色主题（Topic），发布者（Publisher），订阅者（Subscriber） 多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

Pub/Sub的特点：

1. 每个消息可以有多个消费者
2. 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息
3. 为了消费消息，订阅者必须保持运行的状态
4. 为了缓和这样严格的时间相关性，允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。 如果希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型。

消息消费

消息的产生和消费都是异步的。对于消费来说，消费者可以通过两种方式来消费消息。

（1）同步

订阅者或接收者通过receive方法来接收消息，receive方法在接收到消息之前（或超时之前）将一直阻塞；

（2）异步

订阅者或接收者可以注册为一个消息监听器。当消息到达之后，系统自动调用监听器的onMessage方法。