消息隊列與Kafka

關於消息隊列

消息隊列（如下簡稱MQ）是一種跨進程的通訊機制，用於上下游傳遞消息。

什麼時候使用

1. 異步處理：主要的使用場景就是將比較耗時並且不須要即時（同步）返回結果的操做做爲消息放入消息隊列，有利於下降請求響應時間。例如：高併發狀況下用戶註冊時，因爲郵件接口承受不住，可能會出現用戶記錄已經添加到數據庫記錄中可是系統卻卡在發送註冊郵件中，致使請求響應的時間大幅增長，甚至出現超時，面對這種狀況通常也是將這些操做放入消息隊列（生產者消費者模型），消息隊列慢慢的進行處理，同時能夠很快的完成註冊請求，不會影響用戶使用其餘功能。因此在軟件的正常功能開發中，並不須要去刻意的尋找消息隊列的使用場景，而是當出現性能瓶頸時，去查看業務邏輯是否存在能夠異步處理的耗時操做，若是存在的話即可以引入消息隊列來解決。不然盲目地使用消息隊列可能會增長維護和開發的成本卻沒法獲得可觀的性能提高，那就得不償失了。
2. 解耦：因爲使用了消息隊列，只要保證消息格式不變，消息的發送方和接收方並不須要彼此聯繫，也不須要受對方的影響，即解耦和。多個應用之間的耦合，因爲消息是平臺無關和語言無關的，並且語義上也再也不是函數調用，所以更適合做爲多個應用之間的鬆耦合的接口。基於消息隊列的耦合，不須要發送方和接收方同時在線。同時可用於分佈式系統，各個不一樣的進程(同一臺機器或者不一樣機器)經過消息隊列進行通訊。
3. 削峯：好比訂單處理，就能夠由前端應用將訂單信息放到隊列，後端應用從隊列裏依次得到消息處理，高峯時的大量訂單能夠積壓在隊列裏慢慢處理掉。因爲同步一般意味着阻塞，而大量線程的阻塞會下降計算機的性能。好比你的服務器一秒能處理100個訂單，但秒殺活動1秒進來1000個訂單，持續10秒，在後端能力沒法增長的狀況下，你能夠用消息隊列將總共10000個請求壓在隊列裏，後臺consumer按原有能力處理，100秒後處理完全部請求（而不是直接宕機丟失訂單數據）。

典型場景

1.數據驅動的任務依賴

如：定時任務tast1, task2, task3之間存在任務依賴關係，必須task1先執行，再task2執行，載task3執行

此時，MQ用來傳遞上游任務執行完成的消息。

2.上游不關心執行結果

• 上游執行時間短
• 上下游邏輯+物理解耦，除了與MQ有物理鏈接，模塊之間都不相互依賴
• 新增一個下游消息關注方，上游不須要修改任何代碼

3.上游關注執行結果，但執行時間很長

跨公網調用微信支付接口，使用回調網關+MQ來解耦。

不適合的場景

調用與被調用的關係，是沒法被MQ取代的。

用戶登陸場景，登陸頁面調用passport服務，passport服務的執行結果直接影響登陸結果，此處的「登陸頁面」與「passport服務」就必須使用調用關係，而不能使用MQ通訊。

不管如何，記住這個結論：調用方實時依賴執行結果的業務場景，請使用調用，而不是MQ。

使用MQ可能存在的問題：

• 系統更復雜，多了一個MQ組件
• 消息傳遞路徑更長，延時會增長
• 消息可靠性和重複性互爲矛盾，消息不丟（架構師之路-消息總線可否實現消息必達？）不重（冪等性設計）難以同時保證
• 上游沒法知道下游的執行結果，這一點是很致命的

RPC與MQ的區別

遠程調用服務(RPC)和消息(Message Queue)對比及其適用/不適用場合

Kafka

吞吐量極高的分佈式消息系統，總體設計是典型的發佈與訂閱系統。下圖1爲Kafka架構圖：

                                圖-1 Kafka架構圖

主要術語

消息生產者：即Producer，消息源頭，負責發送消息併發送到Kafka服務器上。

消息消費者：即Consumer,消息的使用方，負責消費Kafka服務器上的消息。

主題：Topic，用戶配置並定義在Kafka服務端，用於創建生產者和消費者之間的訂閱關係：生產者發送消息到指定topic下，消費者從這個topic下訂閱消息。

參考連接

芋道源碼-【消息隊列 MQ 專欄】消息隊列之Kafka

高效開發運維-漫談消息隊列：以Kafka和RocketMQ爲例

芋道源碼-爲何須要消息隊列？使用消息隊列有什麼好處？（主流消息隊列對比）

InfoQ-Kafka系列

orchome-Kafka中文教程

芋道源碼-分佈式消息隊列RocketMQ源碼分析—Message順序發送與消費（順序消費問題，RocketMQ支持可是通常場景不推薦使用，Kafka只能保證每一個partition內的消息順序傳輸）