這些年開源氛圍越來越好，各大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]
馮嘉，花名鼬神，阿裡巴巴中間件架構師，具有豐富的分布式軟體架構、高并發網站設計、性能調優經驗，擁有多項分布式領域的專利。開源愛好者，專注分布式、大資料領域，關注hbase/hadoop/spark/flink等大資料技術棧。目前負責阿裡消息中間件生态輸出、雲上商業化，apache rocketmq聯合創始人。聯系方式: [email protected]
談起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兩種消費模式，支援叢集消費和廣播消息，提供實時的消息訂閱機制，滿足大多數消費場景。
在備戰2016年雙十一時，團隊重點做了兩件事情，優化慢請求與統一存儲引擎。
優化慢請求：這裡主要是解決在海量高并發場景下降低慢請求對整個叢集帶來的抖動，毛刺問題。這是一個極具挑戰的技術活，團隊同學經過長達1個多月的跟進調優，從雙十一的複盤情況來看，99.996%的延遲落在了10ms以内，而99.6%的延遲在1ms以内。優化主要集中在rocketmq存儲層算法優化、jvm與作業系統調優。更多的細節大家可以參考我們之前寫的電子書章節《萬億級資料洪峰下的分布式消息引擎》[1]。
再來看看統一存儲引擎：主要解決的消息引擎的高可用，成本問題。在多代消息引擎共存的前提下，我們對notify的存儲子產品進行了全面移植與替換。
這樣下來，阿裡巴巴内部的消息中間件就全面擁抱了rocketmq的低延遲存儲引擎。基于上述積極的技術準備，在16年雙十一期間，阿裡集團大約有1.2萬億級的消息流轉總量，幾乎是15年雙十一大促的2倍。峰值期間，消息生産的吞吐在2000 w/s左右，消息消費的吞吐也近乎1500 w/s的量級。整個大促下來，用我們内部的話來說，如絲般順滑。
請從技術構思、實踐表現和适用場景三個大方向對rocketmq、rabbitmq、kafka、activemq和zeromq進行對比？除了技術上的較量，可否對這些中間件背後的社群營運、商業案例應用，進行對比呢？
<b>1、是不是cs架構？</b>
如果需要做同類産品之間的橫向對比，我們優先拿下zeromq，zeromq正如其名0mq，它更像是一個嵌入式的網絡類庫，一個專注于transports層的通訊元件，而不是傳統意義上的cs架構的mq。
<b>2、實作的哪種規範 / 協定？</b>
接下來我們來看看rabbitmq、activemq、kafka和rocketmq之間的一些對比，從設計思路上來看，rabbitmq是amqp規範的參考實作，amqp是一個線路層協定，面面俱到，很系統，也稍顯複雜。目前rabbitmq已經成為openstack iaas平台首選的消息服務，其背後的支援力度不言而喻。
activemq最初是由紅帽子捐贈給apache的，是jms規範的參考實作，也是apache旗下的老牌消息服務引擎。jms雖說是一個api級别的協定，但其内部還是定義了一些實作限制，不過缺少多語言支撐。activemq的生态堪稱豐富多彩，在該apache頂級項目下，擁有不少子項目，包括由hornetmq演變而來的artemis，基于scala号稱下一代amq的apollo等。
<b>3、适用何類場景？</b>
而kafka最初被設計用來做日志處理，是一個不折不扣的大資料通道，追求高吞吐，存在丢消息的可能。其背後的研發團隊也圍繞着kafka進行了商業包裝，目前在一些中小型公司被廣泛使用，國内也有不少忠實的擁捧着。
rocketmq天生為金融網際網路領域而生，追求高可靠、高可用、高并發、低延遲，是一個阿裡巴巴由内而外成功孕育的典範，除了阿裡集團上千個應用外，根據我們不完全統計，國内至少有上百家機關、科研教育機構在使用。關于這幾個mq産品更詳細的特性對比，可以參考我們官網上的說明[2]。
<b>（一）消息的順序</b>
不可否認，順序消息是rocketmq功能特性上的一個賣點。目前我們做到了全局保序。需要重點說一下，這裡的全局是有前提，針對某個唯一辨別（能夠被hash成唯一辨別），比方說大賣家賬号，某類産品的訂單等。其技術實作原理也相對比較簡單，保證對通道的單一執行個體操作，如單程序、單線程寫，單程序、線程讀，像activemq的exclusive consumer也是類似的實作。
不難看出，這種實作方式實際是在吞吐上做出了一定犧牲。另外也帶來了另外一個問題 - 熱點。如雙十一當天，如果使用簡單的散列政策，像短期内就交易過億的天貓商家的消息會發送到一個通道裡面，造成單通道，甚至單機的熱點問題在最新的rocketmq版本裡，我們将會改進目前的實作，借此改善因為順序導緻的單通道熱點問題，這個特性預計今年中旬會釋出。
<b>（二）消息的去重</b>
消息領域有一個對消息投遞的qos定義，大緻可分為：最多一次（at most once），至少一次（at least once），僅一次（ exactly once）。
幾乎所有的mq産品都聲稱自己做到了at least once。既然是至少一次，那避免不了消息重複，尤其是在分布式網絡環境下，而這個缺憾歸根結底也可以看做是tcp協定的一部分，如失敗重傳。業務上往往對消息重複又很敏感，rocketmq目前的版本是不支援去重的，我們通常建議使用者通過外置全局存儲自己做判重處理。在下一代的特性規劃裡，我們會内置解決方案。先說下業界通用做法，像artemis，ironmq等，通過在服務端全局存儲判重。這是一個io敏感的操作，為服務端帶來一定的負載。而rocketmq則希望通過采取二次判重政策，有效降低服務端io。
<b>（三）分布式的挑戰</b>
首先明确分布式系統這個概念：分布式系統是由一系列分散自治元件通過網際網路并行并發協作，進而組成的一個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。再強的系統也一定有容量底線，足夠的容量是可用性的有效前提。通常情況下，會通過降級、限流、熔斷機制來保障洪峰下的可用性。具體的技術細節可以參看電子書章節[1]
另外，考慮到在金融高頻交易典型場景，我們也為rocketmq設計了cp機制，在滿足分布式系統的分區容錯性的前提下，犧牲系統可用性來保證資料的一緻性。而技術實作上，則基于zab一緻性協定，利用分布式鎖和通知機制，以此來保障多副本資料的一緻性。
目前國内外有很多公司會把一些通用問題的解決方案，尤其是那些久經考驗、愈久彌堅的産品開源出來，以期望在品牌宣傳、人才引進方面有所建樹。把rocketmq開源出來，甚至捐贈給apache，内部也是經過了深思熟慮，層層審批與讨論，期望能夠在生态化、規範化、國際化、商業化方面深耕細作。
開源捐贈的想法實際上始于2014年。當時，我們甄選了幾位apache社群權威人士，遺憾的是反複溝通不斷修改草案之後突然間失去了聯系。2015年，我們有幸結識了kylin principal architect 蔣旭和vp luke以及readhat 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，期望建構一套廠商無關的集線路層、api層于一體的規範，這也是第四代消息引擎最大的亮點。目前，我們聯系了twitter、yahoo等公司相關技術負責人，共同起草完善這一規範，而rocketmq将會是第一批率先成為參考實作的産品。我們非常期望國内的mq廠商亦或是分布式愛好者能夠參與進來，積極在國際開源社群代表國人發聲呐喊。
另外，本周，團隊剛剛釋出了第四代引擎的第一個版本[5]，該版本也是進入apache社群後的首次發版。按照我們的規劃，将在今年4月左右完成整個引擎的更新重組，非常歡迎大家的使用、回報以及參與。
<b>來源：infoq 作者：木環</b>
<a href="http://www.infoq.com/cn/news/2017/02/rocketmq-future-idea" target="_blank"><b>原文連結</b></a>