auto commit

notes/消息队列.md

@@ -1,27 +1,22 @@
+# 消息队列
 <!-- GFM-TOC -->
-* [一、消息模型](#一消息模型)
-    * [点对点](#点对点)
-    * [发布/订阅](#发布订阅)
-* [二、使用场景](#二使用场景)
-    * [异步处理](#异步处理)
-    * [流量削锋](#流量削锋)
-    * [应用解耦](#应用解耦)
-* [三、可靠性](#三可靠性)
-    * [发送端的可靠性](#发送端的可靠性)
-    * [接收端的可靠性](#接收端的可靠性)
-* [参考资料](#参考资料)
+* [消息队列](#消息队列)
+    * [一、消息模型](#一消息模型)
+    * [二、使用场景](#二使用场景)
+    * [三、可靠性](#三可靠性)
+    * [参考资料](#参考资料)
 <!-- GFM-TOC -->
 
 
-# 一、消息模型
+## 一、消息模型
 
-## 点对点
+### 点对点
 
 消息生产者向消息队列中发送了一个消息之后，只能被一个消费者消费一次。
 
 <div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/image-20191212011250613.png"/> </div><br>
 
-## 发布/订阅
+### 发布/订阅
 
 消息生产者向频道发送一个消息之后，多个消费者可以从该频道订阅到这条消息并消费。
 
@@ -34,9 +29,9 @@
 
 <div align="center"> <img src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/image-20191212011747967.png"/> </div><br>
 
-# 二、使用场景
+## 二、使用场景
 
-## 异步处理
+### 异步处理
 
 发送者将消息发送给消息队列之后，不需要同步等待消息接收者处理完毕，而是立即返回进行其它操作。消息接收者从消息队列中订阅消息之后异步处理。
 
@@ -44,27 +39,27 @@
 
 只有在业务流程允许异步处理的情况下才能这么做，例如上面的注册流程中，如果要求用户对验证邮件进行点击之后才能完成注册的话，就不能再使用消息队列。
 
-## 流量削锋
+### 流量削锋
 
 在高并发的场景下，如果短时间有大量的请求到达会压垮服务器。
 
 可以将请求发送到消息队列中，服务器按照其处理能力从消息队列中订阅消息进行处理。
 
-## 应用解耦
+### 应用解耦
 
 如果模块之间不直接进行调用，模块之间耦合度就会很低，那么修改一个模块或者新增一个模块对其它模块的影响会很小，从而实现可扩展性。
 
 通过使用消息队列，一个模块只需要向消息队列中发送消息，其它模块可以选择性地从消息队列中订阅消息从而完成调用。
 
-# 三、可靠性
+## 三、可靠性
 
-## 发送端的可靠性
+### 发送端的可靠性
 
 发送端完成操作后一定能将消息成功发送到消息队列中。
 
 实现方法：在本地数据库建一张消息表，将消息数据与业务数据保存在同一数据库实例里，这样就可以利用本地数据库的事务机制。事务提交成功后，将消息表中的消息转移到消息队列中，若转移消息成功则删除消息表中的数据，否则继续重传。
 
-## 接收端的可靠性
+### 接收端的可靠性
 
 接收端能够从消息队列成功消费一次消息。
 
@@ -73,14 +68,7 @@
 - 保证接收端处理消息的业务逻辑具有幂等性：只要具有幂等性，那么消费多少次消息，最后处理的结果都是一样的。
 - 保证消息具有唯一编号，并使用一张日志表来记录已经消费的消息编号。
 
-# 参考资料
+## 参考资料
 
 - [Observer vs Pub-Sub](http://developers-club.com/posts/270339/)
 - [消息队列中点对点与发布订阅区别](https://blog.csdn.net/lizhitao/article/details/47723105)
-
-
-
-
-
-
-<div align="center"><img width="320px" src="https://cs-notes-1256109796.cos.ap-guangzhou.myqcloud.com/githubio/公众号二维码-2.png"></img></div>