中讀取對應的數據投遞失敗時，將該恢復索引放入所述恢復分區中的索引隊列的排序執行末端，等待下一次重試。
[0072]其中，所述索引分區中的索引，由文件名和文件組成，文件名為從零開始排序，排序在該文件名之后的文件名為該文件名加上該文件名對應的文件的格式大小的數值；其中，所述索引的大小為最多32個字節組成。
[0073]其中，每個索引分區的文件命名和數據隊列的名稱是一模一樣的，從零開始，下一個文件的文件名是上一個文件的文件名加上文件的大小，本申請中文件也是以DirectMapped Buffer (直接映射緩沖區)的方式打開，使用到操作系統的虛擬內存，因此索引的大小是固定的。
[0074]具體地，所謂文件名從零開始，是指數據分區的文件或者是索引分區的第一個文件命名是從零開始的，假設每個文件大小為1M，那么第一個文件名為“0000000000000000”，第二個文件名為“0000000001048576”，以此類推，方便根據索引快速定位數據所在的文件。Direct Mapped Buffer 是 JVM (Java Virtual Machine, Java 虛擬機)堆外內存，也就是說使用的內存不是java虛擬機自身的內存，而是操作系統的虛擬內存，操作系統將文件映射到自身內存中的一塊，可以對文件像內存一樣快速讀寫操作。本發明中索引大小是指每條索引自身的大小是固定的，數據隊列(DataQueue)和索引隊列(IndexQueue)中的每個文件大小也是固定的，另外索引是沒有排序的，索引是按自然順序存儲的，即順序寫，順序讀，索引存儲有對應數據所在的文件和位置信息，這種結構是增對消息中間件量身定做的，和普通的數據存儲引擎的索引存在很大的區別的。
[0075]具體地:
[0076]監控所述恢復分區中的索引隊列中的至少十個恢復索引從所述數據隊列中讀取對應的數據進行投遞的失敗率，若所述失敗率超過20%，則延時至少5秒鐘執行所述恢復分區從所述指針文件中獲取當前恢復指針指向的恢復索引所在的所述恢復分區的索引隊列位置。
[0077]上述提到的恢復分區，實際上是對投遞失敗的數據在進行處理，重新重試，以保證處理數據的完整性。也對失敗率達到一定數值如何進行處理進行了設置。
[0078]上述實施例一所述的方式，能夠通過創建的數據隊列將需要投遞的數據直接通過傳送的方式(transfer to)發送到socket的buffer上,無需經過JVM堆。
[0079]而且創建的索引隊列為順序存儲，讀取也為順序讀取，無需進行特殊排序在進行處理。
[0080]同時,本發明實施例一還可以通過臨時文件(Temp File,為一個空白文件,無任何內容)的檢查其是否存在，即該臨時文件在文件庫(Filestore)初始化時生成，在程序關閉時刪除，該臨時文件主要用于校驗是否正常關閉。如果文件庫(Filestore)初始化時發現有該臨時文件則會做清理臟數據的動作，根據數據隊列(DataQueue)文件末尾的數據刪除掉索弓I隊列(IndexQueue )文件末尾的臟索弓I。
[0081]如圖3所示，為本發明實施例三所述的一種用于中間件消息的存儲與傳輸系統，應用于文件庫中，該系統包括:存儲單元301、監測單元302、寫入傳輸單元303和讀取傳輸單元304 ;其中，
[0082]所述存儲單元301，分別與所述文件庫和所述監測單元302相耦接，用于在所述文件庫中創建數據隊列、索引隊列和指針文件，其中，該索引隊列包括對應于不同用戶的索引分區；所述數據隊列用于順序存儲用戶的數據，所述索引分區按照所屬用戶劃分，每個所述索引分區存儲該用戶在所述數據隊列中存儲的數據的索引，所述指針文件中的指針指向被讀取的數據的索引所在的所述索引分區的索引隊列位置；
[0083]所述監測單元302，與所述存儲單元301相耦接，用于監測到數據存入所述文件庫時，指示所述寫入傳輸單元；監測到讀取所述文件庫中的數據時，指示所述讀取傳輸單元；
[0084]所述寫入傳輸單元303，分別與所述存儲單元301和所述監測單元302相耦接，用于將該數據存入所述存儲單元301創建的數據隊列中，完成后將該數據對應的索引存儲到與該數據所屬用戶相對應的所述索引隊列中；
[0085]所述讀取傳輸單元304，分別與所述存儲單元301和所述監測單元302相耦接，用于從所述存儲單元301的指針文件中獲取當前指針指向的索引所在的所述索引分區的索引隊列位置，并根據該索引隊列位置獲取下一條索引，通過該索引從所述數據隊列中讀取對應的數據投遞完成，并更新所述指針文件中當前指針指向的索引所在的所述索引分區的索引隊列位置。
[0086]上述實施例三的系統中，所述存儲單元301，還用于在所述索引隊列中創建一恢復分區；
[0087]另外，對應的:
[0088]所述讀取傳輸單元304，還用于從所述存儲單元301的指針文件中獲取當前指針指向的索引所在的所述索引分區的索引隊列位置，并根據該索引隊列位置獲取下一條索弓丨，通過該索引從所述數據隊列中讀取對應的數據投遞失敗時，將該索引存入所述恢復分區中的索引隊列；
[0089]同時，監測到讀取所述文件庫中的數據時，所述恢復分區從所述指針文件中獲取當前恢復指針指向的恢復索引所在的所述恢復分區的索引隊列位置，并根據該索引隊列位置獲取下一條恢復索引，通過該恢復索引從所述數據隊列中讀取對應的數據投遞完成，并更新所述指針文件中當前恢復指針指向的索引所在的所述恢復分區的索引隊列位置。
[0090]針對上述內容，需要說明的是:所述讀取傳輸單元304，還用于通過該恢復索引從所述數據隊列中讀取對應的數據投遞失敗時，將該恢復索引放入所述存儲單元301的恢復分區中的索引隊列的排序執行末端。
[0091]以及，還用于監控所述恢復分區中的索引隊列中的至少十個恢復索引從所述數據隊列中讀取對應的數據進行投遞的失敗率，若所述失敗率超過20%，則延時至少5秒鐘執行所述恢復分區從所述指針文件中獲取當前恢復指針指向的恢復索引所在的所述恢復分區的索引隊列位置。
[0092]另外，上述實施例三中所述索引分區中的索引，由文件名和文件組成，文件名為從零開始排序，排序在該文件名之后的文件名為該文件名加上該文件名對應的文件的格式大小的數值；其中，所述索引的大小為最多32個字節組成。
[0093]由于方法部分已經對本申請實施例進行了詳細描述，這里對實施例中涉及的系統與方法對應部分的展開描述省略，不再贅述。對于系統中具體內容的描述可參考方法實施例的內容，這里不再具體限定。
[0094]本申請與現有的方案相比，本申請所獲得的技術效果:
[0095]I)本發明解決了消息中間件需要快速投遞消息，而且還能夠處理大量堆積消息的場景。
[0096]2)本發明還能夠實現同步和異步兩種模式的數據寫入操作，同步模式可以采用group commit的方式等待刷盤之后返回成功,異步模式則無需等待刷盤則直接返回。通過本發明寫入數據的性能得到了很大提高，異步模式耗時0.1毫秒，同步模式耗時2毫秒。
[0097]3)本發明還能夠保證數據處理的完整性，在本發明之前還可以包括:檢查臨時文件(tempFile)是否存在，如果存在，根據文件刷盤的時間戳(CheckPointFile)檢查數據最后一次刷盤的時間戳，然后根據這個時間戳找到數據隊列(DataQueue)中某個文件的某個位置，然后從該位置往后遍歷數據，每遍歷一條數據就把該數據恢復到對應的索引分區(Data queue中的數據有記錄索引的信息)，直至遍歷到(遍歷完)數據隊列中的最后一個文件。另外在遍歷數據隊列的過程中每讀取一條數據時還需要對該數據進行crc32檢驗，如果校驗失敗，則認為該文件后面的所有數據都是臟數據，需要全部刪除。在部署時磁盤需要配置raidlO策略執行雙寫，保證數據隊列的數據有備份。在文件庫(Filestore)的上層還可以實現HA的雙寫模式，即Master/Slave模式。
[0098]需要說明的是