京東-JMQ框架介紹

1、京東-JMQ框架京東-JMQJMQ是京東自主研發(fā)的一款消息中間件系統(tǒng)，具有高可用、數(shù)據(jù)高可靠等特性。廣泛應(yīng)用于公司內(nèi)部系統(tǒng)，包括訂單、支付、庫房等場景。1 .整體結(jié)構(gòu)系統(tǒng)包括服務(wù)端、客戶端、管理端與其他支撐模塊?？蛻艉鞪FS（JOURNALFILESYSTE時種字節(jié)級日志文件系統(tǒng)，借鑒了數(shù)據(jù)庫保護(hù)系統(tǒng)的技術(shù)，以日志的形式記錄文件的變化。JFS!過記錄文件結(jié)構(gòu)而不是數(shù)據(jù)本身的變化來保證數(shù)據(jù)的完整性。這種方式可以確保在任何時刻都能維護(hù)數(shù)據(jù)的可訪問性。Redis：是一個key-value存儲系統(tǒng)。和Memcached類似，它支持存儲的value類型相對更多，包括string（字符串）、list（鏈表

2、）、set（集合）、zset（sortedset-有序集合）和hash（哈希類型）。這些數(shù)據(jù)類型都支持push/pop、add/remove及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎(chǔ)上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數(shù)據(jù)都是緩存在內(nèi)存中。區(qū)別的是redis會周期性的把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎(chǔ)上實現(xiàn)了master-slave（主從）同步。HBase:HadoopDatabase,是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)，利用HBase技術(shù)可在廉價PCServer上搭建起大規(guī)

3、模結(jié)構(gòu)化存儲集群。京東-JMQ1.1. 服務(wù)端服務(wù)端提供了配置信息分發(fā)、重試消息管理和消息存儲與分發(fā)這三大類功能。每個服務(wù)端實例都具備這三類功能的服務(wù)能力，但是在實際部署上這三類功能對應(yīng)三個不同的集群，對應(yīng)每一個實例功能不疊加。在測試環(huán)境和庫房等資源有限的環(huán)境下，這三類功能由同一個服務(wù)端實例提供服務(wù)。配置信息分發(fā)：負(fù)責(zé)客戶端參數(shù)變更時與消息分配的服務(wù)端實例變更時通知客戶端。重試消息管理：主要用于對業(yè)務(wù)系統(tǒng)臨時處理不了的消息進(jìn)行存放，然后再按照一定的策略投遞給客戶端處理。可以提供錯誤原因、錯誤處理次數(shù)等查詢。消息存儲與分發(fā)：接收生產(chǎn)者投遞的消息，把消息存放在本地磁盤上，消費者從該服務(wù)上拉取消息進(jìn)

4、行消費。1.2. 客戶端目前只提供了JAVA語言的SDK和支持HTTP協(xié)議的proxy,非JAVA語言通過proxy接入。1.3. 管理端主要功能有：接入申請、消息元數(shù)據(jù)管理、重試消息信息查詢、消息發(fā)送和消費日志查詢、服務(wù)端狀態(tài)信息管理查看、客戶端連接信息管理查看等。1.4. 支撐模塊主要有報警模塊、任務(wù)模塊、歸檔模塊、信息采集模塊等。1.5. 數(shù)據(jù)可靠性針對公司的業(yè)務(wù)特點，消息服務(wù)主要應(yīng)用于訂單、支付、物流等環(huán)節(jié)。服務(wù)端采用MASTER-SLAVED構(gòu),消息在正常情況下會同時存放兩份，其中一份會強(qiáng)制持久化到磁盤，磁盤做RAID-5。默認(rèn)情況下客戶端采用京東-JMQ同步發(fā)送，每條消息到達(dá)服務(wù)端

5、MASTER后會強(qiáng)制刷入磁盤同時并行推送一份到SLAVE±,SLAVE寫入文件系統(tǒng)后不等待強(qiáng)制刷盤就反饋給MASTER根據(jù)不同的場景為了提高服務(wù)的可用性，普通級別的消息SLAVE斷開后，該組服務(wù)可以正常使用，當(dāng)SLAVED接上后又會自動切換為保存兩份。當(dāng)然對數(shù)據(jù)可靠級別高的消息是強(qiáng)制要求數(shù)據(jù)必須寫兩份才算成功的。1.6. 服務(wù)高可用每類消息一般都會分配3組及以上的服務(wù)組，每組服務(wù)包括一個MASTER和一個SLAVE當(dāng)然如果有需要也可以掛載多個SLAVE客戶端發(fā)送消息時，如果其中一組出現(xiàn)故障會重試發(fā)送給其他的組。雖然MASTER-SLAV或持切換，提高服務(wù)的可用性，但是在實際生產(chǎn)中MA

6、STER出現(xiàn)故障時會優(yōu)先采用通過其他服務(wù)組自動接替生產(chǎn)服務(wù)的方式，本組服務(wù)只提供從SLAVE賣取的方式，而不是讓SLAV強(qiáng)替MASTER的寫入，避免臨界狀態(tài)下丟失消息。對要求嚴(yán)格順序的消息，不能通過簡單的切換服務(wù)組實現(xiàn)，具體實現(xiàn)方式參考高可用保證消息絕對順序消費的BROKE淞計方案（點擊“閱讀原文”查看這篇文章）。1.7. 消費模型由于公司以前有使用基于ACTIVEMQ二次開發(fā)的服務(wù)，服務(wù)端會存放客戶端的消費位置，因此在自主研發(fā)JMQ時也延續(xù)了這種方式（可以兼容ACTIVEMQ的客戶端）。但是ACTIVEMQ生產(chǎn)和消費都會操作索引文件，影響性能，JMQ吸取了這個經(jīng)驗教訓(xùn)。消費者在消費時按照索引

7、分區(qū)順序的消費，消費確認(rèn)時只需要變更最后確認(rèn)位置的值，不需要操作索引文件，而且多個消費者共用一個索引文件，各自保存自己的消費偏移位置就可以了。當(dāng)然在實踐過程中，由于一些特殊場景需要，會允許一定范圍內(nèi)不完全按照順序消費，但是服務(wù)端會記錄已經(jīng)消費的索引區(qū)間。與KAFKA的對比順序追加等特點。JMQ在服務(wù)端存儲設(shè)計上與KAFKA有一些相似的地方，借鑒了文件按照偏移位置管理、京東-JMQ不過JMQ的存儲和消費模型有自己的特點:1.8. 消息存放JMQ每個存儲系統(tǒng)只有一個分段存儲的日志文件，不同類的消息按照服務(wù)端接收的順序存放在日志文件中，通過索引程序按照不同的消息（主題）分類名異步創(chuàng)建各自的索引，方便

8、消費端獲取消息時快速定位該客戶端所關(guān)心的（主題）分類消息。每個（主題）分類的索引劃分了多個分區(qū)，同一（主題）分類的消息分配在多組服務(wù)器上的分區(qū)數(shù)是相同的。每個索引分區(qū)都是以鏈表按照時間序存放消息引用信息。消費JMQ也采用客戶端主動拉取的方式，但是客戶端不需要協(xié)調(diào)自己應(yīng)該從哪個服務(wù)器上獲取消息，服務(wù)端會控制好每個索引分區(qū)里對應(yīng)的消息在同一時刻只會被一個客戶端線程取走，直到客戶端反饋消費成功或者消費異常，消費異常會被重試程序轉(zhuǎn)移到重試服務(wù)中。如果客戶端長時間沒有反饋信息，達(dá)到了超時時間，那么鎖定的消息可以被其他的線程拉取走。由于服務(wù)端儲存了每個消費者消費的位置，因此服務(wù)器可以隨時把已經(jīng)消費的消息移

9、除走。2 .主要特性與場景2.1. 發(fā)布與訂閱目前公司接入的消息絕大部分都采用這種方式，不同類的消息通過主題名進(jìn)行區(qū)分，多個消費者分組之間各自消費一份完整的消息內(nèi)容，他們看到的消費視圖一模一樣，唯一的區(qū)別就是各自消費進(jìn)度不同。同一個消費分組內(nèi)的消費實例只會消費到其中一部分消息，各自連接服務(wù)端，通過搶占的方式進(jìn)行消費。場景：以訂單消息為例，訂單系統(tǒng)在訂單的生命周期里的每一次變更都會發(fā)送消息，訂單查詢系統(tǒng)、結(jié)算系統(tǒng)、庫房生產(chǎn)系統(tǒng)等都會訂閱該類型的消息，每個系統(tǒng)拿到一份完整的消息，各自進(jìn)行處理。2.2. 廣播由于發(fā)布訂閱型的主題消息，如果要獲取一份完整的消息就需要命名一個消費組，如果一類消息每個消費

10、者實例都需要獲取一份完整的消息，如果還按照主題消息管理那么就需要為每一個實例命名一個唯一的標(biāo)識，使用時非常不方便，這時可以使用廣播類型的消息，每個消費廣播消息的實例都會拿到一份完整消息。場景：分布式數(shù)據(jù)庫接入層對應(yīng)的服務(wù)端拓?fù)湫畔⑿枰{(diào)整，客戶端可以訂閱一個拓?fù)渥兏膹V播消息，提前把需要變更的拓?fù)湫畔⑾掳l(fā)給每個客戶端備用，當(dāng)捕捉到拓?fù)渥兏漠惓：缶蛦⒂脗溆猛負(fù)湫畔ⅰ＞〇|-JMQ2.3. 順序消費消息的消費會根據(jù)服務(wù)端接收到的順序，依次推送給客戶端消費，消息如果亂序可能會引起最終結(jié)果不正常。場景:數(shù)據(jù)庫binglog日志基于消息系統(tǒng)進(jìn)行復(fù)制，接收到消息的客戶端可以更新ElasticSearch中

11、的索弓I信息,可以彳改Redis中的值，同時也可以基于日志重放同步數(shù)據(jù)到一個全量的數(shù)據(jù)庫中。如果有一條記錄的更新和刪除操作亂序到達(dá)消費端，那么各個系統(tǒng)的狀態(tài)將會不一致。2.4. 索引分區(qū)并行消費默認(rèn)情況下，每個索引分區(qū)的消息只能夠按照順序依次進(jìn)行消費，如果索引分區(qū)內(nèi)有一條消息處理比較慢，就會阻塞后面消息的處理，導(dǎo)致消息積壓，影響消息的實時性。為了解決這個問題，可以增大索引分區(qū)數(shù)，但是每個索引分區(qū)對應(yīng)獨立的文件夾，增大會導(dǎo)致文件夾數(shù)目擴(kuò)大，而且不能根本解決，只是一定程度緩解積壓的消息數(shù)目。如果讓單個索引分區(qū)內(nèi)的消息可以并行的把不同區(qū)間的消息發(fā)送給客戶端處理，這樣如果有某條消息處理慢，服務(wù)端可以把

12、后面的消息交給空閑的客戶端線程去處理，當(dāng)連續(xù)多個區(qū)間的消息都消費后再統(tǒng)一合并為一個大的消費區(qū)間，減少服務(wù)端需要記錄的已消費區(qū)間數(shù)。場景:有一個通過消息派發(fā)任務(wù)的應(yīng)用，每個任務(wù)執(zhí)行時間長短不一，消費端獲取到消息后，根據(jù)消息構(gòu)建任務(wù)執(zhí)行，任務(wù)完成后反饋給服務(wù)端消費成功。由于任務(wù)執(zhí)行時間長短不一樣，因此客戶端的超時時間只能以最長的時間為參考進(jìn)行設(shè)置，避免任務(wù)在執(zhí)行過程中由于超時被其他線程重復(fù)處理。但是當(dāng)一個時間相對長的任務(wù)在執(zhí)行時，它會占用該消息所在索引分區(qū)被鎖定，后面的任務(wù)不能及時派發(fā)給空閑的客戶端處理。這時服務(wù)端如果啟用索引分區(qū)并行消費的特性，就可以及時的把后面的任務(wù)派發(fā)給其他的客戶端去執(zhí)行，同

13、時也不需要調(diào)整索引的分區(qū)數(shù)。2.5. 事務(wù)消息事務(wù)消息具有回滾的特點，當(dāng)消息發(fā)送給服務(wù)端未提交前，如果關(guān)聯(lián)的其他業(yè)務(wù)操作失敗，客戶端可以主動發(fā)起回滾，當(dāng)回滾或者提交事務(wù)消息時網(wǎng)絡(luò)故障，消息系統(tǒng)會主動調(diào)用客戶端的事務(wù)狀態(tài)查詢接口，根據(jù)客戶端查詢到的事務(wù)狀態(tài)決定消息是否提交或回滾。這樣就能夠保證消息系統(tǒng)和業(yè)務(wù)系統(tǒng)數(shù)據(jù)狀態(tài)最終完全一致。利用消息系統(tǒng)會主動查詢不確定狀態(tài)消息的特點，可以做為多個資源的事務(wù)協(xié)調(diào)器使用。場景:變更缺貨商品的庫存信息時，需要更新下單系統(tǒng)中的庫存數(shù)，需要通知搜索系統(tǒng)修改商品索引，需要通知網(wǎng)頁緩存系統(tǒng)刷新。各個系統(tǒng)之間由于各種網(wǎng)絡(luò)或服務(wù)等原因造成狀態(tài)不一致。可能出現(xiàn)庫存變更了，其他系統(tǒng)的商品可銷售狀態(tài)沒有修改正確，或者出現(xiàn)庫存數(shù)據(jù)修改失敗，但是其他系統(tǒng)的商品狀態(tài)發(fā)生了變更。只能通過一些核對系統(tǒng)定期的把各個系統(tǒng)中的不一致狀態(tài)變更為一致，加大了開發(fā)工作量，而且定期掃描可京東-JMQ能引發(fā)性能問題。通過事務(wù)消息，可以很好的解決這類場景，不會因為網(wǎng)絡(luò)不可用等原因出現(xiàn)系統(tǒng)之間狀態(tài)不一致。當(dāng)更新任何一個服務(wù)出現(xiàn)故障時就拋出異常，事務(wù)消息不會被提交或回滾，消息服務(wù)器