2018-07-28 01:05:53 +08:00
|
|
|
<!-- GFM-TOC -->
|
|
|
|
|
* [一、消息模型](#一消息模型)
|
|
|
|
|
* [点对点](#点对点)
|
|
|
|
|
* [发布/订阅](#发布订阅)
|
|
|
|
|
* [二、使用场景](#二使用场景)
|
|
|
|
|
* [异步处理](#异步处理)
|
|
|
|
|
* [流量削锋](#流量削锋)
|
|
|
|
|
* [应用解耦](#应用解耦)
|
|
|
|
|
* [三、可靠性](#三可靠性)
|
2018-07-28 01:08:20 +08:00
|
|
|
* [发送端的可靠性](#发送端的可靠性)
|
|
|
|
|
* [接收端的可靠性](#接收端的可靠性)
|
2018-07-28 01:05:53 +08:00
|
|
|
<!-- GFM-TOC -->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# 一、消息模型
|
|
|
|
|
|
|
|
|
|
## 点对点
|
|
|
|
|
|
|
|
|
|
消息生产者向消息队列中发送了一个消息之后，只能被一个消费者消费一次。
|
|
|
|
|
|
|
|
|
|
<div align="center"> <img src="../pics//09b52bcb-88ba-4e36-8244-b375f16ad116.jpg"/> </div><br>
|
|
|
|
|
|
|
|
|
|
## 发布/订阅
|
|
|
|
|
|
|
|
|
|
消息生产者向频道发送一个消息之后，多个消费者可以从该频道订阅到这条消息并消费。
|
|
|
|
|
|
|
|
|
|
<div align="center"> <img src="../pics//ddb5ff4c-4ada-46aa-9bf1-140bdb5e4676.jpg"/> </div><br>
|
|
|
|
|
|
|
|
|
|
发布与订阅模式和观察者模式有以下不同：
|
|
|
|
|
|
|
|
|
|
- 观察者模式中，观察者和主题都知道对方的存在；而在发布与订阅模式中，发布者与订阅者不知道对方的存在，它们之间通过频道进行通信。
|
|
|
|
|
- 观察者模式是同步的，当事件触发时，主题会去调用观察者的方法，然后等待方法返回；而发布与订阅模式是异步的，发布者向频道发送一个消息之后，就不需要关心订阅者何时去订阅这个消息。
|
|
|
|
|
|
|
|
|
|
<div align="center"> <img src="../pics//bee1ff1d-c80f-4b3c-b58c-7073a8896ab2.jpg"/> </div><br>
|
|
|
|
|
|
|
|
|
|
参考：
|
|
|
|
|
|
|
|
|
|
- [Observer vs Pub-Sub](http://developers-club.com/posts/270339/)
|
|
|
|
|
- [消息队列中点对点与发布订阅区别](https://blog.csdn.net/lizhitao/article/details/47723105)
|
|
|
|
|
|
|
|
|
|
# 二、使用场景
|
|
|
|
|
|
|
|
|
|
## 异步处理
|
|
|
|
|
|
|
|
|
|
发送者将消息发送给消息队列之后，不需要同步等待消息接收者处理完毕，而是立即返回进行其它操作。消息接收者从消息队列中订阅消息之后异步处理。
|
|
|
|
|
|
|
|
|
|
例如在注册流程中通常需要发送验证邮件来确保注册用户的身份合法，可以使用消息队列使发送验证邮件的操作异步处理，用户在填写完注册信息之后就可以完成注册，而将发送验证邮件这一消息发送到消息队列中。
|
|
|
|
|
|
|
|
|
|
只有在业务流程允许异步处理的情况下才能这么做，例如上面的注册流程中，如果要求用户对验证邮件进行点击之后才能完成操作的话，就不能再使用消息队列。
|
|
|
|
|
|
|
|
|
|
## 流量削锋
|
|
|
|
|
|
|
|
|
|
在高并发的场景下，如果短时间有大量的请求会压垮服务器。
|
|
|
|
|
|
|
|
|
|
可以将请求发送到消息队列中，服务器按照其处理能力从消息队列中订阅消息进行处理。
|
|
|
|
|
|
|
|
|
|
## 应用解耦
|
|
|
|
|
|
|
|
|
|
如果模块之间不直接进行调用，模块之间耦合度很低，那么修改一个模块或者新增一个模块对其它模块的影响会很小，从而实现可扩展性。
|
|
|
|
|
|
|
|
|
|
通过使用消息队列，一个模块只需要向消息队列中发送消息，其它模块可以选择性地从消息队列中订阅消息从而完成调用。
|
|
|
|
|
|
|
|
|
|
# 三、可靠性
|
|
|
|
|
|
2018-07-28 01:08:20 +08:00
|
|
|
## 发送端的可靠性
|
2018-07-28 01:05:53 +08:00
|
|
|
|
|
|
|
|
发送端完成操作后一定能将消息成功发送到消息队列中。
|
|
|
|
|
|
|
|
|
|
实现方法：
|
|
|
|
|
|
|
|
|
|
- 在本地数据库建一张消息表，将消息数据与业务数据保存在同一数据库实例里，这样就可以利用本地数据库的事务机制。事务提交成功后，将消息表中的消息转移到消息队列中，若转移消息成功则删除消息表中的数据，否则继续重传。
|
|
|
|
|
|
2018-07-28 01:08:20 +08:00
|
|
|
## 接收端的可靠性
|
2018-07-28 01:05:53 +08:00
|
|
|
|
|
|
|
|
接收端能够从消息中间件成功消费一次消息。
|
|
|
|
|
|
|
|
|
|
实现方法：
|
|
|
|
|
|
|
|
|
|
- 保证接收端处理消息的业务逻辑具有幂等性：只要具有幂等性，那么消费多少次消息，最后处理的结果都是一样的。
|
|
|
|
|
- 保证消息具有唯一编号，并使用一张日志表来记录已经消费的消息编号。
|
