nmq消息隊列解析

消息中間件NMQ

1.What is nmq?

nmq = new message queue;

一個通用消息隊列系統

爲在線服務設計

什麼是消息隊列？問什麼須要？有哪些功能？

消息隊列的本質：1.多個不一樣的應用之間實現相互通訊的一種異步傳輸模式2.異步3.解耦

業界有哪些比較好的mq？

yahoo YMB 、twitter Kestrel、amazon SQS、apache kafka

百度的nmq和bigpipe

那麼爲何會有這麼多的實現呢？

影響設計的關鍵需求：

1.數據安全性

2.傳輸實時性

3.時序需求

4.吞吐需求

5.消費方形態

6.消息關聯形態

如今介紹一下百度的nmq(看一下nmq的設計考量)：

1.項目起源於大社區

2.重複開發、分散運維；極大的人力浪費；

併發+時序的難點，讓rd頭疼

核心+單點的運維，讓op蛋疼

3.架構的發展，讓老的系統不在適合

4.業務的發展，對性能、可擴展性有了更高的要求；

mq的本質需求：

1.數據安全性————》其實還好

2.傳輸實時性————》要求很高

3.吞吐需求————》很大

4.時序需求————》真的須要

5.消費方形態————》多樣

6.消息關聯形態————》1vN

nmq的其餘需求：

1.集中運維

2.解耦

3.運維平臺化、自動化

4.完善的功能，強大的時序+併發控制

5.支持國際化數據互通

模型設計(第一個問題)

nmq是基於消息的隊列，仍是基於消費者的隊列

 

考慮點：

1.存儲容量

2.運維便利度

3.擴展性

4.開發成本

因此最終選擇應該基於消息自己。

模型設計(第二個問題)：

1.推或者拉

2.核心問題：誰維護信息？

爲了更加深刻的對「推」和「拉」這兩種模式進行對比，能夠將consumer分爲2類：

1.競爭模式：一個consumer模塊部署不少機器，但全部機器競爭消費同一份消息。

2.多主模式：一個consumer模塊部署不少機器，每一個機器都消費全量消息。

推模型的分析：

1.推模型是消息集中管理方式，消息隊列知道consumer的一切。

2.能夠支持2種consumer模式，容易實現各類策略。

3.優勢是靈活，什麼均可以作

4.缺點是耦合，消息隊列自己的運維是問題

拉模式分析

1.對多主的consumer：完美

消息隊列只負責消息的存儲和查詢

運維便利、架構清晰、簡單

2.對競爭的consumer：難以支持

兩種模式的選擇

1.競爭模式會是咱們從此的主流模式和大趨勢；

數據邏輯層和存儲引擎層的分離

數據的拆分和冗餘，都會在存儲引擎層實現

2.PHP模塊實現「拉」有必定的難度

3.實現策略的靈活性和重要，推模式有自然的優點

4.拉模式，會帶來更大的遷移代價

5.最終選擇「推」模式

消息標識：

1.msg = product+topic+cmd

2.product產品線標識

3.topic

按業務劃分的消息序列，邏輯上的概念，可小可大。

nmq只保證相同的topic內的命令時序

4.cmd消息類別的最終標識，不一樣topic之間能夠同名

模型：

1.proxy

消息惟一入口，以topic爲單位消息分流

2.topic-server(ts)

消息存儲。級聯和備份

3.pusher

消息發送，協議可擴展

nmq集羣圖片：

 

 nmq的擴展性設計：

1.垂直擴展

當接收同一個topic的consumer增多，致使pusher出現性能瓶頸。

能夠經過ts級聯擴展多個pusher解決，支持多級級聯

2.水平擴展

當一個topic的命令增多，致使超過單機ts性能極限

能夠經過將該topic拆分到多個ts解決；好比按照某個partition key進行拆分；拆分後，只有相同pk的消息才能保證時序。

運維設計

1.隊列的存儲粒度

一個ts內部的全部topic串行存儲於一個隊列中，共享一維transid；

犧牲性能換取簡單，易運維

2.主從同步和切換

ts級聯和備份合一；slave主動從master拉數據，配合資源定位，簡化主從切換步驟。

異步pipeline模式，強吞吐，支持跨機房。

 

 

併發+時序

1.一發一答的串行更新模式遠不能知足更新性能的需求

2.在併發的前提下，能夠作到按照某個key的時需保證；

具備相同key的消息，能夠保證時序

好比接貼吧發帖的命令的consumer，能夠經過配置作到不一樣發帖更新併發，但保證同一個吧的發帖是有序串行的；

3.實現

正在發送窗口+待發送窗口

發送先前check是否有互斥的消息正在發送

國內跨城市方案：

國際化數據互通方案：