<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          云原生消息、事件、流超融合平臺(tái)——RocketMQ 5.0 初探

          共 9188字,需瀏覽 19分鐘

           ·

          2021-10-30 03:57


          前言:本文整理自 RocketMQ x EventMesh OpenDay 金融通演講內(nèi)容


          今天分享的主題是云原生消息事件流超融合平臺(tái) RocketMQ 5.0 初探,內(nèi)容主要分為三個(gè)部分:


          首先,帶大家回顧業(yè)務(wù)消息領(lǐng)域首選 RocketMQ 4 發(fā)展歷史以及 4.x 版本的演進(jìn)與發(fā)展。

          其次,會(huì)為大家詳細(xì)介紹 RocketMQ 5.0 發(fā)展情況以及一些新特性。
          ????
          最后,會(huì)為大家介紹 RocketMQ 5.0 的發(fā)展路線圖,方便社區(qū)小伙伴能夠一起參與進(jìn)來到 5.0 的貢獻(xiàn)中來。
          ?

          RocketMQ?發(fā)展歷程

          Aliware




          RocketMQ 自誕生以來前后經(jīng)歷了四代架構(gòu),并伴隨著企業(yè)IT 架構(gòu)不斷發(fā)展,從 SOA 時(shí)代到微服務(wù)時(shí)代,再到如今的云原生時(shí)代。RocketMQ 最早誕生于阿里巴巴,阿里巴巴早期有一些自研的消息引擎,比如淘寶的 Notify、B2B 業(yè)務(wù)的 Napoli。但無論是 Napoli 還是 Notify,都是基于關(guān)系型數(shù)據(jù)庫進(jìn)行存儲(chǔ)并帶來了一些隱患。

          所以在2011年,阿里巴巴以文件系統(tǒng)作為存儲(chǔ)研發(fā)了 MetaQ。經(jīng)過不斷探索,在重寫 MetaQ 2.0 后,第一代 RocketMQ 正是誕生,并將其命名為 RocketMQ 3.0 。2013年,阿里巴巴對 RocketMQ 進(jìn)行開源,并在2016年捐獻(xiàn)給 Apache 社區(qū)。2017年,RocketMQ 從 Apache 畢業(yè),正式成為 Apache 基金會(huì)頂級開源項(xiàng)目。

          隨著 RocketMQ 進(jìn)入 Apache 基金會(huì),RocketMQ 4.x 進(jìn)行快速發(fā)展,也發(fā)布了非常多版本,在架構(gòu)多副本能力、消息類型、消息治理方面都有了非常巨大的飛躍。與此同時(shí),社區(qū)生態(tài)也茁壯成長,全球 Contributor 數(shù)接近 500 人。
          ?
          伴隨著云原生時(shí)代到來,以及實(shí)時(shí)計(jì)算的興起,RocketMQ 也將進(jìn)行全面升級,發(fā)布 RocketMQ 5.0。我們和社區(qū)小伙伴們將 RocketMQ 5.0 定義為云原生的消息、事件、流的超融合平臺(tái)。
          ?

          RocketMQ 4?回顧

          Aliware


          回顧 RocketMQ 4,我們一直在強(qiáng)調(diào) RocketMQ 是業(yè)務(wù)消息首選。非常多公司將 RocketMQ 用于核心交易鏈路上,甚至很多公司會(huì)搭建兩套消息系統(tǒng),一套 Kafka 進(jìn)行數(shù)據(jù)分析,另一套 RocketMQ 用于業(yè)務(wù)消息處理。


          那為什么 RocketMQ 會(huì)為成為眾多企業(yè)的一致選擇呢,從以下幾點(diǎn),也許能一窺究竟:

          第一,RocketMQ 是金融級高可靠的產(chǎn)品。相比于其他消息中間件,RocketMQ 經(jīng)過超大規(guī)模驗(yàn)證。阿里巴巴幾乎所有消息鏈路都是建立在 RocketMQ 之上,包括核心交易鏈路。比如雙十一當(dāng)天 RocketMQ 支持了超過數(shù)萬億條消息的流轉(zhuǎn),與此同時(shí),在阿里云上的消息服務(wù)也服務(wù)了數(shù)萬家企業(yè)。這些規(guī)模龐大的企業(yè)對 SLA 同樣有著極高的要求。而這些自身實(shí)踐以及客戶服務(wù)的大量真實(shí)場景打磨對于消息系統(tǒng)的穩(wěn)定性起到了至關(guān)重要的作用。
          ?
          第二,RocketMQ 有著極簡的架構(gòu)并且易于維護(hù),整個(gè)集群由 NameServer、Broker 兩部分組成,NameServer 進(jìn)行路由發(fā)現(xiàn),Broker 作為實(shí)際存儲(chǔ)數(shù)據(jù)的集群。從架構(gòu)圖中可以看到,RocketMQ 采用兩主兩備的集群方式,從節(jié)點(diǎn)通過同步復(fù)制或者異步復(fù)制的方式向主節(jié)點(diǎn)同步數(shù)據(jù)。這樣的部署模式保證了服務(wù)能夠具備較高可用性。
          ?
          通過部署多組 Broker,即使其中一組 Broker 的 Master 出現(xiàn)不可用,也可以發(fā)送消息給其他組 Master,Consumer 也能從 Slave 進(jìn)行讀取。而 NameServer 處于完全無狀態(tài),即使 NameServer 全部宕機(jī),由于客戶端已保存路由信息,所以也不會(huì)影響存量服務(wù)。此外,RocketMQ 的運(yùn)維也非常容易,擴(kuò)容時(shí)只要增加 Broker 組數(shù)即可。如果一組 Broker 出現(xiàn)問題,也可以將它進(jìn)行禁寫,路由會(huì)馬上被摘掉,不會(huì)影響其他業(yè)務(wù)。
          ?
          RocketMQ 部署也非常簡單,JAR 部署只需要兩行命令就能把 RocketMQ 進(jìn)行拉起。在 K8s 上部署就更加簡單,如果用了 RocketMQ Operator ,用一句 kubectl apply ?命令就能將整個(gè)集群拉起來。
          ?
          第三,是豐富的消息類型,RocketMQ 支持普通消息、順序消息、延遲消息、重試消息、死信消息、事務(wù)消息等。在消息治理方面,RocketMQ 除了常見的訂閱模式,廣播模式、集群模式,還支持消息查詢,消息回放,消息軌跡,ACL 權(quán)限控制等。此外,RocketMQ 也是業(yè)界少有的原生支持服務(wù)端過濾的消息產(chǎn)品,可以提供給用戶更加豐富的使用場景,也可以充分利用服務(wù)端計(jì)算資源。RocketMQ 不僅支持消息的 Tag 過濾,還創(chuàng)新性地支持 SQL92 過濾,Tag 過濾其實(shí)已經(jīng)滿足了絕大部分的過濾需求,如果特別復(fù)雜的場景可以考慮 SQL92 過濾方式,兩個(gè)過濾方式基本上可以滿足所有消息過濾需求。相比于其他消息中間件而言,RocketMQ 的消息類型和消息治理是最豐富的。
          ?
          最后 RocketMQ 具備高吞吐低延時(shí)的特性。在阿里巴巴雙十一中,RocketMQ 支撐萬億級洪峰并保持毫秒級響應(yīng)。
          ?


          接下來,帶大家回顧一下 RocketMQ 4.x 版本的發(fā)展。在開源早期,RocketMQ 就已支持普通消息、順序消息、延遲消息等不同類型消息,基本滿足大多數(shù)業(yè)務(wù)場景。

          在 RocketMQ 4.3.0 版本之后,正式發(fā)布事務(wù)消息,通過類似于兩階段的方式去解決上下游數(shù)據(jù)不一致問題。

          在 RocketMQ 4.4.0 版本中,RocketMQ 增加了消息軌跡的功能,使用戶可以更好定位每一條消息的投放接收路徑,幫助問題排查,另外還增加 ACL 權(quán)限控制,提高了 RocketMQ 的管控能力和安全性。

          在 4.5.0 版本中,RocketMQ 推出了多副本,也就是 Raft 模式。在 Raft 模式下,一組 Broker 如果 Master 掛了,那么 Broker 中其他 Slave 就會(huì)重新選出主。因此 Broker 組內(nèi)就擁有了自動(dòng)故障轉(zhuǎn)移的能力,也解決了像高可用順序消息這樣的問題,進(jìn)一步提高了 RocketMQ 的可用性。
          ?
          在 4.6.0 版本中,我們推出了輕量級 Pull Consumer,用戶可以使用更加適合于流計(jì)算的 API,這一版本也開始支持全新的 Request-Reply 消息,使得 RocketMQ 具備了同步調(diào)用 RPC 的能力,RocketMQ 可以更好的打破網(wǎng)絡(luò)隔離網(wǎng)絡(luò)之間的調(diào)用,這個(gè)版本中 RocketMQ 也開始支持 IPV6,并且是首個(gè)支持 IPV6 的消息中間件。
          ?
          在 4.7.0?版本中,RocketMQ 重構(gòu)了主備同步復(fù)制流程,通過線程異步化,將同步復(fù)制和刷盤的過程 Pipeline 化,同步雙寫性能有將近數(shù)倍提升。
          ?
          在 4.8.0 版本中,RocketMQ Raft 模式有了一個(gè)質(zhì)的提升,包括通過異步化、批量復(fù)制等手段將性能提升了數(shù)倍,在穩(wěn)定性上利用 OpenChaos 完成包括宕機(jī)、殺死進(jìn)程,OOM、各種各樣的網(wǎng)絡(luò)分區(qū)和延遲的測試,修復(fù)了重要 Bug。在功能上,支持 Preferred Leader,從而 Broker 組內(nèi)可以優(yōu)先選主,也支持了批量消息等功能。

          在 4.9.0 版本,主要是提升了可觀測性,包括支持 OpenTracing,事務(wù)消息和 Pull Consumer 支持 Trace 等功能。
          ?
          可以看到 RocketMQ 在經(jīng)過多年發(fā)展,從性能、穩(wěn)定性、可靠性、可觀測性等方面都有了很大提高。并且在這一過程中,除了阿里之外企業(yè)在代碼建設(shè)方面做出了卓越貢獻(xiàn),這也證明 RocketMQ 已成為多元化并繁榮發(fā)展的社區(qū)。
          ?


          除了 RocketMQ 主倉庫的發(fā)展,RocketMQ 生態(tài)項(xiàng)目發(fā)展也令人備受鼓舞,特別是與云原生熱點(diǎn)技術(shù)的整合,比如說在云原生化部署上面,我們有 RocketMQ Operator、RocketMQ Docker 這些項(xiàng)目。在微服務(wù)開發(fā)框架上面,RocketMQ 社區(qū)也通過構(gòu)建 RocketMQ Spring Boot Starter 這種接入方式,方便開源用戶的微服務(wù)系統(tǒng)與 RocketMQ 消息隊(duì)列的通信能力能夠?qū)崿F(xiàn)快速集成和打通,以此為基礎(chǔ) Spring Cloud Stream Binder 和 Spring Cloud?Bus 的 RocketMQ 實(shí)現(xiàn)也被 Spring Cloud 官方收錄。

          在 Service Mesh 方面,RocketMQ 是最早和 Envoy 結(jié)合的消息產(chǎn)品,現(xiàn)在也完成了 Dapr 的集成。在 Serverless 方面,包括適配 Cloud Events 以及社區(qū)開源了 RocetMQ Knative Source 倉庫。

          在可觀測性上,RocketMQ 支持 OpenTracing、OpenTelemetry、Prometheus Exporter 等 。
          ?
          在 Eventing 領(lǐng)域,我們有自己的 RocketMQ Connector,可以去完成各種外部組件,比如 MySQL、ElasticSearch 與 RocketMQ 的數(shù)據(jù)交互和數(shù)據(jù)同步,也能完成 MQ 集群之間的一個(gè)數(shù)據(jù)流轉(zhuǎn)。在 Streaming 領(lǐng)域, RocketMQ 5.0 會(huì)發(fā)布原生的輕量級實(shí)時(shí)計(jì)算框架 RocketMQ-Streams,另一方面 RocketMQ 也積極和 Flink、Storm 、Spark 等現(xiàn)有大數(shù)據(jù)框架進(jìn)行集成。
          ?
          我們可以看到 RocketMQ 不僅是業(yè)務(wù)消息的管道,也在承擔(dān)著事件流轉(zhuǎn)、業(yè)務(wù)數(shù)據(jù)的一些離線計(jì)算和輕量級的實(shí)時(shí)計(jì)算。通過消息、事件、流三個(gè)方面發(fā)展,RocketMQ 已形成完整自閉環(huán)的生態(tài)發(fā)展,正在逐漸成為消息、事件、流的超融合的處理平臺(tái)。



          RocketMQ5.0 概覽

          Aliware



          在正式介紹 RocketMQ 5.0 之前,我們需要先回答這樣一個(gè)問題:為什么我們需要 RocketMQ 5.0,在跟眾多貢獻(xiàn)者溝通以及對 RocketMQ 大量運(yùn)維實(shí)踐后,發(fā)現(xiàn)這里有兩大原因:

          首先,開源社區(qū)的需求越發(fā)凸顯,當(dāng)大量企業(yè)采用 RocketMQ 后,每個(gè)用戶都有豐富的業(yè)務(wù)場景。而 RocketMQ 4.x 主要服務(wù)于業(yè)務(wù)消息領(lǐng)域,那么如何通過 RocketMQ 進(jìn)行實(shí)時(shí)數(shù)據(jù)計(jì)算去處理這些高價(jià)值數(shù)據(jù),成為企業(yè)下一步探索的重要方向。這也是 RocketMQ 為什么會(huì)從消息領(lǐng)域去積極拓展流計(jì)算領(lǐng)域的原因。
          ?
          其次,云消息服務(wù)質(zhì)量要求不斷提高,作為 RocketMQ 深度參與者與貢獻(xiàn)者,阿里云的消息服務(wù)目前已服務(wù)數(shù)萬家企業(yè)。隨著客戶企業(yè)對于服務(wù)的要求,以及阿里巴巴自身的業(yè)務(wù)發(fā)展,這都對 RocketMQ 有了更高要求。如何做到一套架構(gòu),同時(shí)能滿足不同用戶不同場景需求,成為 RocketMQ 5.0 中重點(diǎn)解決的問題。
          ?
          因此,結(jié)合廣泛的實(shí)際業(yè)務(wù)場景,RocketMQ 5.0 作為生于云、長于云的全新的架構(gòu),經(jīng)過不斷探索實(shí)踐,RocketMQ 5.0 主要具備以下特性:

          1. 高 SLA、低成本:與云一致的可用性、高性能、低成本
          2. 可調(diào)度:任意組件的重塑與組建適應(yīng)多樣性場景
          3. 可擴(kuò)展:開放的豐富生態(tài)
          4. 可伸縮性:極致自動(dòng)化擴(kuò)容/縮容
          5. 標(biāo)準(zhǔn)化:社區(qū)標(biāo)準(zhǔn),符合行業(yè)標(biāo)準(zhǔn)
          ??


          RocketMQ 5.0 作為云原生的消息事件流的超融合平臺(tái),基于架構(gòu)圖我們一一進(jìn)行講解:

          1. 輕量級?SDK
          RocketMQ 5.0 提供輕量級的客戶端,使之具備良好的集成與被集成能力。同時(shí),將負(fù)載均衡、邏輯位點(diǎn)管理這些復(fù)雜邏輯都放到服務(wù)端,實(shí)現(xiàn)無狀態(tài)化。在協(xié)議選擇方面,除了原有協(xié)議之外,全面支持云原生通信標(biāo)準(zhǔn) gRPC 協(xié)議。
          ?
          2. 極簡架構(gòu)
          RocketMQ 5.0 依然不會(huì)去引入任何外部依賴,保持極低的運(yùn)維負(fù)擔(dān)。同時(shí),節(jié)點(diǎn)之間的松散耦合,任意服務(wù)節(jié)點(diǎn)可以隨時(shí)進(jìn)行遷移。RocketMQ 5.0 將會(huì)是面向失敗的設(shè)計(jì),任意的服務(wù)節(jié)點(diǎn)的失敗和遷移都是可以忍受的。
          ?
          3. 可分可合的存儲(chǔ)計(jì)算分離架構(gòu)
          Broker 節(jié)點(diǎn)會(huì)成為真正無狀態(tài)的服務(wù)節(jié)點(diǎn),并且沒有 Topic Binding。也就是說消息的發(fā)送和消費(fèi)是可以發(fā)生在任意計(jì)算節(jié)點(diǎn)上,一個(gè)接入點(diǎn)即可代理所有流量,計(jì)算層以及存儲(chǔ)層均可獨(dú)立進(jìn)行彈性擴(kuò)縮。在存儲(chǔ)計(jì)算分離后,計(jì)算節(jié)點(diǎn)可以處理不同類型的協(xié)議,包括 Remoting、gRPC,MQTT、AMQP 等。此外包括 ACL、訂閱關(guān)系、多租的控制等都會(huì)放在計(jì)算節(jié)點(diǎn)上。最重要的一點(diǎn),它是可分可合的,可以支持小集群,也可以支持超大規(guī)模的集群,并且能適應(yīng)多種業(yè)務(wù)的場景,降低運(yùn)維的負(fù)擔(dān)。
          ?
          4. 多模存儲(chǔ)
          RocketMQ Raft 模式采取三副本形態(tài),與本身就擁有三副本的云盤結(jié)合之后,相當(dāng)于就得到了 9 副本。9 副本雖然帶來了更高的可靠性,但也造成了嚴(yán)重的成本浪費(fèi)。所以,RocketMQ 5.0 通過多模存儲(chǔ)解決這一問題。比如,在普通的塊存儲(chǔ)設(shè)備上,可以根據(jù)可用性需求完成兩副本或三副本部署。在云上用單副本,從而更好的支持云盤輸出,充分利用云上基礎(chǔ)設(shè)施去降低運(yùn)維成本。
          ?
          5. 云原生基礎(chǔ)設(shè)施的廣泛使用與整合
          支持 OpenTelemetry、Prometheus 等項(xiàng)目,強(qiáng)化 RocketMQ 可觀測能力。并更好去支持 K8s 生態(tài),比如 RocketMQ Operator 用一條命令即可拉起 RocketMQ 集群,并且去完成向灰度發(fā)布數(shù)據(jù)的全生命周期管理,自動(dòng)彈性擴(kuò)縮等方面的支持。


          1

          核心特性一:可分可合的存儲(chǔ)計(jì)算分離架構(gòu)



          接下來,詳細(xì)介紹一下可分可合的存儲(chǔ)計(jì)算分離架構(gòu)??煞挚珊现傅氖?RocketMQ 可以像現(xiàn)在一樣用同一進(jìn)程去啟動(dòng) Broker,也可以分開部署。分開部署之后計(jì)算節(jié)點(diǎn)就能真正的做到無狀態(tài),RocketMQ 對存儲(chǔ)計(jì)算分離的架構(gòu)的引進(jìn)是非常謹(jǐn)慎的,一體化部署帶來了諸多好處,比如大數(shù)據(jù)場景下,一體化部署提供就近計(jì)算能力,降低帶寬成本。業(yè)務(wù)消息場景下,一體化部署可以降低延遲。與此同時(shí),存儲(chǔ)計(jì)算分離也有非常多的好處,比如說擴(kuò)縮容可以更加靈活,可以針對具體計(jì)算資源或存儲(chǔ)資源進(jìn)行擴(kuò)縮容。
          ?
          因此 RocketMQ 5.0 將會(huì)提供可分可合的存儲(chǔ)計(jì)算分離架構(gòu),可以適應(yīng)多種場景。計(jì)算節(jié)點(diǎn)是完全無狀態(tài)的。包括像協(xié)議適配、流量租戶等管控都會(huì)放在計(jì)算節(jié)點(diǎn)上完成。此外,通過 POP 消費(fèi)方式把整個(gè)客戶端的負(fù)載均衡邏輯位的管理上升到計(jì)算節(jié)點(diǎn),無 Queue Binding,任意的計(jì)算節(jié)點(diǎn)都能進(jìn)行收發(fā)。另外,由于無狀態(tài),可以完成秒級彈性擴(kuò)縮,并且過程中是沒有 Rebalance 負(fù)擔(dān)的。
          ?
          與此同時(shí),RocketMQ 5.0 會(huì)對存儲(chǔ)集群進(jìn)行了優(yōu)化調(diào)整。在存儲(chǔ)集群中我們原生的保留了多消息類型的存儲(chǔ)支持,包括事務(wù)消息、定時(shí)消息,重試消息、死信消息等。在副本的選擇上,根據(jù)不同場景去提供不同支持,包括本地塊設(shè)備多副本支持、云盤單副本支持。借助多模態(tài)存儲(chǔ)功能,充分利用云上基礎(chǔ)設(shè)施降低成本。
          ?
          另一點(diǎn)非常重要的是多元索引的支持。現(xiàn)在 RocketMQ 存儲(chǔ)是一份 CommitLog ,后臺(tái)線程去分發(fā)構(gòu)建 ConsumeQueue、index 這些索引。那么 RocketMQ 5.0 會(huì)對索引全面增強(qiáng),支持更多樣索引。比如加入批處理的索引,消息就可以完成批量發(fā)送,批量存儲(chǔ),批量接收,從而提升 RocketMQ Batch 能力。比如消息隊(duì)列只做消息輪轉(zhuǎn),查詢能力比較弱,在 RocketMQ 5.0 中,消息和 KV 會(huì)更好結(jié)合在一起,去構(gòu)建查詢索引從而增強(qiáng) KV 能力。通過一份數(shù)據(jù),多種索引,RocketMQ 5.0 可以滿足不同場景。

          2

          核心特性二:流批一體的數(shù)據(jù)訪問方式



          首先介紹全新的消費(fèi)模式——POP 消費(fèi)方式。左上角的圖是 RocketMQ 4.0 現(xiàn)有消費(fèi)端的負(fù)載均衡架構(gòu)。比如現(xiàn)在 Topic 分布在 3 個(gè) Broker 上,共計(jì) 9 個(gè)隊(duì)列。在集群模式下,1 個(gè)消費(fèi)組有 3 個(gè)消費(fèi)者,所以每個(gè)消費(fèi)者分配到了三個(gè)隊(duì)列。
          ?
          但這也帶來了一些問題,比如說某 Consumer 突然 Hang 住了,這它無法消費(fèi)消息但也沒有掉線,仍然保持和 Broker 的心跳連接,因此也不會(huì)將剔除而進(jìn)行重平衡,所以這個(gè)消費(fèi)者分配到的隊(duì)列就會(huì)有大量的消息堆積,這些隊(duì)列的消費(fèi)就會(huì)卡住。
          ?
          這本質(zhì)上是一個(gè)綁定關(guān)系問題,一旦 Rebalance 發(fā)生后,Consumer 和隊(duì)列就完成了綁定。針對這個(gè)問題,RocketMQ 5.0 推出了一個(gè)全新的消費(fèi)方式,即 POP 消費(fèi)方式。它取消了 Rebalance 造成的綁定關(guān)系,一個(gè)隊(duì)列可以被任意多個(gè) Consumer 進(jìn)行消費(fèi),然后在 Broker 端通過隊(duì)列鎖完成并發(fā)控制。
          ?
          POP 消費(fèi)中,客戶端會(huì)直接到每個(gè) Broker 的隊(duì)列進(jìn)行請求消費(fèi), Broker 會(huì)把消息分配返回給等待的客戶端。隨后客戶端消費(fèi)結(jié)束后返回對應(yīng)的 ACK 結(jié)果通知 Broker,Broker 再標(biāo)記消息消費(fèi)結(jié)果,如果超時(shí)沒響應(yīng)或者消費(fèi)失敗,再會(huì)進(jìn)行重試。
          ?
          Broker 對于每次 POP 的請求,都會(huì)有以下三個(gè)操作:
          1. 對應(yīng)的隊(duì)列進(jìn)行加鎖,然后從 Store 層獲取該隊(duì)列的消息;
          2. 然后寫入 CK 消息,表明獲取的消息要被 POP 消費(fèi);
          3. 最后提交當(dāng)前位點(diǎn),并釋放鎖。

          CK 消息實(shí)際上是記錄了 POP 消息具體位點(diǎn)的定時(shí)消息,當(dāng)客戶端超時(shí)沒響應(yīng)的時(shí)候,CK 消息就會(huì)重新被 Broker 消費(fèi),然后把 CK 消息的位點(diǎn)的消息寫入重試隊(duì)列。如果 Broker 收到客戶端的消費(fèi)結(jié)果的 ACK ,刪除對應(yīng)的 CK 消息,然后根據(jù)具體結(jié)果判斷是否需要重試。

          從整體流程可見,POP 消費(fèi)并不需要 Reblance ,可以避免 Rebalance 帶來的消費(fèi)延時(shí),同時(shí)客戶端可以消費(fèi) Broker 的所有隊(duì)列,這樣就可以避免機(jī)器 Hang 住而導(dǎo)致堆積的問題。
          ?
          有了 POP、PUSH、PULL 等模式之后,RocketMQ 就可以完成流批一體的數(shù)據(jù)訪問方式。比如說在 Streaming 場景下,通過原本 PUSH 方式可以保證很好的順序消費(fèi)。但批處理等對順序要求并不高的場景中,我們可以用 POP 消費(fèi)的方式對同一隊(duì)列進(jìn)行高并發(fā)讀取,加快數(shù)據(jù)讀取速度。另一方面 POP 消費(fèi)模式也使得客戶端更加輕量化,大量的邏輯都在服務(wù)端,對多語言客戶端的編寫也是更加友好的。


          3

          核心特性三:極致彈性擴(kuò)縮


          ?
          上圖是 RocketMQ 現(xiàn)有架構(gòu),比如說我們通過禁寫操作,可以使 Broker 1001 的流量自然流入到 1002 上。但在 Streaming 領(lǐng)域,上層業(yè)務(wù)一般要求存儲(chǔ)隊(duì)列始終固定的,只有這樣才能保證流式數(shù)據(jù)處理的順序性和完整性,這也就要求擴(kuò)縮容不會(huì)引起隊(duì)列數(shù)量的變化。因此 RocketMQ 5.0 Preview 版本提供了一個(gè)邏輯隊(duì)列概念,把原本的物理隊(duì)列邏輯組合在一起,一個(gè)邏輯隊(duì)列可以分散到不同 Broker 上面。比如圖中的一個(gè)邏輯隊(duì)列,0~100 在 Broker 1001 上,100~1000 在 Broker 1002 上,1000~2000 的在 Broker 1003 上,通過組合可以把多個(gè)物理隊(duì)列串聯(lián)成了一個(gè)大的邏輯隊(duì)列。
          ?
          由于邏輯隊(duì)列是一個(gè) Binding 過程,所以是非常輕量級的操作,因此提供了一個(gè)秒級彈性擴(kuò)充的一個(gè)能力,過程中完全沒有也沒有數(shù)據(jù)的復(fù)制,只要一完成 Broker 擴(kuò)容,完成綁定操作,流量也就完成了調(diào)撥。另外我們也提供雙模隊(duì)列兼容的能力,平時(shí)默認(rèn)還是原來的物理隊(duì)列,只有指定單個(gè) Topic 開啟后,才會(huì)使用邏輯隊(duì)列。


          4

          核心特性四:輕量級實(shí)時(shí)計(jì)算


          RocketMQ 5.0 中還有一個(gè)非常重量級的特性,將會(huì)推出輕量級的實(shí)時(shí)計(jì)算框架 RocketMQ Streams。它的設(shè)計(jì)目標(biāo)是幫助用戶在不依賴外部重量級計(jì)算產(chǎn)品的情況下,僅利用已有 RocketMQ 資源完成大多數(shù)業(yè)務(wù)場景需要的輕量級的數(shù)據(jù)處理和計(jì)算。



          RocketMQ Stream 依賴少、部署簡單,它利用 RocketMQ Rabalance 能力可以任意橫向擴(kuò)展,同時(shí)支持包括 Map、Fliter 這些常見的算子,還有 Window、Join、維表等。另外相比于其他基于消息的實(shí)時(shí)計(jì)算平臺(tái),RocketMQ Streams 除提供原生無依賴的支持外,可以兼容 Flink SQL 標(biāo)準(zhǔn)以及提供 UDF/UDAF/UDTF 的能力。
          ?
          另一方面,在實(shí)時(shí)計(jì)算生態(tài)上面,RocketMQ 也積極的和其他的大數(shù)據(jù)框架進(jìn)行對接,包括 Flink、Spark 等 。特別是基于最新標(biāo)準(zhǔn)的 RocketMQ-Flink Connector 也會(huì)近期畢業(yè)。
          ?

          RcoketMQ 5.0 Landscape

          Aliware


          RocketMQ 5.0 版本將在今年正式發(fā)布, 5.0 Preview 的版本已經(jīng)在 Discuss 了,代碼也放在 Github 倉庫中,5.0 Preview 版本會(huì)推出邏輯隊(duì)列,以及流批一體的訪問方式等重磅特性。之后我們會(huì)正式發(fā)布實(shí)時(shí)流計(jì)算框架 RocketMQ Streams,并在 RocketMQ 5.0 支持批處理、批索引能力。在后續(xù)的里程碑中 RocketMQ 5.0 將會(huì)完成 gRPC 協(xié)議支持,全新的輕量級客戶端,完成 AMQP、MQTT 協(xié)議等支持,以及可分可合的存儲(chǔ)與計(jì)算分離架構(gòu)。

          ?
          也希望能有更多的小伙伴參與到 Apache RocketMQ 社區(qū)中來,一起打造來下一代云原生消息引擎,打造 Messaging、Eventing、Streaming 的超融合處理平臺(tái)。


          推薦閱讀:

          騰訊二面:Redis 事務(wù)支持 ACID 么?

          讀懂Redis源碼,我總結(jié)了這7點(diǎn)心得
          緩存和數(shù)據(jù)庫一致性問題,看這篇就夠了
          搞懂異地多活,看這篇就夠了
          聊聊分布式鎖——Redis和Redisson的方式
          看一遍就理解:MVCC原理詳解

          關(guān)互聯(lián)網(wǎng)全棧架構(gòu)價(jià)


          瀏覽 63
          點(diǎn)贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評論
          圖片
          表情
          推薦
          點(diǎn)贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  三级片做爱视频 | 日韩视频在线观看一区二区三区 | 欧美精品成人自拍视频在线观看 | 午夜试看120秒体验区的特点 | 蜜桃视频网站免费观看 |