????寫在前面的話：學(xué)而不思則罔，思而不學(xué)則殆。回顧和總結(jié)應(yīng)該是一種比較好的思考的方式，雖然在使用過程中也需要思考，但是那種思考有些碎片化。容易在長時(shí)間之后讓人沒有抓住總領(lǐng)和全局。所以，后面要開始試著慢一點(diǎn)，把所學(xué)所用慢慢記錄下來。

1. 消息方案的作用和應(yīng)用

? ? 異步解耦、削峰填谷。還可以利用消息的廣播機(jī)制用來作為分布式緩存同步的實(shí)現(xiàn)方案，以及在大數(shù)據(jù)時(shí)代下，對流式數(shù)據(jù)的收集，從而提供下游進(jìn)行大數(shù)據(jù)分析（kafka）

2. 主要關(guān)心的問題

? ? 『順序消息』：消費(fèi)嚴(yán)格遵守生產(chǎn)的順序。tradeoff：順序保障 vs 吞吐率、消息積壓。rocketMQ有實(shí)現(xiàn)-可以保證局部嚴(yán)格有序；淘寶notify沒有。作為業(yè)務(wù)系統(tǒng)的開發(fā)，在基于淘寶notify的情況下，在業(yè)務(wù)代碼層實(shí)現(xiàn)了一個(gè)保證消息順序的方案。

? ? ? ?業(yè)務(wù)解決的一個(gè)栗子：

? ? ? ?業(yè)務(wù)背景：消息接收量 萬TPS級；DB訪問量 10萬TPS級。而不同的消息可能是需要操作同一個(gè)用戶的賬戶，所以業(yè)務(wù)上是需要消費(fèi)端按照生產(chǎn)端的產(chǎn)生時(shí)序進(jìn)行處理的。

? ? ? ?技術(shù)背景：notify沒有順序消息的功能，不過能夠盡量按照消息產(chǎn)生的時(shí)序投遞給消費(fèi)者，但是在消息回彈的情況下，順序性就喪失了。

? ? ? ? 解決思路是1.利用上游業(yè)務(wù)順序信息（業(yè)務(wù)時(shí)間、index字段等）將同一個(gè)用戶的多個(gè)消息分到一組，組內(nèi)按照業(yè)務(wù)順序串行執(zhí)行，不同組之間并行執(zhí)行的方式 2. 錯(cuò)峰延遲執(zhí)行，消息基本檢查后先落DB，消息任務(wù)的執(zhí)行延遲。讓消息接受和業(yè)務(wù)執(zhí)行錯(cuò)峰，一方面減少鎖沖突，從而減低db壓力，另外保證大部分情況下消息已經(jīng)落地。

? ? 『重復(fù)消息』：大部分消息中間件都是只做at least once，而不做exactly once的。首先，重復(fù)的出現(xiàn)可能在發(fā)送端，可能在消費(fèi)端。因?yàn)榫W(wǎng)絡(luò)通訊本身的不可靠性，總是會出現(xiàn)A->B的情況下，A不知道B是否收到的問題。所以保證exactly once很困難，本質(zhì)上，如果重復(fù)被冪等攔截了，這個(gè)問題也就沒那么可怕了。所以大部分消息中間件都要求業(yè)務(wù)代碼實(shí)現(xiàn)冪等，而不是自己實(shí)現(xiàn)exactly once。

? ? 『事務(wù)消息』：消息機(jī)制初衷是用來異步解耦的，但是為了最終數(shù)據(jù)的一致性。在一些場景下，消息生產(chǎn)者是需要保證消息消費(fèi)者收到了自己的消息的。如果讓生產(chǎn)者感知到消費(fèi)者是否收到，然后再根據(jù)接受結(jié)果進(jìn)行后續(xù)處理，那么就喪失了異步解耦的目的了。此處就用到了2PC機(jī)制。消息預(yù)發(fā)送在生產(chǎn)者本地事務(wù)中，如果生產(chǎn)者自己的事情ok，那么就通知broker消息可以投遞給消費(fèi)者；否則不投遞。最后一點(diǎn)，還是存在網(wǎng)絡(luò)問題，生產(chǎn)者確認(rèn)和回滾的通知還是有可能因?yàn)榫W(wǎng)絡(luò)問題無法確認(rèn)。所以在rocketMQ中就是broker來進(jìn)行一個(gè)回查，需要生產(chǎn)者實(shí)現(xiàn)回查接口。（2PC+回查機(jī)制）

????『不丟失消息』：三個(gè)地方可能丟消息，生產(chǎn)者發(fā)送時(shí)丟了；在broker端丟了；broker投遞給消費(fèi)者的過程丟了。傳輸過程中的丟失，可以通過ack機(jī)制解決；broker端，則需要考慮自己存儲的方式，是否持久化。另外對于消費(fèi)端，還要考慮自己沒有正常消費(fèi)時(shí)，是怎么應(yīng)答broker的。

????『消息堆積』：消費(fèi)者來不及消費(fèi)的消息堆積在broker中。這塊除了需要消費(fèi)者快速消費(fèi)掉消息，主要的內(nèi)容是broker需要考慮的。按下不表，后續(xù)再完善。

3. 常見的消息中間件

????ActiveMQ

????RabbitMQ-是AMQP協(xié)議的一種實(shí)現(xiàn)

????RocketMQ-自定義協(xié)議：

????????????????http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/

? ??????????????http://rocketmq.apache.org/docs/quick-start/

????淘寶notify-未開源

? ? kafka

????下一篇會分析以下實(shí)現(xiàn)對于關(guān)鍵問題的tradeoff和設(shè)計(jì)思路