轉自：http://www.cnblogs.com/lushilin/p/6209976.html（
魯仕林）
消息中間件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是否有互斥的消息正在發送
國內跨城市方案：
國際化數據互通方案：
