rabbitq消息隊列分析

消息隊列為什么要使用消息隊列解耦擴展性異步通信……消息隊列要解決的其它問題送達保證流量控制/緩沖保證時序主要的使用舉例場景（概念圖）單模塊對單模塊Waybill推送訂單給區(qū)域模塊用來排線使用。主要的使用舉例場景（概念圖）單模塊對多模塊（多消息類型）三體需要發(fā)送線路任務(wù)和每日運力，同時用于時效監(jiān)控和財務(wù)。多模塊對單模塊（多消息類型）問題和風險下游模塊之間相互影響（消費能力）。存在消息優(yōu)先級問題。（優(yōu)先級的定義？）需要同時接收多數(shù)據(jù)類型。rabbitmq的概念和特點用戶權(quán)限控制的粒度為VirtualHost（可以理解為命名空間）。所有的數(shù)據(jù)都只能發(fā)送給rabbit的exchange。Exchange分為三種模式：fanout，direct，topic。在發(fā)送和接收數(shù)據(jù)的時候要指定queuename?？梢猿志没瘮?shù)據(jù)。只有pull的方式。有ack的機制。rabbitmq的解決方案下游模塊之間相互影響每個模塊使用獨立的queue（name），模塊之間無干擾。沒有辦法接收多種數(shù)據(jù)類型。rabbitmq的解決方案同時接收多種數(shù)據(jù)類型單個隊列可以接收多種不同類型的數(shù)據(jù)。存在嚴重的優(yōu)先級問題。封裝策略其他模塊在架構(gòu)中對rabbitmq無感：將pull的方式修改成push的方式。pusher根據(jù)下游使用方式的要求，可以同時接一個或者多個queuequeuename由Pusher來自行決定，下游不關(guān)注。屏蔽了rabbitmq奇怪的noack機制解決多下游的競爭機制不完善的。（消息會亂序）增加了轉(zhuǎn)運功能，將單條1*N的數(shù)據(jù)拆分成N*1的數(shù)據(jù)，然后下發(fā)。隊列的接收方需要自行決定數(shù)據(jù)是繼續(xù)處理還是跳過。隊列的接收方需要保證自己的邏輯冪等+可重入。解決方案（PHP）未封裝的功能沒有主動數(shù)據(jù)回放的機制。不區(qū)分完全時序和相對時序。封裝之后的使用（PHP）21:8095/display/beeper/rabbitmqExchange：每個模塊獨立一個exchange，exchange按照模塊名稱命名，exchange不允許在代碼中自動創(chuàng)建。在Pusher新增Queue：命名方式exchange.功能.下游名稱，允許代碼自動創(chuàng)建。漫話架構(gòu)絕對原創(chuàng)，一笑了之為什么大家都想做架構(gòu)師掙錢多好跳槽讓別人覺得牛X可以對小弟呼來喝去更多……全宇宙中最常出現(xiàn)的架構(gòu)web代碼Mysql架構(gòu)（Architecture）框架（Framework）什么是軟件架構(gòu)軟件架構(gòu)不是軟件，而是關(guān)于軟件設(shè)計的一種決策。架構(gòu)是問題的抽象解決方案，它主要關(guān)注大局。軟件架構(gòu)定義系統(tǒng)的技術(shù)選型。軟件架構(gòu)決策如何將軟件系統(tǒng)分解成不同的部分，以及各個部分之間的交互關(guān)系。軟件架構(gòu)約束整個系統(tǒng)的數(shù)據(jù)流。經(jīng)過完整的開發(fā)過程之后，這些架構(gòu)決策將要體現(xiàn)在最終開發(fā)出的軟件系統(tǒng)中。架構(gòu)師存在是為了什么做設(shè)計決策為設(shè)計決策失敗承擔責任為開發(fā)不到位引起的失敗承擔責任為測試不到位引起的失敗承擔責任為性能不滿足引起的失敗承擔責任為穩(wěn)定性不滿足引起的失敗承擔責任為所有最終交付之前出現(xiàn)的任何技術(shù)錯誤導(dǎo)致的失敗承擔責任成功架構(gòu)師需要具備的XX經(jīng)驗權(quán)利能力前瞻性變通運氣TMS的架構(gòu)設(shè)計原則優(yōu)先業(yè)務(wù)功能：分析真實的業(yè)務(wù)需求。業(yè)務(wù)后續(xù)的可能演進方向。將業(yè)務(wù)需求轉(zhuǎn)變成通用的技術(shù)需求其他的考慮：盡量少依賴第三方和開源。和外部功能解耦。在需求的基礎(chǔ)上做少量的技術(shù)規(guī)劃。新建派車單和對外API接口（PM）政策需要新建立派車單和配送點。要求可以通過API接口和外部系統(tǒng)交互。要求可以根據(jù)派車單維度查詢司機的在途位置。對策需要承載派車單和訂單數(shù)據(jù)實體和邏輯。需要規(guī)劃新的模塊API接口對外，為了安全性，需要添加鑒權(quán)機制，為了擴展和部署。在代碼和邏輯上都獨立開派車單維度查詢位置。派車單的執(zhí)行主體是司機，所以將數(shù)據(jù)維度轉(zhuǎn)換成按照司機+時間保存。語言/存儲和公司統(tǒng)一node.js+mongodb。功能之間對數(shù)據(jù)庫的訪問獨立。派車單模板、排線和地址查詢功能（PM）政策創(chuàng)建派車單太麻煩，需要只填寫一次，創(chuàng)建一堆。要求引入訂單的概念。要求支持排線功能。排線需要依賴坐標，需要地址和坐標轉(zhuǎn)換功能。對策公司語言限制放開，php+mysql。派車單模板生成派車單，放在一模塊（node.js+mongodb）。訂單，直接新模塊。新增區(qū)域，區(qū)域不是運單的屬性，也和司機無關(guān)，繼續(xù)新加模塊，單獨管理區(qū)域。有區(qū)域才能落點排線，排線和區(qū)域放一起。落點和訂單需要交互，但是不要求實時性，添加隊列，業(yè)務(wù)解耦。地址轉(zhuǎn)轉(zhuǎn)換涉及到很多人工的維護，直接獨立，方便后續(xù)獨立添加人工地址審核功能和地址檢索功能。Node.js+mongodb遷移php+mysql（架構(gòu)）政策原有的Node.js模塊線上各種超時日志，搞不定，換之…跨數(shù)據(jù)庫查詢，獲取數(shù)據(jù)的時候想死的心都有了。對策平移Node.js+mongodb的所有功能。派車單和訂單一直綁定出現(xiàn)，放在一個模塊。司機位置，在關(guān)系數(shù)據(jù)庫中需要考慮數(shù)據(jù)量問題，按照天分表。保證開發(fā)速度，協(xié)議依舊選擇HTTP。時效+異常功能（開發(fā)+PM）政策時效產(chǎn)品派車單+訂單維度的異常監(jiān)控和預(yù)警。對策時效，怎么看都和現(xiàn)在的東西不相關(guān)，也不在規(guī)劃范圍內(nèi)，隨便找個地方丟吧…時效需要依賴運力，引入隊列。異常監(jiān)控，這么重要的功能，又和