rabbitq消息隊(duì)列分析

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