用于中间件消息的存储与传输方法及系统.pdf

本申请公开了用于中间件消息的存储与传输方法及系统，方法为：在文件库中创建数据队列、索引队列和指针文件；监测到数据存入文件库时，将该数据存入数据队列中，完成后将该数据对应的索引存储到与该数据所属用户相对应的索引队列中；监测到读取文件库中的数据时，从指针文件中获取当前指针指向的索引所在的索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从数据队列中读取对应的数据投递完成，并更新指针文件中当前指针指向的索引所在的索引分区的索引队列位置。本发明解决了消息中间件需要快速投递消息，而且还需要处理大量堆积消息的场景。

权利要求书1.  一种用于中间件消息的存储与传输方法，应用于文件库中，其特征在于，包括：在所述文件库中创建数据队列、索引队列和指针文件，其中，该索引队列包括对应于不同用户的索引分区；所述数据队列用于顺序存储用户的数据，所述索引分区按照所属用户划分，每个所述索引分区存储该用户在所述数据队列中存储的数据的索引，所述指针文件中的指针指向被读取的数据的索引所在的所述索引分区的索引队列位置；监测到数据存入所述文件库时，将该数据存入所述数据队列中，完成后将该数据对应的索引存储到与该数据所属用户相对应的所述索引队列中；监测到读取所述文件库中的数据时，从指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前指针指向的索引所在的所述索引分区的索引队列位置。2.  如权利要求1所述的用于中间件消息的存储与传输方法，其特征在于，还包括：所述索引队列还包括一恢复分区；监测到读取所述文件库中的数据时，从指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递失败时，将该索引存入所述恢复分区中的索引队列；同时，监测到读取所述文件库中的数据时，所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置，并根据该索引队列位置获取下一条恢复索引，通过该恢复索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前恢复指针指向的索引所在的所述恢复分区的索引队列位置。3.  如权利要求2所述的用于中间件消息的存储与传输方法，其特征在于，还包括：通过该恢复索引从所述数据队列中读取对应的数据投递失败时，将该恢复索引放入所述恢复分区中的索引队列的排序执行末端。4.  如权利要求3所述的用于中间件消息的存储与传输方法，其特征在于，还包括：监控所述恢复分区中的索引队列中的至少十个恢复索引从所述数据队列中读取对应的数据进行投递的失败率，若所述失败率超过20%，则延时至少5秒钟执行所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置。5.  如权利要求1至4中任一所述的用于中间件消息的存储与传输方法，其特征在于，所述索引分区中的索引，由文件名和文件组成，文件名为从零开始排序，排序在该文件名之后的文件名为该文件名加上该文件名对应的文件的格式大小的数值；其中，所述索引的大小为最多32个字节组成。6.  一种用于中间件消息的存储与传输系统，应用于文件库中，其特征在于，包括：存储单元、监测单元、写入传输单元和读取传输单元；其中，所述存储单元，用于在所述文件库中创建数据队列、索引队列和指针文件，其中，该索引队列包括对应于不同用户的索引分区；所述数据队列用于顺序存储用户的数据，所述索引分区按照所属用户划分，每个所述索引分区存储该用户在所述数据队列中存储的数据的索引，所述指针文件中的指针指向被读取的数据的索引所在的所述索引分区的索引队列位置；所述监测单元，用于监测到数据存入所述文件库时，指示所述写入传输单元；监测到读取所述文件库中的数据时，指示所述读取传输单元；所述写入传输单元，用于将该数据存入所述存储单元创建的数据队列中， 完成后将该数据对应的索引存储到与该数据所属用户相对应的所述索引队列中；所述读取传输单元，用于从所述存储单元的指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前指针指向的索引所在的所述索引分区的索引队列位置。7.  如权利要求6所述的用于中间件消息的存储与传输系统，其特征在于，所述存储单元，还用于在所述索引队列中创建一恢复分区；所述读取传输单元，还用于从所述存储单元的指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递失败时，将该索引存入所述恢复分区中的索引队列；同时，监测到读取所述文件库中的数据时，所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置，并根据该索引队列位置获取下一条恢复索引，通过该恢复索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前恢复指针指向的索引所在的所述恢复分区的索引队列位置。8.  如权利要求7所述的用于中间件消息的存储与传输系统，其特征在于，所述读取传输单元，还用于通过该恢复索引从所述数据队列中读取对应的数据投递失败时，将该恢复索引放入所述存储单元的恢复分区中的索引队列的排序执行末端。9.  如权利要求8所述的用于中间件消息的存储与传输系统，其特征在于，所述读取传输单元，还用于监控所述恢复分区中的索引队列中的至少十个恢复索引从所述数据队列中读取对应的数据进行投递的失败率，若所述失败率 超过20%，则延时至少5秒钟执行所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置。10.  如权利要求6至9中任一所述的用于中间件消息的存储与传输系统，其特征在于，所述索引分区中的索引，由文件名和文件组成，文件名为从零开始排序，排序在该文件名之后的文件名为该文件名加上该文件名对应的文件的格式大小的数值；其中，所述索引的大小为最多32个字节组成。

说明书用于中间件消息的存储与传输方法及系统
技术领域
本申请涉及网络信息处理领域，具体地说，涉及一种用于中间件消息的存储与传输方法及系统。
背景技术
在互联网络的时代，信息如同大海般没有边际。消息中间件是分布式系统中常用的一种消息通讯的组件，主要用于系统间的解耦，是一种以消息为通讯介质并且帮助转发消息给不同的应用的分布式系统，与邮件系统类似。参与方按角色可以分为发送消息方，消息中间件服务器和订阅消息方。消息中间件所在服务器承担着消息的存储和转发，本发明对应的正是消息存储和消息转发这两块，是消息系统的核心功能，直接影响消息系统的性能和可靠性。
目前，在市面上开源的产品有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，所以影响性能。
针对上述问题，如何提供一种能够解决中间件消息数据的存储与传输性能低的问题，便成为亟待解决的技术问题。
发明内容
有鉴于此，本申请所要解决的技术问题是提供了一种用于中间件消息的存储与传输方法及系统，解决了消息中间件需要快速投递消息，而且还需要处理大量堆积消息的场景。
为了解决上述技术问题，本申请公开了一种用于中间件消息的存储与传输方法，应用于文件库中，其特征在于，包括：
在所述文件库中创建数据队列、索引队列和指针文件，其中，该索引队列包括对应于不同用户的索引分区；所述数据队列用于顺序存储用户的数据，所述索引分区按照所属用户划分，每个所述索引分区存储该用户在所述数据队列中存储的数据的索引，所述指针文件中的指针指向被读取的数据的索引所在的所述索引分区的索引队列位置；
监测到数据存入所述文件库时，将该数据存入所述数据队列中，完成后将该数据对应的索引存储到与该数据所属用户相对应的所述索引队列中；
监测到读取所述文件库中的数据时，从指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递完成，并更新所 述指针文件中当前指针指向的索引所在的所述索引分区的索引队列位置。
优选地，还包括：
所述索引队列还包括一恢复分区；
监测到读取所述文件库中的数据时，从指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递失败时，将该索引存入所述恢复分区中的索引队列；
同时，监测到读取所述文件库中的数据时，所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置，并根据该索引队列位置获取下一条恢复索引，通过该恢复索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前恢复指针指向的索引所在的所述恢复分区的索引队列位置。
优选地，还包括：
通过该恢复索引从所述数据队列中读取对应的数据投递失败时，将该恢复索引放入所述恢复分区中的索引队列的排序执行末端。
优选地，还包括：
监控所述恢复分区中的索引队列中的至少十个恢复索引从所述数据队列中读取对应的数据进行投递的失败率，若所述失败率超过20%，则延时至少5秒钟执行所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置。
优选地，所述索引分区中的索引，由文件名和文件组成，文件名为从零开始排序，排序在该文件名之后的文件名为该文件名加上该文件名对应的文件的格式大小的数值；其中，所述索引的大小为最多32个字节组成。
为了解决上述技术问题，本申请还公开了一种用于中间件消息的存储与传输系统，应用于文件库中，其特征在于，包括：存储单元、监测单元、写入传输单元和读取传输单元；其中，
所述存储单元，用于在所述文件库中创建数据队列、索引队列和指针文件，其中，该索引队列包括对应于不同用户的索引分区；所述数据队列用于 顺序存储用户的数据，所述索引分区按照所属用户划分，每个所述索引分区存储该用户在所述数据队列中存储的数据的索引，所述指针文件中的指针指向被读取的数据的索引所在的所述索引分区的索引队列位置；
所述监测单元，用于监测到数据存入所述文件库时，指示所述写入传输单元；监测到读取所述文件库中的数据时，指示所述读取传输单元；
所述写入传输单元，用于将该数据存入所述存储单元创建的数据队列中，完成后将该数据对应的索引存储到与该数据所属用户相对应的所述索引队列中；
所述读取传输单元，用于从所述存储单元的指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前指针指向的索引所在的所述索引分区的索引队列位置。
优选地，所述存储单元，还用于在所述索引队列中创建一恢复分区；
所述读取传输单元，还用于从所述存储单元的指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递失败时，将该索引存入所述恢复分区中的索引队列；
同时，监测到读取所述文件库中的数据时，所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置，并根据该索引队列位置获取下一条恢复索引，通过该恢复索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前恢复指针指向的索引所在的所述恢复分区的索引队列位置。
优选地，所述读取传输单元，还用于通过该恢复索引从所述数据队列中读取对应的数据投递失败时，将该恢复索引放入所述存储单元的恢复分区中的索引队列的排序执行末端。
优选地，所述读取传输单元，还用于监控所述恢复分区中的索引队列中的至少十个恢复索引从所述数据队列中读取对应的数据进行投递的失败率， 若所述失败率超过20%，则延时至少5秒钟执行所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置。
优选地，其特征在于，所述索引分区中的索引，由文件名和文件组成，文件名为从零开始排序，排序在该文件名之后的文件名为该文件名加上该文件名对应的文件的格式大小的数值；其中，所述索引的大小为最多32个字节组成。
本申请与现有的方案相比，本申请所获得的技术效果：
1）本发明解决了消息中间件需要快速投递消息，而且还能够处理大量堆积消息的场景。
2）本发明还能够实现同步和异步两种模式的数据写入操作，同步模式可以采用group commit的方式等待刷盘之后返回成功，异步模式则无需等待刷盘则直接返回。通过本发明写入数据的性能得到了很大提高，异步模式耗时0.1毫秒，同步模式耗时2毫秒。
3）本发明还能够保证数据处理的完整性，在本发明之前还可以包括：检查临时文件（tempFile）是否存在，如果存在，根据文件刷盘的时间戳（CheckPointFile）检查数据最后一次刷盘的时间戳，然后根据这个时间戳找到数据队列（DataQueue）中某个文件的某个位置，然后从该位置往后遍历数据，每遍历一条数据就把该数据恢复到对应的索引分区（Data queue中的数据有记录索引的信息），直至遍历到（遍历完）数据队列中的最后一个文件。另外在遍历数据队列的过程中每读取一条数据时还需要对该数据进行crc32检验，如果校验失败，则认为该文件后面的所有数据都是脏数据，需要全部删除。在部署时磁盘需要配置raid10策略执行双写，保证数据队列的数据有备份。在文件库（FileStore）的上层还可以实现HA的双写模式，即Master/Slave模式。
4）本发明还能够实现数据异常处理，通过对索引队列（IndexQueue）中创建恢复分区（Recover），当数据处理出现异常，将投递失败的异常数据的索引存入recover分区在进行重新处理，当投递失败率大于20%，则Recover分区的消息会延时投递（默认延时5秒）。
当然，实施本申请的任一产品必不一定需要同时达到以上所述的所有技术效果。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是本申请实施例一所述的用于中间件消息的存储与传输方法流程图；
图2为本申请实施例二所述的用于中间件消息的存储与传输方法流程图；
图3为本申请实施例三所述的用于中间件消息的存储与传输系统结构框图。
具体实施方式
以下将配合图式及实施例来详细说明本申请的实施方式，藉此对本申请如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。
如图1所示，为本申请实施例一所述的用于中间件消息的存储与传输方法，应用于文件库中，该方法包括：
步骤101，在所述文件库中创建数据队列、索引队列和指针文件，其中，该索引队列包括对应于不同用户的索引分区；所述数据队列用于顺序存储用户的数据，所述索引分区按照所属用户划分，每个所述索引分区存储该用户在所述数据队列中存储的数据的索引，所述指针文件中的指针指向被读取的数据的索引所在的所述索引分区的索引队列位置；
步骤102中包括具体如下两步骤：
步骤1021：监测到数据存入所述文件库时，将该数据存入所述数据队列中，完成后将该数据对应的索引存储到与该数据所属用户相对应的所述索引 队列中；
步骤1022：监测到读取所述文件库中的数据时，从指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前指针指向的索引所在的所述索引分区的索引队列位置。
另外，根据上述实施例一所述方法，还包括：
所述索引队列还包括一恢复分区；
所以在步骤102中还可以包括：
监测到读取所述文件库中的数据时，从指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递失败时，将该索引存入所述恢复分区中的索引队列；
同时，监测到读取所述文件库中的数据时，所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置，并根据该索引队列位置获取下一条恢复索引，通过该恢复索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前恢复指针指向的索引所在的所述恢复分区的索引队列位置。
其中，通过该恢复索引从所述数据队列中读取对应的数据投递失败时，将该恢复索引放入所述恢复分区中的索引队列的排序执行末端。
具体地：
监控所述恢复分区中的索引队列中的至少十个恢复索引从所述数据队列中读取对应的数据进行投递的失败率，若所述失败率超过20%，则延时至少5秒钟执行所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置。
上述提到的恢复分区，实际上是对投递失败的数据在进行处理，重新重试，以保证处理数据的完整性。也对失败率达到一定数值如何进行处理进行了设置。
上述实施例一所述的方式，能够通过创建的数据队列将需要投递的数据直接通过传送的方式（transfer to）发送到socket的buffer上，无需经过JVM堆。
而且创建的索引队列为顺序存储，读取也为顺序读取，无需进行特殊排序在进行处理。
同时，本发明实施例一还可以通过临时文件（Temp File，为一个空白文件，无任何内容）的检查其是否存在，即该临时文件在文件库（FileStore）初始化时生成，在程序关闭时删除，该临时文件主要用于校验是否正常关闭。如果文件库（FileStore）初始化时发现有该临时文件则会做清理脏数据的动作，根据数据队列（DataQueue）文件末尾的数据删除掉索引队列（IndexQueue）文件末尾的脏索引。
如图2所示，为本发明实施例二所述用于中间件消息的存储与传输方法，该方法包括：
步骤201，在所述文件库中创建数据队列、索引队列和指针文件，其中，该索引队列包括对应于不同用户的索引分区和一恢复分区；所述数据队列用于顺序存储用户的数据，所述索引分区按照所属用户划分，每个所述索引分区存储该用户在所述数据队列中存储的数据的索引，所述指针文件中的指针指向被读取的数据的索引所在的所述索引分区的索引队列位置；
步骤202中包括具体如下两步骤：
步骤2021：监测到数据存入所述文件库时，将该数据存入所述数据队列中，完成后将该数据对应的索引存储到与该数据所属用户相对应的所述索引队列中；
步骤2022：监测到读取所述文件库中的数据时，从指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前指针指向的索引所在的所述索引分区的索引队列位置。
步骤2023：在步骤2022中：当通过该索引从所述数据队列中读取对应的数据投递失败时，将该索引存入所述恢复分区中的索引队列；同时，监测到读取所述文件库中的数据时，所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置，并根据该索引队列位置获取下一条恢复索引，通过该恢复索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前恢复指针指向的索引所在的所述恢复分区的索引队列位置；通过该恢复索引从所述数据队列中读取对应的数据投递失败时，将该恢复索引放入所述恢复分区中的索引队列的排序执行末端，等待下一次重试。
其中，所述索引分区中的索引，由文件名和文件组成，文件名为从零开始排序，排序在该文件名之后的文件名为该文件名加上该文件名对应的文件的格式大小的数值；其中，所述索引的大小为最多32个字节组成。
其中，每个索引分区的文件命名和数据队列的名称是一模一样的，从零开始，下一个文件的文件名是上一个文件的文件名加上文件的大小，本申请中文件也是以Direct Mapped Buffer（直接映射缓冲区）的方式打开，使用到操作系统的虚拟内存，因此索引的大小是固定的。
具体地，所谓文件名从零开始，是指数据分区的文件或者是索引分区的第一个文件命名是从零开始的，假设每个文件大小为1M，那么第一个文件名为“0000000000000000”，第二个文件名为“0000000001048576”，以此类推，方便根据索引快速定位数据所在的文件。Direct Mapped Buffer是JVM（Java Virtual Machine，Java虚拟机）堆外内存，也就是说使用的内存不是java虚拟机自身的内存，而是操作系统的虚拟内存，操作系统将文件映射到自身内存中的一块，可以对文件像内存一样快速读写操作。本发明中索引大小是指每条索引自身的大小是固定的，数据队列（DataQueue）和索引队列（IndexQueue）中的每个文件大小也是固定的，另外索引是没有排序的，索引是按自然顺序存储的，即顺序写，顺序读，索引存储有对应数据所在的文件和位置信息，这种结构是增对消息中间件量身定做的，和普通的数据存储引擎的索引存在很大的区别的。
具体地：
监控所述恢复分区中的索引队列中的至少十个恢复索引从所述数据队列中读取对应的数据进行投递的失败率，若所述失败率超过20%，则延时至少5秒钟执行所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置。
上述提到的恢复分区，实际上是对投递失败的数据在进行处理，重新重试，以保证处理数据的完整性。也对失败率达到一定数值如何进行处理进行了设置。
上述实施例一所述的方式，能够通过创建的数据队列将需要投递的数据直接通过传送的方式（transfer to）发送到socket的buffer上，无需经过JVM堆。
而且创建的索引队列为顺序存储，读取也为顺序读取，无需进行特殊排序在进行处理。
同时，本发明实施例一还可以通过临时文件（Temp File，为一个空白文件，无任何内容）的检查其是否存在，即该临时文件在文件库（FileStore）初始化时生成，在程序关闭时删除，该临时文件主要用于校验是否正常关闭。如果文件库（FileStore）初始化时发现有该临时文件则会做清理脏数据的动作，根据数据队列（DataQueue）文件末尾的数据删除掉索引队列（IndexQueue）文件末尾的脏索引。
如图3所示，为本发明实施例三所述的一种用于中间件消息的存储与传输系统，应用于文件库中，该系统包括：存储单元301、监测单元302、写入传输单元303和读取传输单元304；其中，
所述存储单元301，分别与所述文件库和所述监测单元302相耦接，用于在所述文件库中创建数据队列、索引队列和指针文件，其中，该索引队列包括对应于不同用户的索引分区；所述数据队列用于顺序存储用户的数据，所述索引分区按照所属用户划分，每个所述索引分区存储该用户在所述数据队列中存储的数据的索引，所述指针文件中的指针指向被读取的数据的索引所在的所述索引分区的索引队列位置；
所述监测单元302，与所述存储单元301相耦接，用于监测到数据存入所述文件库时，指示所述写入传输单元；监测到读取所述文件库中的数据时，指示所述读取传输单元；
所述写入传输单元303，分别与所述存储单元301和所述监测单元302相耦接，用于将该数据存入所述存储单元301创建的数据队列中，完成后将该数据对应的索引存储到与该数据所属用户相对应的所述索引队列中；
所述读取传输单元304，分别与所述存储单元301和所述监测单元302相耦接，用于从所述存储单元301的指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前指针指向的索引所在的所述索引分区的索引队列位置。
上述实施例三的系统中，所述存储单元301，还用于在所述索引队列中创建一恢复分区；
另外，对应的：
所述读取传输单元304，还用于从所述存储单元301的指针文件中获取当前指针指向的索引所在的所述索引分区的索引队列位置，并根据该索引队列位置获取下一条索引，通过该索引从所述数据队列中读取对应的数据投递失败时，将该索引存入所述恢复分区中的索引队列；
同时，监测到读取所述文件库中的数据时，所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置，并根据该索引队列位置获取下一条恢复索引，通过该恢复索引从所述数据队列中读取对应的数据投递完成，并更新所述指针文件中当前恢复指针指向的索引所在的所述恢复分区的索引队列位置。
针对上述内容，需要说明的是：所述读取传输单元304，还用于通过该恢复索引从所述数据队列中读取对应的数据投递失败时，将该恢复索引放入所述存储单元301的恢复分区中的索引队列的排序执行末端。
以及，还用于监控所述恢复分区中的索引队列中的至少十个恢复索引从所述数据队列中读取对应的数据进行投递的失败率，若所述失败率超过20%， 则延时至少5秒钟执行所述恢复分区从所述指针文件中获取当前恢复指针指向的恢复索引所在的所述恢复分区的索引队列位置。
另外，上述实施例三中所述索引分区中的索引，由文件名和文件组成，文件名为从零开始排序，排序在该文件名之后的文件名为该文件名加上该文件名对应的文件的格式大小的数值；其中，所述索引的大小为最多32个字节组成。
由于方法部分已经对本申请实施例进行了详细描述，这里对实施例中涉及的系统与方法对应部分的展开描述省略，不再赘述。对于系统中具体内容的描述可参考方法实施例的内容，这里不再具体限定。
本申请与现有的方案相比，本申请所获得的技术效果：
1）本发明解决了消息中间件需要快速投递消息，而且还能够处理大量堆积消息的场景。
2）本发明还能够实现同步和异步两种模式的数据写入操作，同步模式可以采用group commit的方式等待刷盘之后返回成功，异步模式则无需等待刷盘则直接返回。通过本发明写入数据的性能得到了很大提高，异步模式耗时0.1毫秒，同步模式耗时2毫秒。
3）本发明还能够保证数据处理的完整性，在本发明之前还可以包括：检查临时文件（tempFile）是否存在，如果存在，根据文件刷盘的时间戳（CheckPointFile）检查数据最后一次刷盘的时间戳，然后根据这个时间戳找到数据队列（DataQueue）中某个文件的某个位置，然后从该位置往后遍历数据，每遍历一条数据就把该数据恢复到对应的索引分区（Data queue中的数据有记录索引的信息），直至遍历到（遍历完）数据队列中的最后一个文件。另外在遍历数据队列的过程中每读取一条数据时还需要对该数据进行crc32检验，如果校验失败，则认为该文件后面的所有数据都是脏数据，需要全部删除。在部署时磁盘需要配置raid10策略执行双写，保证数据队列的数据有备份。在文件库（FileStore）的上层还可以实现HA的双写模式，即Master/Slave模式。
需要说明的是：目前主备HA的双写模式的数据同步方案采用了类似Oracle的数据同步方案，即系统在正常情况下都是以同步的方式同步到备机， 当备机或者网络发生异常时自动转化为异步的方式同步到备机，当同步的进度赶上当前主机的速度之后自动再切换为同步复制数据。
4）本发明还能够实现数据异常处理，通过对索引队列（IndexQueue）中创建恢复分区（Recover），当数据处理出现异常，将投递失败的异常数据的索引存入recover分区在进行重新处理，当投递失败率大于20%，则Recover分区的消息会延时投递（默认延时5秒）。
本领域内的技术人员应明白，本申请的实施例可提供为方法、装置、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。
上述说明示出并描述了本申请的若干优选实施例，但如前所述，应当理解本申请并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本申请的精神和范围，则都应在本申请所附权利要求的保护范围内。