阿里分布式消息中間件RocketMQ-深入解析

1、 阿里分布式消息中間件RocketMQ深入解析2012年，阿里巴巴開源其自研的第三代分布式消息中間件RocketMQ。經(jīng)過幾年的技術(shù)打磨，使用RocketMQ技術(shù)的阿里目前可以在雙十一當(dāng)天承受萬億級消息容量。2016年11月，阿里將RocketMQ捐獻給Apache軟件基金會，正式成為孵化項目。阿里稱會將其打造成頂級項目。這是阿里邁出的一大步，因為加入到開源軟件基金會需要經(jīng)過評審方的考核與觀察。坦率而言，業(yè)界還對國人的代碼開源參與度仍保持著刻板印象；而Apache基金會中的342個項目中，暫時還只有Kylin、CarbonData、Eagle 和 RocketMQ 共計四個中國技術(shù)人主導(dǎo)的項目

2、。2017年2月20日，RocketMQ正式發(fā)布4.0版本，專家稱新版本適用于電商領(lǐng)域，金融領(lǐng)域，大數(shù)據(jù)領(lǐng)域，兼有物聯(lián)網(wǎng)領(lǐng)域的編程模型。RocketMQ項目背后，究竟有怎樣的技術(shù)內(nèi)涵？緣何贏得了基金會的初步認(rèn)可？入駐基金會可以給技術(shù)圈哪些啟示？InfoQ帶著這樣的疑問對兩位項目聯(lián)合創(chuàng)始人進行了專訪，內(nèi)容整理如下。RocketMQ的由來 談起RocketMQ的亮點，那不得不先提一下阿里巴巴消息引擎的演進史。阿里中間件消息引擎發(fā)展到今日，前前后后經(jīng)歷了三代演進。第一代，推模式，數(shù)據(jù)存儲采用關(guān)系型數(shù)據(jù)庫。在這種模式下，消息具有很低的延遲特性，并且很容易支持分布式事務(wù)。尤其在阿里淘寶這種高頻交易場景中

3、，具有非常廣泛地應(yīng)用。典型代表包括Notify、Napoli。第二代，拉模式，自研的專有消息存儲。在日志處理方面能夠媲美Kafka的吞吐性能，但考慮到淘寶的應(yīng)用場景，尤其是其交易鏈路的高可靠需求，消息引擎并沒有一味的追求吞吐，而是將穩(wěn)定可靠放在首位。因為采用了長連接拉模式，在消息的實時方面絲毫不遜推模式。典型代表MetaQ。第三代，以拉模式為主，兼有推模式的高性能、低延遲消息引擎RocketMQ，在二代功能特性的基礎(chǔ)上，為電商金融領(lǐng)域添加了可靠重試、基于文件存儲的分布式事務(wù)等特性，并做了大量優(yōu)化。從2012年開始，經(jīng)歷了歷次雙11核心交易鏈路檢驗。目前已經(jīng)捐贈給Apache基金會。時至今日，R

4、ocketMQ很好的服務(wù)了阿里集團大大小小上千個應(yīng)用，在雙11當(dāng)天，更有不可思議的萬億級消息流轉(zhuǎn)，為集團大中臺的穩(wěn)定發(fā)揮了舉足輕重的作用。不難看出，RocketMQ其實是伴隨著阿里巴巴整個生態(tài)的成長，逐漸衍生出來的高性能、低延遲能夠同時滿足電商領(lǐng)域和金融領(lǐng)域的極盡苛刻場景的消息中間件。經(jīng)歷雙11洗禮的英雄 2016年雙十一，阿里巴巴內(nèi)部的消息中間件全面擁抱RocketMQ的低延遲存儲引擎。在備戰(zhàn)期間，團隊重點做了兩件事情，優(yōu)化慢請求與統(tǒng)一存儲引擎；優(yōu)化慢請求：這里主要是解決在海量高并發(fā)場景下降低慢請求對整個集群帶來的抖動，毛刺問題。這是一個極具挑戰(zhàn)的技術(shù)活，團隊同學(xué)經(jīng)過長達1個多月的跟進調(diào)優(yōu)，

5、從雙十一的復(fù)盤情況來看，99.996%的延遲落在了10ms以內(nèi)，而99.6%的延遲在1ms以內(nèi)。優(yōu)化主要集中在RocketMQ存儲層算法優(yōu)化、JVM與操作系統(tǒng)調(diào)優(yōu)。更多的細節(jié)大家可以參考我們之前寫的電子書章節(jié)萬億級數(shù)據(jù)洪峰下的分布式消息引擎1。統(tǒng)一存儲引擎：主要解決的消息引擎的高可用，成本問題。在多代消息引擎共存的前提下，我們對Notify的存儲模塊進行了全面移植與替換?；谏鲜龇e極的技術(shù)準(zhǔn)備，在16年雙十一期間，阿里集團大約有1.2萬億級的消息流轉(zhuǎn)總量，幾乎是15年雙十一大促的2倍。峰值期間，消息生產(chǎn)的吞吐在2000 w/s左右，消息消費的吞吐也近乎1500 w/s的量級。整個大促下來，用我

6、們內(nèi)部的話來說，如絲般順滑。RocketMQ的技術(shù)概覽 在我們看來，它最大的創(chuàng)新點在于能夠通過精巧的橫向、縱向擴展，不斷滿足與日俱增的海量消息在高吞吐、高可靠、低延遲方面的要求。目前RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分構(gòu)成，如下圖所示。所有的集群都具有水平擴展能力，無單點障礙。NameServer以輕量級的方式提供服務(wù)發(fā)現(xiàn)和路由功能，每個NameServer存有全量的路由信息，提供對等的讀寫服務(wù)，支持快速擴縮容。Broker負責(zé)消息存儲，以Topic為緯度支持輕量級的隊列，單機可以支撐上萬隊列規(guī)模，支持消息推拉模型，具備多副本容錯

7、機制（2副本或3副本）、強大的削峰填谷以及上億級消息堆積能力，同時可嚴(yán)格保證消息的有序性。除此之外，Broker還提供了同城異地容災(zāi)能力，豐富的Metrics統(tǒng)計以及告警機制。這些都是傳統(tǒng)消息系統(tǒng)無法比擬的。Producer由用戶進行分布式部署，消息由Producer通過多種負載均衡模式發(fā)送到Broker集群，發(fā)送低延時，支持快速失敗。Consumer也由用戶部署，支持PUSH和PULL兩種消費模式，支持集群消費和廣播消息，提供實時的消息訂閱機制，滿足大多數(shù)消費場景。與其他消息中間件的對比 1、是不是CS架構(gòu)？如果需要做同類產(chǎn)品之間的橫向?qū)Ρ?，我們?yōu)先拿下ZeroMQ，ZeroMQ正如其名0M

8、Q，它更像是一個嵌入式的網(wǎng)絡(luò)類庫，一個專注于transports層的通訊組件，而不是傳統(tǒng)意義上的CS架構(gòu)的MQ。2、實現(xiàn)的哪種規(guī)范 / 協(xié)議？接下來我們來看看RabbitMQ、ActiveMQ、Kafka和RocketMQ之間的一些對比，從設(shè)計思路上來看，RabbitMQ是AMQP規(guī)范的參考實現(xiàn)，AMQP是一個線路層協(xié)議，面面俱到，很系統(tǒng)，也稍顯復(fù)雜。目前RabbitMQ已經(jīng)成為OpenStack Iaas平臺首選的消息服務(wù)，其背后的支持力度不言而喻。ActiveMQ最初是由紅帽子捐贈給Apache的，是JMS規(guī)范的參考實現(xiàn)，也是Apache旗下的老牌消息服務(wù)引擎。JMS雖說是一個API級別的

9、協(xié)議，但其內(nèi)部還是定義了一些實現(xiàn)約束，不過缺少多語言支撐。ActiveMQ的生態(tài)堪稱豐富多彩，在該Apache頂級項目下，擁有不少子項目，包括由HornetMQ演變而來的Artemis，基于Scala號稱下一代AMQ的Apollo等。3、適用何類場景？而Kafka最初被設(shè)計用來做日志處理，是一個不折不扣的大數(shù)據(jù)通道，追求高吞吐，存在丟消息的可能。其背后的研發(fā)團隊也圍繞著Kafka進行了商業(yè)包裝，目前在一些中小型公司被廣泛使用，國內(nèi)也有不少忠實的擁捧著。RocketMQ天生為金融互聯(lián)網(wǎng)領(lǐng)域而生，追求高可靠、高可用、高并發(fā)、低延遲，是一個阿里巴巴由內(nèi)而外成功孕育的典范，除了阿里集團上千個應(yīng)用外，根

10、據(jù)我們不完全統(tǒng)計，國內(nèi)至少有上百家單位、科研教育機構(gòu)在使用。關(guān)于這幾個MQ產(chǎn)品更詳細的特性對比，可以參考我們官網(wǎng)上的說明2。三項技術(shù)發(fā)力點 （一）消息的順序 不可否認(rèn)，順序消息是RocketMQ功能特性上的一個賣點。目前我們做到了全局保序。需要重點說一下，這里的全局是有前提，針對某個唯一標(biāo)識（能夠被Hash成唯一標(biāo)識），比方說大賣家賬號，某類產(chǎn)品的訂單等。其技術(shù)實現(xiàn)原理也相對比較簡單，保證對通道的單一實例操作，如單進程、單線程寫，單進程、線程讀，像ActiveMQ的Exclusive Consumer也是類似的實現(xiàn)。不難看出，這種實現(xiàn)方式實際是在吞吐上做出了一定犧牲。另外也帶來了另外一個問題

11、- 熱點。如雙十一當(dāng)天，如果使用簡單的散列策略，像短期內(nèi)就交易過億的天貓商家的消息會發(fā)送到一個通道里面，造成單通道，甚至單機的熱點問題在最新的RocketMQ版本里，我們將會改進目前的實現(xiàn)，借此改善因為順序?qū)е碌膯瓮ǖ罒狳c問題，這個特性預(yù)計今年中旬會發(fā)布。（二）消息的去重 消息領(lǐng)域有一個對消息投遞的QoS定義，分為：最多一次（At most once），至少一次（At least once），僅一次（ Exactly once）。幾乎所有的MQ產(chǎn)品都聲稱自己做到了At least once。既然是至少一次，那避免不了消息重復(fù)，尤其是在分布式網(wǎng)絡(luò)環(huán)境下，而這個缺憾歸根結(jié)底也可以看做是TCP協(xié)議的

12、一部分，如失敗重傳。業(yè)務(wù)上往往對消息重復(fù)又很敏感，RocketMQ目前的版本是不支持去重的，我們通常建議用戶通過外置全局存儲自己做判重處理。在下一代的特性規(guī)劃里，我們會內(nèi)置解決方案。先說下業(yè)界通用做法，像Artemis，IronMQ等，通過在服務(wù)端全局存儲判重。這是一個IO敏感的操作，為服務(wù)端帶來一定的負載。而RocketMQ則希望通過采取二次判重策略，有效降低服務(wù)端IO。（三）分布式的攻堅戰(zhàn) 首先明確分布式系統(tǒng)這個概念：分布式系統(tǒng)是由一系列分散自治組件通過互聯(lián)網(wǎng)并行并發(fā)協(xié)作，從而組成的一個coherent軟件系統(tǒng)。它具備資源共享，并行并發(fā)，可靠容錯，透明開放等特性。像CAP，BASE，Pax

13、os，事務(wù)等一起構(gòu)成了分布式基礎(chǔ)理論。這里我們再來重溫下CAP理論：CAP分別代表一致性（Consistency），可用性（Availability），分區(qū)容忍性（Partition tolerance）。一致性，Eric Brewer（CAP理論提出者）用一個服務(wù)要么被執(zhí)行，要么不被執(zhí)行來定義(原文：A service that is consistent operates fully or not at all)。請注意，這里的一致性是有別于數(shù)據(jù)庫ACID屬性中的C，數(shù)據(jù)庫層面的C指的是數(shù)據(jù)的操作不能破壞數(shù)據(jù)之間的完整性約束，如外鍵約束。在分布式環(huán)境中，可以把C簡單理解為多節(jié)點看到的是數(shù)據(jù)

14、單一或者同一副本?？捎眯?，意味著服務(wù)是可用的（原文：the service is available (to operate fully or not as above)）?？捎眯杂挚梢约毞譃閷懣捎煤妥x可用。在分布式環(huán)境中，往往指的是系統(tǒng)在確定時間內(nèi)可返回讀寫操作結(jié)果，也即讀寫均可用。分區(qū)容忍性，除了整個網(wǎng)絡(luò)故障外（如光纖被掘斷），其它故障（如丟包、亂序、抖動、甚至是網(wǎng)絡(luò)分區(qū)節(jié)點 crash ）都不能導(dǎo)致整個系統(tǒng)無法正確響應(yīng)（原文：No set of failures less than total network failure is allowed to cause the system

15、to respond incorrectly）。CAP理論可以看做是探索適合不同應(yīng)用的一致性與可用性平衡問題。沒有分區(qū)的情況：可以同時滿足C與A，以及完整的ACID事務(wù)支持。可以選擇犧牲一定的C，獲得更好的性能與擴展性。分區(qū)的情況：選擇A（集中關(guān)注分區(qū)的恢復(fù)），需要有分區(qū)開始前、進行中、恢復(fù)后的處理策略，應(yīng)用合適的補償處理機制。像RocketMQ這樣的分布式消息引擎，更多的追求AP。再強的系統(tǒng)也一定有容量底線，足夠的容量是可用性的有效前提。通常情況下，會通過降級、限流、熔斷機制來保障洪峰下的可用性。具體的技術(shù)細節(jié)可以參看電子書章節(jié)1另外，考慮到在金融高頻交易典型場景，我們也為RocketMQ設(shè)

16、計了CP機制，在滿足分布式系統(tǒng)的分區(qū)容錯性的前提下，犧牲系統(tǒng)可用性來保證數(shù)據(jù)的一致性。而技術(shù)實現(xiàn)上，則基于Zab一致性協(xié)議，利用分布式鎖和通知機制，以此來保障多副本數(shù)據(jù)的一致性。開源捐贈和社區(qū)運營 目前國內(nèi)外有很多公司會把一些通用問題的解決方案，尤其是那些久經(jīng)考驗、愈久彌堅的產(chǎn)品開源出來，以期望在品牌宣傳、人才引進方面有所建樹。把RocketMQ開源出來，甚至捐贈給Apache，內(nèi)部也是經(jīng)過了深思熟慮，層層審批與討論，期望能夠在生態(tài)化、規(guī)范化、國際化、商業(yè)化方面深耕細作。開源捐贈的想法實際上始于2014年。當(dāng)時，我們甄選了幾位Apache社區(qū)權(quán)威人士，遺憾的是反復(fù)溝通不斷修改草案之后突然間失去

17、了聯(lián)系。2015年，我們有幸結(jié)識了Kylin Principal Architect蔣旭和VP Luke以及Readhat Principal Software Engineer姜寧，請教了一些Apache禁忌事項，重新活躍起來了捐贈進程。接下來，最重要的是征集champion候選人，很開心的是ActiveMQ VP Bruce爽快地接收了我們的邀請，經(jīng)過前前后后接近100封郵件來往，我們終于正式開啟了Apache之旅。捐贈投票是在雙十一當(dāng)天，我們準(zhǔn)備充分很好地回答了評委會的犀利問題。不過，面對“中國開發(fā)者不喜歡郵件溝通”的突然刁難，還要感謝社區(qū)華人的防御性聲明回應(yīng)。經(jīng)過很多磨難，投票結(jié)果總算

18、出來了：還不算壞，10票贊同，帶binding（IPMC成員的有效投票）的+1，無反對票，正式進入孵化期。孵化成功后有望成為國內(nèi)首個互聯(lián)網(wǎng)中間件在Apache上的頂級項目，成為全球繼ActiveMQ，Kafka之后，分布式消息引擎家族中的重要成員。接下來，我們想強調(diào)下知識產(chǎn)權(quán)這個對大多數(shù)工程師來說陌生的領(lǐng)域，尤其是專利權(quán)、著作權(quán)、商標(biāo)權(quán)。在國外，每年因為這些問題導(dǎo)致的侵權(quán)官司不在少數(shù)。而我們在開源之初，對這塊的選擇、保護也是極其謹(jǐn)慎，包括開源許可協(xié)議的選擇、授權(quán)方面，代碼署名權(quán)等，這些都是很好的智力保護，也是我們產(chǎn)品的核心競爭力之一。尊重知識，尊重產(chǎn)權(quán)，才能構(gòu)建一個和諧積極向上的開源氛圍，打造真正的自主知識產(chǎn)權(quán)品牌產(chǎn)品。在Alibaba，我們基于開源引擎的RocketM