消息中間件Kafka、RocketMQ該怎么理解

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)消息中間件Kafka、RocketMQ該怎么理解，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

消息中間件的應(yīng)用場(chǎng)景

• 異步解耦

• 削峰填谷

• 順序收發(fā)

• 分布式事務(wù)一致性

主流 MQ 框架及對(duì)比

說(shuō)明

• Kafka：整個(gè)行業(yè)應(yīng)用廣泛

• RocketMQ：阿里，從 apache 孵化

• Pulsar：雅虎開源，符合云原生架構(gòu)的消息隊(duì)列，社區(qū)活躍

• RabbitMQ 架構(gòu)比較老，AMQP并沒(méi)有在主流的 MQ 得到支持

• NSQ：內(nèi)存型，不是最優(yōu)選擇

• ActiveMQ、ZeroMQ 可忽略

Kafka 優(yōu)點(diǎn)

• 非常成熟，生態(tài)豐富，與 Hadoop 連接緊密

• 吞吐非常高，可用性高sharding提升 replication 速度

• 主要功能：pub-sub，壓縮支持良好

• 可按照 at least once, at most once 進(jìn)行配置使用，exactly once 需要 Consumer 配合

• 集群部署簡(jiǎn)單，但 controller 邏輯很復(fù)雜，實(shí)現(xiàn)partition 得多副本、數(shù)據(jù)一致性

• controller 依賴 ZooKeeper

• 異步刷磁盤（除了錢的業(yè)務(wù)，很少有同步 flush 的需求）

Kafka 缺點(diǎn)

• 寫入延時(shí)穩(wěn)定性問(wèn)題，partition 很多時(shí)Kafka 通常用機(jī)械盤，隨機(jī)寫造成吞吐下降和延時(shí)上升100ms ~ 500ms

• 運(yùn)維的復(fù)雜性單機(jī)故障后補(bǔ)充副本數(shù)據(jù)遷移快手的優(yōu)化：遷移 partition 時(shí)舊數(shù)據(jù)不動(dòng)，新數(shù)據(jù)寫入新 partition 一定時(shí)間后直接切換

RocketMQ

• 阿里根據(jù) Kafka 改造適應(yīng)電商等在線業(yè)務(wù)場(chǎng)景

• 以犧牲性能為代價(jià)增強(qiáng)功能安 key 對(duì)消息查詢，維護(hù) hash 表，影響 io為了在多 shard 場(chǎng)景下保證寫入延遲穩(wěn)定，在 broker 級(jí)別將所有 shard 當(dāng)前寫入的數(shù)據(jù)放入一個(gè)文件，形成 commitlog list，放若干個(gè) index 文件維護(hù)邏輯 topic 信息，造成更多的隨機(jī)讀

• 沒(méi)有中心管理節(jié)點(diǎn)，現(xiàn)在看起來(lái)并沒(méi)有什么用，元數(shù)據(jù)并不多

• 高精度的延遲消息（快手已支持秒級(jí)精度的延遲消息）

Pulsar

• 存儲(chǔ)、計(jì)算分離，方便擴(kuò)容存儲(chǔ)：bookkeeperMQ邏輯：無(wú)狀態(tài)的 broker 處理

發(fā)展趨勢(shì)

• 云原生

• 批流一體：跑任務(wù)時(shí)，需要先把 Kafka 數(shù)據(jù)→HDFS，資源消耗大。如果本來(lái)就存在 HDFS，能節(jié)省很大資源

• Serverless

各公司發(fā)展

• 快手：Kafka所有場(chǎng)景均在使用特殊形態(tài)的讀寫分離數(shù)據(jù)實(shí)時(shí)消費(fèi)到 HDFS在有明顯 lag 的 consumer 讀取時(shí)，broker 把請(qǐng)求從本地磁盤轉(zhuǎn)發(fā)的 HDFS不會(huì)因?yàn)橛?lag 的 consumer 對(duì)日常讀寫造成明顯的磁盤隨機(jī)讀寫由于自己改造，社區(qū)新功能引入困難

• 阿里巴巴：開源 RocketMQ

• 字節(jié)跳動(dòng)在線場(chǎng)景：NSQ→RocketMQ離線場(chǎng)景：Kafka→自研的存儲(chǔ)計(jì)算分類的 BMQ（協(xié)議層直接兼容Kafka，用戶可以不換 client）

• 百度：自研的 BigPipe，不怎么樣

• 美團(tuán)：Kafka 架構(gòu)基礎(chǔ)上用 Java 進(jìn)行重構(gòu)，內(nèi)部叫 Mafka

• 騰訊：部分使用了自研的 PhxQueue，底層是 KV 系統(tǒng)

• 滴滴：DDMQ對(duì) RocketMQ 和 Kafka 進(jìn)行封裝多機(jī)房數(shù)據(jù)一致性可能有問(wèn)題

• 小米：自研 Talos架構(gòu)類似 pulsar，存儲(chǔ)是 HDFS，讀場(chǎng)景有優(yōu)化

Kafka

• Kafka官網(wǎng)： https://kafka.apache.org/documentation/#uses

• 最新版本：2.7

Kafka 是什么？

• 開源的消息引擎系統(tǒng)（消息隊(duì)列/消息中間件）

• 分布式流處理平臺(tái)

• 發(fā)布/訂閱模型

• 削峰填谷

Kafka 術(shù)語(yǔ)

• Topic：發(fā)布訂閱的主題

• Producer：向Topic發(fā)布消息的客戶端

• Consumer：消費(fèi)者

• Consumer Group：消費(fèi)者組，多個(gè)消費(fèi)者共同組成一個(gè)組

• Broker：Kafka的服務(wù)進(jìn)程

• Replication：備份，相同數(shù)據(jù)拷貝到多臺(tái)機(jī)器Leader ReplicaFollower Replica，不與外界交互

• Partition：分區(qū)，解決伸縮性問(wèn)題，多個(gè)Partition組成一個(gè)Topic

• Segment：partition 有多個(gè) segment 組成

Kafka 如何持久化？

• 消息日志（Log）保存數(shù)據(jù)，磁盤追加寫（Append-only）避免緩慢的隨機(jī)I/O操作高吞吐

• 定期刪除消息（日志段）

Kafka 文件存儲(chǔ)機(jī)制

https://www.open-open.com/lib/view/open1421150566328.html

• 每個(gè) partition 相當(dāng)于一個(gè)巨型文件→多個(gè)大小相等 segment 數(shù)據(jù)文件中

• 每個(gè) partition 只需要順序讀寫就行了，segment 文件生命周期由配置決定

• segment file 組成：index file：索引文件data file：數(shù)據(jù)文件

• segment file 文件命名規(guī)則：全局第一個(gè) segment 是 0后序每個(gè)加上全局 partition 的最大 offset

一對(duì) segment file

message 物理結(jié)構(gòu)

分區(qū)

為什么分區(qū)？

• Kafka的消息組織方式：主題-分區(qū)-消息

• 一條消息，僅存在某一個(gè)分區(qū)中

• 提高伸縮性，不同分區(qū)可以放到不同機(jī)器，讀寫操作也是以分區(qū)粒度

分區(qū)策略？

• 輪詢

• 隨機(jī)

• 按 key 保序，單分區(qū)有序

Kafka 是否會(huì)消息丟失？

• 只對(duì)“已提交”的消息做有限度的持久化保證已提交的消息：消息寫入日志文件有限度的持久化保證：N個(gè) broker 至少一個(gè)存活

• 生產(chǎn)者丟失數(shù)據(jù)producer.send(msg) 異步發(fā)送消息，不保證數(shù)據(jù)到達(dá)Kafkaproducer.send(msg, callback) 判斷回調(diào)

• 消費(fèi)者程序丟失數(shù)據(jù)應(yīng)該「先消費(fèi)消息，后更新位移的順序」新問(wèn)題：消息的重復(fù)處理多線程異步處理消息，Consumer不要開啟自動(dòng)提交位移，應(yīng)用程序手動(dòng)提交位移

控制器

• 在 ZooKeeper幫助下管理和協(xié)調(diào)整個(gè) Kafka 集群

• 運(yùn)行過(guò)程中，只能有一個(gè) Broker 成為控制器

控制器如何選購(gòu)？

在 ZooKeeper 創(chuàng)建 /controller 節(jié)點(diǎn)，第一個(gè)創(chuàng)建成功的 Broker 被指定為控制器。

控制器有什么用？

• 主題管理（創(chuàng)建、刪除、增加分區(qū)）

• 分區(qū)重分配

• 領(lǐng)導(dǎo)者選舉

• 集群成員管理（新增 Broker、Broker 主動(dòng)關(guān)閉、Broker 宕機(jī)）（ZooKeeper 臨時(shí)節(jié)點(diǎn)）

• 數(shù)據(jù)服務(wù)：最全的集群元數(shù)據(jù)信息

控制器故障轉(zhuǎn)移

• 只有一個(gè) Broker 當(dāng)控制器，單點(diǎn)失效，立即啟用備用控制器

Kafka 的 ZooKeeper 存儲(chǔ)結(jié)構(gòu)

分布式事務(wù)的應(yīng)用場(chǎng)景

• 團(tuán)隊(duì)內(nèi)部，某些操作要同時(shí)更新多個(gè)數(shù)據(jù)源

• 業(yè)務(wù)團(tuán)隊(duì) A 完成某個(gè)操作后，B 業(yè)務(wù)的某個(gè)操作也必須完成，A 業(yè)務(wù)并不能直接訪問(wèn) B 的數(shù)據(jù)庫(kù)

• 公司之間，用戶付款后，支付系統(tǒng)（支付寶/微信）必須通知商家的系統(tǒng)更新訂單狀態(tài)

兩階段最終一致

• 先完成數(shù)據(jù)源 A 的事務(wù)（一階段）

• 成功后通過(guò)某種機(jī)制，保證數(shù)據(jù)源 B 的事務(wù)（二階段）也一定最終完成不成功，會(huì)不斷重試直到成功為止或達(dá)到一定重試次數(shù)后停止（配合對(duì)賬、人工處理）

如何保證最終一致？

為了保證最終一致，消息系統(tǒng)和業(yè)務(wù)程序需要保證：

• 消息發(fā)送的一致性：消息發(fā)送時(shí)，一階段事務(wù)和消息發(fā)送必須同時(shí)成功或失敗

• 消息存儲(chǔ)不丟失：消息發(fā)送成功后，到消息被成功消費(fèi)前，消息服務(wù)器（broker）必須存儲(chǔ)好消息，保證發(fā)生故障時(shí)，消息不丟失

• 消費(fèi)者不丟失消息：處理失敗不丟棄，重試直到成功為止

消息發(fā)送的一致性如何保證？

目標(biāo) ：本地事務(wù)、消息發(fā)送必須同時(shí)成功/失敗

問(wèn)題

• 先執(zhí)行本地事務(wù)，再發(fā)送消息，消息可能發(fā)送失敗

• 可把失敗的消息放入內(nèi)存，稍后重試，但成功率也無(wú)法達(dá)到 100%

• 解決方案`* 先發(fā)送半消息（Half Msg，類似 Prepare 操作），不會(huì)投遞給消費(fèi)者

• 半消息發(fā)送成功，再執(zhí)行 DB 操作

• DB 操作執(zhí)行成功后，提交半消息

發(fā)送異常會(huì)如何？

• 1 異常，半消息發(fā)送失敗，本地 DB 沒(méi)有執(zhí)行，整個(gè)操作失敗，DB/消息的狀態(tài)一致（都沒(méi)有提交）

• 2 異常/超市生產(chǎn)者以為失敗了，不執(zhí)行 DBbroker 存儲(chǔ)半消息成功，等不到后續(xù)操作，會(huì)詢問(wèn)生產(chǎn)者是提交還是回滾（第6步）

• 3 DB操作失?。荷a(chǎn)者在第 4 步告知 broker 回滾半消息

• 4 提交/回滾半消息失敗：broker 等不到這個(gè)操作，觸發(fā)回查（第 6 步）

• 5、6、7回查失?。篟ocketMQ 最多回查 15 次

上述就是小編為大家分享的消息中間件Kafka、RocketMQ該怎么理解了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。