中读取对应的数据投递失败时，将该恢复索引放入所述恢复分区中的索引队列的排序执行末端，等待下一次重试。
[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]需要说明的是