消息隊列(三)

順序消息

消息有序指的是能夠按照消息的發送順序來消費。例如：一筆訂單產生3條消息，分別建立訂單消息、訂單支付消息、訂單物流消息。消費時，須要按照順序依次消費纔有意義，與此同時多筆訂單能夠又並行消費。

在部分消息隊列，例如RabbitMQ，若是多個消費者同時從服務器消費消息，會形成消息異步的發送給各個消費者，這樣就會形成消息的無序。在一些消息隊列，例如Kafka、RocketMQ使用分區(parttion)的概念，使得消息可以有序且可以併發的處理消息。

全局順序

首先對於單生產者和單消費者這種狀況下可以保證消息的有序。好比上訴狀況下，消費者把生成的3條消息放入隊列中，因爲只有一個消費者，因此可以保證有序。可是當有多個消費者或者說多個消費線程狀況下就會出現無序。

分區順序

分區順序是部分消息隊列支持，例如Kafka、RocketMQ。在生產者發送消息時，若是指定分區(parttion)，那麼消息就會發給到該分區下的隊列，保證有序。在消費端，消息隊列保證1個分區只能被一個Consumer消費，這樣咱們就能夠多個Consumer併發的處理有序消息。注意：這裏消息有序指的是一個分區下的消息有序，併發的處理消息指的是消費者能夠併發的處理多個分區消息。這樣，經過分區的概念，把併發和有序都可以很好的解決。注：圖來自順序消息

對於指定的一個 Topic，全部消息根據 sharding key 進行區塊分區。同一個分區內的消息按照嚴格的 FIFO 順序進行發佈和消費。Sharding key 是順序消息中用來區分不一樣分區的關鍵字段，和普通消息的 Key 是徹底不一樣的概念。

分區順序的例子：電商的訂單建立，以訂單 ID 做爲 sharding key，那麼同一個訂單相關的建立訂單消息、訂單支付消息、訂單退款消息、訂單物流消息都會按照前後順序來發布和訂閱。

消息持久化

消息持久化主要是在消息隊列服務器掛掉的狀況下，消息不會消失。也就是說在MQ-Server接收到消息後會把消息持久化到磁盤，這樣在MQ-Server掛點的狀況下也能夠從磁盤中恢復。這裏持久化主要有兩種方式：

• 同步持久化： 同步持久化指的是消息到達MQ-Server後會同步持久化到磁盤中才算真正的接收消息，纔會回調SendCallback接口。這樣的話缺點是須要較長時間，畢竟寫磁盤比寫內存慢多了。
• 異步持久化 異步持久化值的是消息到達MQ-Server後會異步的持久化到磁盤中。這樣的話缺點是若是在持久化過程當中，MQ-Server掛點會致使該條消息的丟失。

消息消費模式

各類消息隊列有不一樣的消費模式，每一個消息隊列對於消費模式有不一樣的叫法，可是其實質基本相同，下面介紹兩種消費模式：

P2P模式

P2P模式也叫直連模式，指的是生成者生成的消息生成的消息只由一個消費者消費。圖來自網絡：

Pub/Sub模式

Pub/Sub模式也叫發佈訂閱模式，其與設計模式中的觀察者模式相似。消費者把消息發送給某一主題(Topic)，對這一主題感興趣的全部消費者都會接收到該消息。圖來自網絡：

消息隊列的其它特性

消息隊列還支持許多不一樣的特性，本身僅僅把一些特性列出來，本身也不太懂，之後寫：

• 定時消息
• 消息的存儲和消息的堆積
• 消息隊列對事務的支持
• ...

Reference

http://www.wangzhe.tech/kafka/Kafka%E4%BF%9D%E8%AF%81%E6%B6%88%E6%81%AF%E7%9A%84%E6%9C%89%E5%BA%8F%E6%80%A7/2017/06/18/
https://codeday.me/bug/20171210/105056.html
http://blog.csdn.net/chunlongyu/article/details/53977819
http://dbaplus.cn/news-21-1123-1.html
https://tech.meituan.com/mq-design.html
https://cloud.tencent.com/document/product/406/8303
https://www.jianshu.com/p/453c6e7ff81c