訊息中介軟體學習總結（1）——RocketMQ之專訪RocketMQ聯合創始人：專案思路、技術細節和未來規劃
編者按
這些年開源氛圍越來越好，各大IT公司都紛紛將一些自研程式碼開源出來。2012年，阿里巴巴開源其自研的第三代分散式訊息中介軟體——RocketMQ。經過幾年的技術打磨，阿里稱基於RocketMQ技術，目前雙十一當天訊息容量可達到萬億級。
2016年11月，阿里將RocketMQ捐獻給Apache軟體基金會，正式成為孵化專案。阿里稱會將其打造成頂級專案。這是阿里邁出的一大步，因為加入到開源軟體基金會需要經過評審方的考核與觀察。坦率而言，業界還對國人的程式碼開源參與度仍保持著刻板印象；而Apache基金會中的342個專案中，暫時還只有Kylin、CarbonData、Eagle 和 RocketMQ 共計四個中國技術人主導的專案。
2017年2月20日，RocketMQ正式釋出4.0版本，專家稱新版本適用於電商領域，金融領域，大資料領域，兼有物聯網領域的程式設計模型。
RocketMQ專案，究竟用怎樣的技術內涵？緣何贏得了基金會的初步認可？入駐基金會可以給技術圈哪些啟示？InfoQ帶著這樣的疑問對兩位專案聯合創始人進行了專訪，內容整理如下。
受訪者簡介
王小瑞，花名誓嘉，阿里巴巴中介軟體訊息團隊負責人，具有豐富的高可用，高可靠分散式系統構建經驗，主導了阿里巴巴多次雙十一訊息引擎的改進優化專案，擁有多項分散式領域的專利。Apache RocketMQ聯合創始人。聯絡方式: [email protected]
馮嘉
RocketMQ的由來
談起RocketMQ的亮點，那不得不先提一下阿里巴巴訊息引擎的演進史。阿里中介軟體訊息引擎發展到今日，前前後後經歷了三代演進。
第一代，推模式，資料儲存採用關係型資料庫。在這種模式下，訊息具有很低的延遲特性，並且很容易支援分散式事務。尤其在阿里淘寶這種高頻交易場景中，具有非常廣泛地應用。典型代表包括Notify、Napoli。
第二代，拉模式，自研的專有訊息儲存。在日誌處理方面能夠媲美Kafka的吞吐效能，但考慮到淘寶的應用場景，尤其是其交易鏈路的高可靠需求，訊息引擎並沒有一味的追求吞吐，而是將穩定可靠放在首位。因為採用了長連線拉模式，在訊息的實時方面絲毫不遜推模式。典型代表MetaQ。
第三代，以拉模式為主，兼有推模式的高效能、低延遲訊息引擎RocketMQ，在二代功能特性的基礎上，為電商金融領域添加了可靠重試、基於檔案儲存的分散式事務等特性，並做了大量優化。從2012年開始，經歷了歷次雙11核心交易鏈路檢驗。目前已經捐贈給Apache基金會。時至今日，RocketMQ很好的服務了阿里集團大大小小上千個應用，在雙11當天，更有不可思議的萬億級訊息流轉，為集團大中臺的穩定發揮了舉足輕重的作用。
不難看出，RocketMQ其實是伴隨著阿里巴巴整個生態的成長，逐漸衍生出來的高效能、低延遲能夠同時滿足電商領域和金融領域的極盡苛刻場景的訊息中介軟體。
RocketMQ的技術概覽
在我們看來，它最大的創新點在於能夠通過精巧的橫向、縱向擴充套件，不斷滿足與日俱增的海量訊息在高吞吐、高可靠、低延遲方面的要求。
目前RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分構成，如下圖所示。
所有的叢集都具有水平擴充套件能力，無單點障礙。
NameServer以輕量級的方式提供服務發現和路由功能，每個NameServer存有全量的路由資訊，提供對等的讀寫服務，支援快速擴縮容。
Broker負責訊息儲存，以Topic為緯度支援輕量級的佇列，單機可以支撐上萬佇列規模，支援訊息推拉模型，具備多副本容錯機制（2副本或3副本）、強大的削峰填谷以及上億級訊息堆積能力，同時可嚴格保證訊息的有序性。除此之外，Broker還提供了同城異地容災能力，豐富的Metrics統計以及告警機制。這些都是傳統訊息系統無法比擬的。
Producer由使用者進行分散式部署，訊息由Producer通過多種負載均衡模式傳送到Broker叢集，傳送低延時，支援快速失敗。
Consumer也由使用者部署，支援PUSH和PULL兩種消費模式，支援叢集消費和廣播訊息，提供實時的訊息訂閱機制，滿足大多數消費場景。
經歷雙11洗禮的英雄
在備戰2016年雙十一時，團隊重點做了兩件事情，優化慢請求與統一儲存引擎。
- 優化慢請求：這裡主要是解決在海量高併發場景下降低慢請求對整個叢集帶來的抖動，毛刺問題。這是一個極具挑戰的技術活，團隊同學經過長達1個多月的跟進調優，從雙十一的覆盤情況來看，99.996%的延遲落在了10ms以內，而99.6%的延遲在1ms以內。優化主要集中在RocketMQ儲存層演算法優化、JVM與作業系統調優。更多的細節大家可以參考我們之前寫的電子書章節《萬億級資料洪峰下的分散式訊息引擎》。
- 再來看看統一儲存引擎：主要解決的訊息引擎的高可用，成本問題。在多代訊息引擎共存的前提下，我們對Notify的儲存模組進行了全面移植與替換。
這樣下來，阿里巴巴內部的訊息中介軟體就全面擁抱了RocketMQ的低延遲儲存引擎。基於上述積極的技術準備，在16年雙十一期間，阿里集團大約有1.2萬億級的訊息流轉總量，幾乎是15年雙十一大促的2倍。峰值期間，訊息生產的吞吐在2000 w/s左右，訊息消費的吞吐也近乎1500 w/s的量級。整個大促下來，用我們內部的話來說，如絲般順滑。
RocketMQ VS 其他幾個訊息中介軟體
請從技術構思、實踐表現和適用場景三個大方向對RocketMQ、RabbitMQ、Kafka、ActiveMQ和ZeroMQ進行對比？除了技術上的較量，可否對這些中介軟體背後的社群運營、商業案例應用，進行對比呢？
1、是不是CS架構？
如果需要做同類產品之間的橫向對比，我們優先拿下ZeroMQ，ZeroMQ正如其名0MQ，它更像是一個嵌入式的網路類庫，一個專注於transports層的通訊元件，而不是傳統意義上的CS架構的MQ。
2、實現的哪種規範 / 協議？
接下來我們來看看RabbitMQ、ActiveMQ、Kafka和RocketMQ之間的一些對比，從設計思路上來看，RabbitMQ是AMQP規範的參考實現，AMQP是一個線路層協議，面面俱到，很系統，也稍顯複雜。目前RabbitMQ已經成為OpenStack Iaas平臺首選的訊息服務，其背後的支援力度不言而喻。
ActiveMQ最初主要的開發者在LogicBlaze，現在主要開發紅帽，是JMS規範的參考實現，也是Apache旗下的老牌訊息服務引擎。JMS雖說是一個API級別的協議，但其內部還是定義了一些實現約束，不過缺少多語言支撐。ActiveMQ的生態堪稱豐富多彩，在該Apache頂級專案下，擁有不少子專案，包括由HornetMQ演變而來的Artemis，基於Scala號稱下一代AMQ的Apollo等。
3、適用何類場景？
而Kafka最初被設計用來做日誌處理，是一個不折不扣的大資料通道，追求高吞吐，存在丟訊息的可能。其背後的研發團隊也圍繞著Kafka進行了商業包裝，目前在一些中小型公司被廣泛使用，國內也有不少忠實的擁捧著。
RocketMQ天生為金融網際網路領域而生，追求高可靠、高可用、高併發、低延遲，是一個阿里巴巴由內而外成功孕育的典範，除了阿里集團上千個應用外，根據我們不完全統計，國內至少有上百家單位、科研教育機構在使用。關於這幾個MQ產品更詳細的特性對比，可以參考我們官網上的說明。
三項技術發力點
（一）訊息的順序
不可否認，順序訊息是RocketMQ功能特性上的一個賣點。目前我們做到了全域性保序。需要重點說一下，這裡的全域性是有前提，針對某個唯一標識（能夠被Hash成唯一標識），比方說大賣家賬號，某類產品的訂單等。其技術實現原理也相對比較簡單，保證對通道的單一例項操作，如單程序、單執行緒寫，單程序、執行緒讀，像ActiveMQ的Exclusive Consumer也是類似的實現。
不難看出，這種實現方式實際是在吞吐上做出了一定犧牲。另外也帶來了另外一個問題 - 熱點。如雙十一當天，如果使用簡單的雜湊策略，像短期內就交易過億的天貓商家的訊息會發送到一個通道里面，造成單通道，甚至單機的熱點問題在最新的RocketMQ版本里，我們將會改進目前的實現，藉此改善因為順序導致的單通道熱點問題，這個特性預計今年中旬會發布。
（二）訊息的去重
訊息領域有一個對訊息投遞的QoS定義，分為：最多一次（At most once），至少一次（At least once），僅一次（ Exactly once）。
幾乎所有的MQ產品都聲稱自己做到了At least once。既然是至少一次，那避免不了訊息重複，尤其是在分散式網路環境下，而這個缺憾歸根結底也可以看做是TCP協議的一部分，如失敗重傳。業務上往往對訊息重複又很敏感，RocketMQ目前的版本是不支援去重的，我們通常建議使用者通過外接全域性儲存自己做判重處理。在下一代的特性規劃裡，我們會內建解決方案。先說下業界通用做法，像Artemis，IronMQ等，通過在服務端全域性儲存判重。這是一個IO敏感的操作，為服務端帶來一定的負載。而RocketMQ則希望通過採取二次判重策略，有效降低服務端IO。
（三）分散式的挑戰
首先明確分散式系統這個概念：分散式系統是由一系列分散自治元件通過網際網路並行併發協作，從而組成的一個coherent軟體系統。它具備資源共享，並行併發，可靠容錯，透明開放等特性。像CAP，BASE，Paxos，事務等一起構成了分散式基礎理論。
這裡我們再來重溫下CAP理論：CAP分別代表一致性（Consistency），可用性（Availability），分割槽容忍性（Partition tolerance）。一致性，Eric Brewer（CAP理論提出者）用一個服務要麼被執行，要麼不被執行來定義(原文：A service that is consistent operates fully or not at all)。請注意，這裡的一致性是有別於資料庫ACID屬性中的C，資料庫層面的C指的是資料的操作不能破壞資料之間的完整性約束，如外來鍵約束。在分散式環境中，可以把C簡單理解為多節點看到的是資料單一或者同一副本。可用性，意味著服務是可用的（原文：the service is available (to operate fully or not as above)）。可用性又可以細分為寫可用和讀可用。在分散式環境中，往往指的是系統在確定時間內可返回讀寫操作結果，也即讀寫均可用。分割槽容忍性，除了整個網路故障外（如光纖被掘斷），其它故障（如丟包、亂序、抖動、甚至是網路分割槽節點 crash ）都不能導致整個系統無法正確響應（原文：No set of failures less than total network failure is allowed to cause the system to respond incorrectly）。
CAP理論可以看做是探索適合不同應用的一致性與可用性平衡問題。
- 沒有分割槽的情況：可以同時滿足C與A，以及完整的ACID事務支援。可以選擇犧牲一定的C，獲得更好的效能與擴充套件性。
- 分割槽的情況：選擇A（集中關注分割槽的恢復），需要有分割槽開始前、進行中、恢復後的處理策略，應用合適的補償處理機制。像RocketMQ這樣的分散式訊息引擎，更多的追求AP。再強的系統也一定有容量底線，足夠的容量是可用性的有效前提。通常情況下，會通過降級、限流、熔斷機制來保障洪峰下的可用性。具體的技術細節可以參看電子書章節。
另外，考慮到在金融高頻交易典型場景，我們也為RocketMQ設計了CP機制，在滿足分散式系統的分割槽容錯性的前提下，犧牲系統可用性來保證資料的一致性。而技術實現上，則基於Zab一致性協議，利用分散式鎖和通知機制，以此來保障多副本資料的一致性。
開源捐贈和社群運營
目前國內外有很多公司會把一些通用問題的解決方案，尤其是那些久經考驗、愈久彌堅的產品開源出來，以期望在品牌宣傳、人才引進方面有所建樹。把RocketMQ開源出來，甚至捐贈給Apache，內部也是經過了深思熟慮，層層審批與討論，期望能夠在生態化、規範化、國際化、商業化方面深耕細作。
開源捐贈的想法實際上始於2014年。當時，我們甄選了幾位Apache社群權威人士，遺憾的是反覆溝通不斷修改草案之後突然間失去了聯絡。2015年，我們有幸結識了Kylin Principal Architect蔣旭和VP Luke以及RedHat Principal Software Engineer姜寧，請教了一些Apache禁忌事項，重新活躍起來了捐贈程序。接下來，最重要的是徵集champion候選人，很開心的是ActiveMQ VP Bruce爽快地接收了我們的邀請，經過前前後後接近100封郵件來往，我們終於正式開啟了Apache之旅。捐贈投票是在雙十一當天，我們準備充分很好地回答了評委會的犀利問題。不過，面對“中國開發者不喜歡郵件溝通”突然刁難，還要感謝社群華人的防禦性宣告迴應。經過很多磨難，投票結果總算出來了：還不算壞10票贊同，帶binding（IPMC成員的有效投票）的+1，無反對票，正式進入孵化期。孵化成功後有望成為國內首個網際網路中介軟體在Apache上的頂級專案，成為全球繼ActiveMQ，Kafka之後，分散式訊息引擎家族中的重要成員。
接下來，我們想強調下智慧財產權這個對大多數工程師來說陌生的領域，尤其是專利權、著作權、商標權。在國外，每年因為這些問題導致的侵權官司不在少數。而我們在開源之初，對這塊的選擇、保護也是極其謹慎，包括開源許可協議的選擇、授權方面，程式碼署名權等，這些都是很好的智力保護，也是我們產品的核心競爭力之一。尊重知識，尊重產權，才能構建一個和諧積極向上的開源氛圍，打造真正的自主智慧財產權品牌產品。
在Alibaba，我們基於開源引擎的RocketMQ，為雲上使用者提供了商業化版本的Aliware MQ。兩個產品都是由阿里中介軟體訊息團隊出品。商業版Aliware MQ 在支援 TCP 、HTTP 和MQTT 協議接入，功能方面增強了運維管控方面，生態整合的能力（包括視覺化的訊息軌跡、資源報表統計以及監控報警、Kafka整合等）。它在公有云上本身具備多機房部署同城高可用容災特性，目的是滿足企業級要求。
關於社群的運營，我們採取了和Apache頂級專案基本相似的策略。首先，必須立足於高質量產品本身，從版本規劃開始，我們建立了里程碑討論，Features設計，編碼自測，結對Review，整合測試，Release討論，Release公告等等一系列規範且高效的軟體研發流程。其次，在社群運營層面，則有一系列與社群互動的活動，如線下meetup、workshop、ApacheCon、不定期的程式設計馬拉松等，吸納新的Contributor和Committer進來。
新一代RocketMQ，蓄勢待發
最近，團隊也在著手構建下一代RocketMQ，期望構建一套廠商無關的集線路層、API層於一體的規範，這也是第四代訊息引擎最大的亮點。目前，我們聯絡了Twitter、Yahoo等公司相關技術負責人，共同起草完善這一規範，而RocketMQ將會是第一批率先成為參考實現的產品。我們非常期望國內的MQ廠商亦或是分散式愛好者能夠參與進來，積極在國際開源社群代表國人發聲吶喊。
另外，本週，團隊剛剛釋出了第四代引擎的第一個版本，該版本也是進入Apache社群後的首次發版。按照我們的規劃，將在今年4月左右完成整個引擎的升級重組，非常歡迎大家的使用、反饋以及參與。