[發明專利]用于中間件消息的存儲與傳輸方法及系統

有效

• 申請號: 201410022650.6
• 申請日: 2014-01-17
• 公開（公告）號: CN104794119B
• 公開（公告）日: 2018-04-03
• 發明（設計）人: 潘先進
• 申請（專利權）人: 阿里巴巴集團控股有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30;H04L29/08
• 代理公司: 北京國昊天誠知識產權代理有限公司11315
• 代理人: 許志勇

技術領域

本申請涉及網絡信息處理領域，具體地說，涉及一種用于中間件消息的存儲與傳輸方法及系統。

背景技術

在互聯網絡的時代，信息如同大海般沒有邊際。消息中間件是分布式系統中常用的一種消息通訊的組件，主要用于系統間的解耦，是一種以消息為通訊介質并且幫助轉發消息給不同的應用的分布式系統，與郵件系統類似。參與方按角色可以分為發送消息方，消息中間件服務器和訂閱消息方。消息中間件所在服務器承擔著消息的存儲和轉發，本發明對應的正是消息存儲和消息轉發這兩塊，是消息系統的核心功能，直接影響消息系統的性能和可靠性。

目前，在市面上開源的產品有kafka，ActiveMQ等，使用本地文件或者DB（database，數據庫）做為存儲介質并實現消息的發布和訂閱。

在這些消息中間件產品中，當使用本地文件存儲時不同應用需要的消息都是獨立存儲（獨立隊列）的，多個應用需要同一條消息時需要同時存多份，并且使用B+樹作為索引存儲，隨機讀寫直接增加磁盤IO的訪問頻率，并且使用java NIO對文件訪問，其結果是性能較低。

當使用DB作為消息中間件存儲介質時，除了B+樹的特性帶來磁盤隨機讀寫之外還多了一層網絡訪問，當大量消息堆積時直接導致DB產生swap（服務器性能評價指標），大量的事務和鎖操作直接導致服務器性能急劇下降，DB并不適合于消息中間件，需要快速投遞消息而又能夠大量堆積消息的場景。

根據上述內容，總結得出現有的技術缺點主要包括：

1、使用B+樹作為消息存儲的索引，B+樹涉及磁盤的隨機讀寫，嚴重影響性能。

2、多個訂閱方的索引都放在一個B+樹存儲里面，當B樹膨脹之后，造成性能極低。

3、受java JVM（Java Virtual Machine，Java虛擬機）本身限制，使用本地文件存儲時緩存小，緩存命中率低。

4、當對失敗消息需要進行頻繁更新索引，由于缺少精確的流控措施，難以保證性能穩定。

5、當消息投遞時需要對消息進行反序列化，由于經java JVM堆傳輸到socket，所以影響性能。

針對上述問題，如何提供一種能夠解決中間件消息數據的存儲與傳輸性能低的問題，便成為亟待解決的技術問題。

發明內容

有鑒于此，本申請所要解決的技術問題是提供了一種用于中間件消息的存儲與傳輸方法及系統，解決了消息中間件需要快速投遞消息，而且還需要處理大量堆積消息的場景。

為了解決上述技術問題，本申請公開了一種用于中間件消息的存儲與傳輸方法，應用于文件庫中，其特征在于，包括：

在所述文件庫中創建數據隊列、索引隊列和指針文件，其中，該索引隊列包括對應于不同用戶的索引分區；所述數據隊列用于順序存儲用戶的數據，所述索引分區按照所屬用戶劃分，每個所述索引分區存儲該用戶在所述數據隊列中存儲的數據的索引，所述指針文件中的指針指向被讀取的數據的索引所在的所述索引分區的索引隊列位置；

監測到數據存入所述文件庫時，將該數據存入所述數據隊列中，完成后將該數據對應的索引存儲到與該數據所屬用戶相對應的所述索引隊列中；

監測到讀取所述文件庫中的數據時，從指針文件中獲取當前指針指向的索引所在的所述索引分區的索引隊列位置，并根據該索引隊列位置獲取下一條索引，通過該索引從所述數據隊列中讀取對應的數據投遞完成，并更新所述指針文件中當前指針指向的索引所在的所述索引分區的索引隊列位置。

優選地，還包括：

所述索引隊列還包括一恢復分區；

監測到讀取所述文件庫中的數據時，從指針文件中獲取當前指針指向的索引所在的所述索引分區的索引隊列位置，并根據該索引隊列位置獲取下一條索引，通過該索引從所述數據隊列中讀取對應的數據投遞失敗時，將該索引存入所述恢復分區中的索引隊列；

同時，監測到讀取所述文件庫中的數據時，所述恢復分區從所述指針文件中獲取當前恢復指針指向的恢復索引所在的所述恢復分區的索引隊列位置，并根據該索引隊列位置獲取下一條恢復索引，通過該恢復索引從所述數據隊列中讀取對應的數據投遞完成，并更新所述指針文件中當前恢復指針指向的索引所在的所述恢復分區的索引隊列位置。

優選地，還包括：

通過該恢復索引從所述數據隊列中讀取對應的數據投遞失敗時，將該恢復索引放入所述恢復分區中的索引隊列的排序執行末端。

優選地，還包括：