CN117667447A - 一种多日志高并发消息队列处理方法及系统 - Google Patents

Abstract

本发明公开了一种多日志高并发消息队列处理方法及系统，属于计算机存储技术领域，采用多个消息日志存储消息，每个消息日志存在唯一写锁，每个消息写工作线程向某个消息日志提交消息前需要获取对应消息日志的写锁，为多个消息写工作线程提供了细粒度的写锁，降低了消息写工作线程之间的锁资源竞争，提高了消息写请求提交速度，提高了高速固态盘写带宽的利用率。除此之外，本发明还根据消息的主题属性将消息分配到不同的消息日志，实现了负载均衡；将写过程拆分为提交和刷盘两个阶段，并在刷盘阶段对短消息导致的小写请求进行聚合，提高了消息刷盘效率；控制异步发送模式的生产者客户端消息发送速率，避免了高并发场景下的系统过载问题。

Description

一种多日志高并发消息队列处理方法及系统

技术领域

本发明属于计算机存储技术领域，更具体地，涉及一种多日志高并发消息队列处理方法及系统。

背景技术

分布式消息队列(Distributed Message Queue，简称消息队列)也称为消息中间件(Messaging-Oriented Middleware，MOM)，是一种面向分布式系统的高并发异步消息传递模型，用于在不同的应用程序之间进行异步通信。它为用户和上层应用提供一组特定接口来存取消息，并把消息数据存储到一个或多个节点中，保证其可靠性和可扩展性。消息生产者可以向消息队列中发送消息，而消费者则可以从消息队列中获取消息并进行处理。这种通信方式与生产者和消费之间直接的点对点通信相比，具有更好的可伸缩性和容错性，因为消息处理的过程可以被分布到多个节点中。此外，在大规模的应用程序中，使用消息队列还可以实现应用解耦和系统水平扩展等功能。

传统分布式文件系统、云存储系统或键值存储系统等无法满足大规模流式数据的处理需求。电商企业因此采用了消息队列作为缓存，提供稳定的订单处理、实时搜索、数据分析、推荐等服务。Google、Alibaba、Amazon、Facebook和Microsoft等云服务提供商均提供了各自的消息队列产品，为订单处理、证券交易、实时数据分析、数据迁移等场景提供了高效稳定的消息存储和转发服务。

作为微服务架构和分布式应用不可或缺的基础设施，消息队列在电商交易系统、流式数据处理、日志收集、分布式缓存领域广泛应用。在复杂系统中，不同组件之间通过发送、接收消息进行通信，消息队列在其中起到缓冲和解耦合的作用，提高了系统开发效率和稳定性。此外，消息队列还可以实现分布式系统中的异步通信、海量日志数据同步、分布式事务等功能，实现高性能、高可用、可伸缩和最终一致性架构。

按照消息传输模式，消息队列分为点对点通信模式和发布-订阅模式。在发布-订阅模式下，消息从生产者传递到任意数量的消费者。消息被传递到特定主题，然后传递给所有订阅了该主题的消费者。其中，主题是指一种特定的消息类型或者说业务类型。每个主题可以包含多个逻辑队列，每个逻辑队列下有多条消息，而每个逻辑队列仅能被一个消费者组内的消费者进行消费。其中，消费者组指具有相同业务逻辑的消费者，具有相同业务逻辑的生产者则被称为生产者组。生产者组将消息发布到特定的主题中，订阅者通过订阅该主题来接收对应的消息。主题模型实现了不同业务之间的区分和隔离，使得系统具有更好的可维护性和可扩展性。

在发布-订阅模式下，消息消费者会向消息处理节点订阅特定主题，消息消费者通常有被动通知(Push)和主动拉取(Pull)两种消息获取方式。在被动通知模式下，如果某一主题下有新消息到达，消息处理节点会将消息主动推送到消息消费者，此时消息消费的延迟更低但在多消费者情况下，消息处理节点的负担也随之增加。在主动拉取模式下，消息消费者会定期从消息处理节点拉取特定主题的消息，更适合需要高吞吐率的场景，同时允许消费者控制消息消息发送速率。

对主流消息队列如RocketMQ的消息写过程进行写请求处理步骤分解分析后发现，由于消息写过程中存在一定的数据处理逻辑，单一消息写工作线程IO请求提交速度有限，所以需要使用多个消息写工作线程提高请求处理速度。然而，RocketMQ以仅追加的方式将消息写入全局唯一日志，在消息写过程中多个消息写工作线程会竞争同一日志文件写锁，锁资源竞争开销限制了写吞吐率，对高速固态盘写带宽的利用率较低。

发明内容

针对现有技术的以上缺陷或改进需求，本发明提供了一种多日志高并发消息队列处理方法及系统，用以解决现有技术所存在的对高速固态盘写带宽的利用率较低的技术问题。

为了实现上述目的，第一方面，本发明提供了一种多日志高并发消息队列处理方法，包括：

当生产者客户端发送的写请求到达消息处理节点后，由请求分发线程将请求分发至写请求处理线程池，并将写请求添加至消息写请求队列中；

由写请求处理线程池中的多个消息写工作线程并行的从消息写请求队列中获取对应的写请求，并将对应的写请求分配到多日志存储结构中的对应消息日志中，然后获取对应消息日志写锁并写入消息；

其中，多日志存储结构包括：多个消息日志；每个消息日志存在唯一写锁，且均包括：多个固定大小的消息日志文件，消息日志文件中存储有消息项，每个消息项中记录有消息体和消息元数据。

进一步优选地，消息写工作线程基于写请求中消息的主题将写请求分配到多日志存储结构中的对应消息日志中：将同一主题下的消息分配到相同的消息日志中。

进一步优选地，消息写工作线程根据写请求中消息的主题计算哈希值，并对消息日志数量取模，得到消息日志编号后，将写请求分配到该编号下的消息日志中。

进一步优选地，写入消息的方法，包括：

将消息的写入过程拆分为提交阶段和刷盘阶段；

在提交阶段执行消息提交操作：由消息写工作线程将消息写入消息日志的内存映射缓冲区；

在刷盘阶段执行刷盘动作，由刷盘线程将内存映射缓冲区内的消息数据持久化到硬盘；

其中，写入消息的模式包括：同步写模式和异步写模式；

在同步写模式下，为每个消息日志设置单独的刷盘线程；消息写工作线程完成其消息提交操作后，将刷盘请求加入刷盘请求队列，并唤醒对应的刷盘线程后等待；待对应的刷盘线程完成刷盘动作后，向生产者客户端返回写请求处理结果应答；

在异步写模式下，消息写工作线程完成其消息提交操作后即可向生产者客户端返回写请求处理结果应答。

进一步优选地，在同步写模式下，若内存映射缓冲区中需要刷盘的脏数据总长度小于预设长度，则由消息刷盘线程将刷盘动作推迟预设时间，若在预设时间段内有预设数量的刷盘请求到达，或新到的刷盘请求使脏数据总长度大于预设长度，则立即执行刷盘动作；否则，在预设时间结束后立即执行刷盘动作。

进一步优选地，在消息处理节点侧，在写请求到达时，由请求分发线程根据写请求中的消息长度计算写请求的消息负载因子，判断消息负载因子与当前消息写请求队列的写负载强度之和是否大于最大写负载强度，若是，则丢弃写请求，并向生产者客户端发送消息处理节点过载应答；否则，将写请求添加至消息写请求队列中；其中，当前消息写请求队列的写负载强度为当前消息写请求队列中所有写请求的消息负载因子之和；

与此同时，当异步发送模式下的生产者客户端在收到消息处理节点过载应答后，降低自身消息发送速率。

进一步优选地，异步发送模式下的生产者客户端在发送写请求之前，根据写请求中的消息长度计算消息负载因子，判断消息负载因子与当前已发送消息的写负载强度之和是否达到当前消息负载强度阈值，若是，则停止发送消息，直至消息负载因子与当前已发送消息的写负载强度之和小于当前消息负载强度阈值后，再发送写请求；否则，发送写请求；

其中，当前已发送消息的写负载强度为当前已发送消息的消息负载因子之和；

当异步发送模式下的生产者客户端在收到消息处理节点过载应答后，降低当前消息负载强度阈值；

当异步发送模式下的生产者客户端连续收到预设数量的消息写请求成功应答后，提高消息负载强度阈值。

进一步优选地，上述多日志存储结构使用主题-队列模型管理消息逻辑布局；每个主题下有多个逻辑队列，每个消息对应唯一的(主题，逻辑队列编号，逻辑队列偏移)三元组；

上述多日志存储结构还包括：消费队列文件和直接索引文件，用于存储消息索引数据；

消费队列文件按照消息在逻辑队列中的顺序存储消息消费索引项，消费索引项用于存储消息在逻辑队列中的位置；

直接索引文件用于记录一段时间内写入消息日志的消息的直接索引项的哈希表；哈希表的键为消息的主题键哈希值，值为消息的直接索引项，包括：消息在消息日志中的物理偏移、相对时间戳和后续索引序号；

消息日志文件名代表本文件第一个字节在整个消息日志中的物理偏移；消费队列文件名代表本文件第一条消息在逻辑队列中的序号；直接索引文件名代表本文件的创建时间戳。

进一步优选地，上述多日志高并发消息队列处理方法，还包括：

在消息处理节点启动过程中创建异常退出文件，并使用检查点文件定期持久化消费队列、直接索引以及消息日志的最后刷盘时间；

正常退出时，将所有消息刷盘，并完成消费队列和索引文件的持久化，最后删除异常退出文件；

在消息处理节点启动过程中，检查是否还存在异常退出文件，若存在，则判定上次程序退出异常，执行如下崩溃恢复操作：

对于每一个消息日志，获取该消息日志的直接索引刷盘时间戳、消费队列刷盘时间戳和消息日志刷盘时间戳，并记上述三个时间戳中的最小值为t，对该消息日志的消息日志文件按照文件名升序排序，得到消息日志文件列表，从消息日志文件列表最后一个消息日志文件开始反向遍历；

遍历过程中，对于每一个消息日志文件，读取消息日志文件中第一条消息，对比该消息的消息存储时间T与t的大小，若T小于t，则获取t时刻最后一条刷盘消息所在的消息日志文件F；否则，继续遍历下一个消息日志文件；

其中，在获取到消息日志文件F后，改变消息日志文件的遍历方向，从消息日志文件F开始依次尝试读取消息，并为每一条有效消息在消费队列文件和直接索引文件中构建索引，直至读取到一条无效消息，或读完后续所有消息日志文件，则完成该消息日志的崩溃恢复操作。

进一步优选地，上述多日志高并发消息队列处理方法，还包括：

当生产者客户端发送的读请求到达消息处理节点后，由请求分发线程将请求分发至读请求处理线程池，并将读请求添加至消息读请求队列中；

采用消息读请求工作线程从消息读请求队列中取出消息读请求，根据读请求中消息的主题，从对应的消费队列文件或者直接索引文件查找消息在消息日志中的位置，读取消息并返回给生产者客户端。

进一步优选地，上述多日志高并发消息队列处理方法，还包括：

采用消息备份线程处理消息备份请求队列中的消息备份请求：定期执行消息备份操作，将本机消息日志发送到备份服务器中；在消息备份请求队列中存在消息备份请求时，执行备份动作。

进一步优选地，上述多日志高并发消息队列处理方法，还包括：

采用元数据写线程在后台定期检查消息日志写入进度，当发现消息日志中存在新写入的消息时，从消息日志中读取消息并将消息信息写入消费队列文件和直接索引文件中。

第二方面，本发明提供了一种多日志高并发消息队列处理系统，包括：存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时执行本发明第一方面所提供的多日志高并发消息队列处理方法。

第三方面，本发明还提供了一种计算机可读存储介质，所述计算机可读存储介质包括存储的计算机程序，其中，在所述计算机程序被处理器运行时控制所述存储介质所在设备执行本发明第一方面所提供的多日志高并发消息队列处理方法。

总体而言，通过本发明所构思的以上技术方案，能够取得以下有益效果：

1、本发明提供了一种多日志高并发消息队列处理方法，采用多日志存储结构存储消息，多日志存储结构包括多个消息日志，每个消息日志存在唯一写锁，每个消息写工作线程向某个消息日志提交消息前需要获取对应消息日志的写锁，通过多日志结构为多个消息写工作线程提供了细粒度的写锁，降低了消息写工作线程之间的锁资源竞争，提高了消息写请求提交速度，可以更充分地利用高速固态盘的写带宽，提高了高速固态盘写带宽的利用率。

2、进一步地，本发明所提供的多日志高并发消息队列处理方法，考虑到多日志存储结构包括多个消息日志，需要将生产者发送的消息分配到不同的消息日志，从而将消息均匀地写到多个消息日志，而消费者客户端一般会持续消费某个主题下的消息，因此，本发明将同一主题下的消息分配到相同的消息日志中，从而提高了数据的局部性，进而提高了消息读速度。

3、进一步地，本发明所提供的多日志高并发消息队列处理方法，使用日志独立的二阶段写机制，将消息写过程拆分为提交和刷盘两阶段；在提交阶段，将消息写入内存映射缓冲区，由消息写工作线程负责；在刷盘阶段，将内存映射缓冲区的数据写入硬盘，由刷盘线程负责；不同阶段使用独立线程处理，从而使消息写入过程流水化，提高了消息的写入效率。

4、进一步地，本发明所提供的多日志高并发消息队列处理方法，在同步写模式下，将同一消息日志中的多个短消息聚合刷盘，从而减少小写请求数量，提高同步写模式下的短消息写入速度。

5、进一步地，本发明所提供的多日志高并发消息队列处理方法，根据消息处理节点当前写负载强度对写请求处理结果进行预测，当写负载强度过高时丢弃写请求并向生产者客户端发送过载信号。在生产者客户端，根据历史写请求处理结果控制自身消息发送速率，避免所有生产者的总消息发送速率超过消息处理节点处理能力；通过上述方法来控制生产者总消息发送速率，避免了生产者客户端异步发送消息场景下所存在的系统过载问题，提高了重负载场景下的写性能。

6、进一步地，本发明所提供的多日志高并发消息队列处理方法，在消息处理节点启动过程中，检查是否还存在异常退出文件，若存在，则判定上次程序退出异常，执行如下崩溃恢复操作，以避免断电等系统故障所导致的一致性错误。

附图说明

图1为本发明实施例提供的一种多日志存储结构示意图；

图2为本发明实施例提供的按照主题-队列模型对消息进行归类的方法的示意图；

图3为本发明实施例提供的同步写模式下日志独立的多线程二阶段写策略示意图；

图4为本发明实施例提供的日志独立的多线程二阶段写策略实现方案示意图；

图5为本发明实施例提供的阐述崩溃恢复过程示意图；

图6为本发明实施例提供的多日志高并发消息队列处理机制的示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

第一方面，本发明提供了一种多日志高并发消息队列处理方法，包括：

当生产者客户端发送的写请求到达消息处理节点后，由请求分发线程将请求分发至写请求处理线程池，并将写请求添加至消息写请求队列中；

由写请求处理线程池中的多个消息写工作线程并行的从消息写请求队列中获取对应的写请求，并将对应的写请求分配到多日志存储结构中的对应消息日志中，然后获取对应消息日志写锁并写入消息；

其中，多日志存储结构包括：多个消息日志；每个消息日志存在唯一写锁，且均包括：多个固定大小的消息日志文件，消息日志文件中存储有消息项，每个消息项中记录有消息体和消息元数据。具体地，如图1所示，假设存在两个消息日志，每个消息日志根据总大小由一个或多个大小相同的消息日志文件组成，每个文件默认大小为1GB，当一个消息日志文件写满后创建一个新的消息日志文件。每个消息存储单元记录了消息存储单元大小、魔数、消息体CRC、主题、逻辑队列编号等元数据，以及消息体。每个消息记录是自描述的，包含了消息的所有信息。消息日志文件文件名为本文件中第一个字节在消息日志中的物理偏移，在根据消息偏移查找消息时可以快速定位到消息所在的消息日志文件。需要说明的是，为保证日志写一致性，每个消息日志存在唯一写锁，每个消息写工作线程向某个消息日志提交消息前需要获取对应消息日志的写锁。消息写请求处理线程池中存在多个消息写工作线程，多日志结构提供了细粒度的日志写锁，降低了消息写工作线程之间的锁资源竞争。

消息写工作线程根据消息到达时间等信息为消息生成消息编号、到达时间等属性，与消息体一起组成消息内容，然后以仅追加的方式将消息写入对应的消息日志。消息日志中存在不同主题的消息，其顺序只与消息被消息写工作线程写入消息日志中的时间先后有关。

在一种可选实施方式下，使用发布-订阅消息传输模式。通信双方约定特定主题，生产者客户端向特定主题中发送消息，消费者客户端从特定主题消费消息，从而实现指定生产者消费者之间的消息通信。生产者客户端和消费者客户端可以以组为单位划分，同一组下的生产者和消费者具有相同的主题订阅关系。如图2所示，上述多日志存储结构使用主题-队列模型管理消息逻辑布局；每个主题下有多个逻辑队列，每个消息对应唯一的(主题，逻辑队列编号，逻辑队列偏移)三元组。消息写入消息日志后，后台线程将消息索引项索引异步写入消费队列。

上述多日志存储结构还包括：消费队列文件和直接索引文件，用于存储消息索引数据；

消费队列文件按照消息在逻辑队列中的顺序存储消息消费索引项，消费索引项用于存储消息在逻辑队列中的位置，具体包含物理偏移字段、消息长度字段、标签哈希值字段。其中，物理偏移字段用来记录消息在消息日志中的物理偏移；消息长度字段用来记录消息在消息日志中的存储长度；标签哈希值字段用来记录用户自定义的消息标签的哈希值，凭借标签哈希值可以在读取消息的过程中对消息进行过滤。如果消费者客户端需要从某个逻辑队列中读取消息，则根据(主题、逻辑队列编号)二元组查询对应的消费队列文件，根据其中的消费索引项从消息日志中读取消息。消费队列可以加速根据主题查找消息的过程，订阅一个主题后，根据相应的消费队列就可以快速查找主题下的消息。

直接索引文件用于记录一段时间内写入消息日志的消息的直接索引项的哈希表；哈希表的键为消息的主题键哈希值，值为消息的直接索引项，包括：消息在消息日志中的物理偏移、相对时间戳和后续索引序号；使用拉链法解决哈希冲突。其中，主题键哈希值指根据消息的主题和键得到的哈希值。

每个直接索引文件由首部、哈希槽表格区、直接索引链表区构成。直接索引文件首部记录了当前直接索引文件中消息的最早存储时间、最晚存储时间、最大物理偏移、最小物理偏移、哈希槽数量、已使用直接索引槽数量。哈希槽表格区拥有多个哈希槽，每个哈希槽记录了直接索引项在直接索引链表区的序号。对于某一条消息，消息的主题键哈希值与哈希槽数量取模即得到其在哈希槽表格中的序号。直接索引链表区拥有多个直接索引项，新插入的消息直接索引项顺序写入直接索引链表区第一个空闲位置，并插入位置序号写入消息对应的哈希槽。直接索引项中记录了消息的主题键哈希值、在消息日志中的物理偏移、相对时间戳、后续索引序号(哈希链表中下个节点的直接索引序号)。

消息日志文件名代表本文件第一个字节在整个消息日志中的物理偏移；消费队列文件名代表本文件第一条消息在逻辑队列中的序号；直接索引文件名代表本文件的创建时间戳。

本发明支持普通消息和顺序消息，主题创建时默认生成多个主题下属的逻辑队列。对于普通消息，生产者客户端发送的消息随机写入主题下的一个逻辑队列。对于顺序消息，生产者客户端发送时需要指定逻辑队列编号并顺序向消息处理节点发送消息，消费者客户端可以通过指定逻辑队列编号的方式从特定逻辑队列中顺序消费消息，进而按照与生产者发送顺序相同的顺序读取消息。

在一种可选实施方式下，考虑到本发明所采用的多日志存储结构包括多个消息日志，需要将生产者发送的消息分配到不同的消息日志，从而将消息均匀地写到多个消息日志。由于消费者客户端一般会持续消费某个主题下的消息，因此应该将某个主题下的消息写入相同编号的消息日志，使同主题消息尽量存储在相同消息日志文件中，提高数据局部性，进而提高消息读速度。基于此提出了一种基于主题模型的消息日志负载均衡算法，具体为：消息写工作线程基于写请求中消息的主题将写请求分配到多日志存储结构中的对应消息日志中：将同一主题下的消息分配到相同的消息日志中。具体地，消息写工作线程根据写请求中消息的主题计算哈希值，并对消息日志数量取模，得到消息日志编号后，将写请求分配到该编号下的消息日志中。

优选地，在一种可选实施方式下，采用内存映射的IO方式操作消息日志，使用内存映射技术，得到消息日志的内存映射缓冲区，消息写工作线程先将消息写入内存映射缓冲区。相比与传统的IO方式，使用内存映射的方式操作消息日志，减少了用户缓冲区和内核缓冲区之间的数据拷贝次数。其次，在不触发Page Fault的情况下，基于内存映射的IO方式可以直接在用户态将数据写内核缓冲区，减少了进程上下文切换开销。

优选地，在一种可选实施方式下，为提高消息写入效率，使用日志独立的二阶段写机制。具体来说，将消息写过程拆分为提交和刷盘两阶段：在提交阶段，将消息写入内存映射缓冲区，由消息写工作线程负责；在刷盘阶段，将内存映射缓冲区的数据写入硬盘，由刷盘线程负责，从而使消息写入过程流水化，提高写入效率。其次，在同步写模式下，将同一消息日志中的多个短消息聚合刷盘，从而减少小写请求数量，提高同步写模式下的短消息写入速度。下面详细介绍上述机制：

写入消息的方法，包括：

将消息的写入过程拆分为提交阶段和刷盘阶段；

在提交阶段执行消息提交操作：由消息写工作线程将消息写入消息日志的内存映射缓冲区；

在刷盘阶段执行刷盘动作，由刷盘线程将内存映射缓冲区内的消息数据持久化到硬盘；

其中，写入消息的模式包括：同步写模式和异步写模式；

在同步写模式下，为每个消息日志设置单独的刷盘线程；消息写工作线程完成其消息提交操作后，将刷盘请求加入刷盘请求队列，并唤醒对应的刷盘线程后等待；待对应的刷盘线程完成刷盘动作后，向生产者客户端返回写请求处理结果应答；

在异步写模式下，消息写工作线程完成其消息提交操作后即可向生产者客户端返回写请求处理结果应答。

具体地，如图3所示为同步写模式下日志独立的多线程二阶段写策略示意图，假设存在2个消息写工作线程：消息写工作线程1、消息写工作线程2；存在2个消息日志：消息日志0、消息日志1。消息1、消息2到达后，消息写工作线程1、消息写工作线程2可以并行处理写请求，解析并处理消息内容，生成校验码、消息编号等。然后，消息写工作线程1、消息写工作线程2根据消息主题，选择应写入的消息日志，假设消息1应写入消息日志0、消息2应写入消息日志1，则消息写工作线程1获取消息日志0的写锁，进入消息提交阶段，将消息写消息日志0的内存映射缓冲区，消息写工作线程2获取消息日志1的写锁，进入消息提交阶段，将消息写消息日志1的内存映射缓冲区。此时，消息写工作线程1、消息写工作线程2之间无资源竞争，消息1、消息2可以并行写消息日志0、消息日志1。最后，消息写工作线程1、消息写工作线程2分别唤醒并等待消息日志0、消息日志1的刷盘线程。

如图4所示为日志独立的多线程二阶段写策略实现方案，本发明使用无锁队列对刷盘请求进行缓存，从而实现日志独立的多线程二阶段写策略。与RocketMQ使用的双缓冲队列相比，无需在消息写线程唤醒刷盘线程时对读写队列加锁，降低了锁资源开销。在同步写模式下消息写工作线程首先处理消息，生成消息CRC校验码、消息属性等字段。然后，将消息写入内存映射缓冲区，并将刷盘请求加入刷盘请求队列。最后，尝试唤醒消息日志刷盘线程。当消息日志刷盘线程被唤醒后，执行消息刷盘算法处理刷盘请求。最后，向生产者客户端返回写请求处理结果应答。每个消息日志拥有独立的内存映射缓冲区、刷盘请求队列、消息日志刷盘线程。

在一种可选实施方式下，在同步写模式下，若内存映射缓冲区中需要刷盘的脏数据总长度小于预设长度(如4KB)，则由消息刷盘线程将刷盘动作推迟预设时间(如10ms)，若在预设时间段(如20ms)内有预设数量(如16条)的刷盘请求到达，或新到的刷盘请求使脏数据总长度大于预设长度，则立即执行刷盘动作；否则，在预设时间结束后立即执行刷盘动作。本实施方式中，消息刷盘线程发现脏数据总长度小于预设长度时，会推迟刷盘操作一段时间，等待更多脏数据写入后刷盘，从而聚合小消息刷盘请求，缓解小写请求过多导致的NVMe固态盘垃圾回收与写放大问题。为避免刷盘时间推迟导致的低负载下写请求处理时间过长，设置最大聚合消息条数为K(默认配置下K＝4)。聚合消息条数达到K后立即刷盘。同时，设置最大延迟时间片T，时间片T耗尽后，如果仍未曾执行刷盘操作，即使没有新的刷盘请求到达也会执行一次刷盘操作。

在一种可选实施方式下，考虑到RocketMQ在生产者异步发送消息场景下存在系统过载问题，且其原因在于，异步发送模式的生产者会持续向消息处理节点发送写请求，随着生产者数量的增加，会向消息处理节点发送海量的写请求，进而造成消息处理节点过载，因此，本发明进一步提出了请求流量控制策略来控制生产者总消息发送速率，即生产者客户端在异步发送模式下，根据消息负载因子、当前写负载强度之和、当前写负载强度阈值，对自身消息发送速率进行控制，并根据写请求处理结果应答对当前写负载强度阈值进行调整；在消息处理节点中，使用消息写请求队列缓冲写请求，根据当前写负载强度和消息负载因子之和对写请求处理结果进行预测，在当前写负载强度和消息负载因子达到最大写负载强度时，直接丢弃写请求并向生产者客户端发送过载信号。具体操作如下：

在消息处理节点侧，在写请求到达时，由请求分发线程根据写请求中的消息长度计算写请求的消息负载因子，判断消息负载因子与当前消息写请求队列的写负载强度之和是否大于最大写负载强度，若是，则丢弃写请求，并向生产者客户端发送消息处理节点过载应答；否则，将写请求添加至消息写请求队列中；其中，当前消息写请求队列的写负载强度为当前消息写请求队列中所有写请求的消息负载因子之和；消息负载因子的计算公式为：Size_i为第i条写请求中的消息字节为单位的长度；

与此同时，当异步发送模式下的生产者客户端在收到消息处理节点过载应答后，降低自身消息发送速率。

具体地，异步发送模式下的生产者客户端在发送写请求之前，根据写请求中的消息长度计算消息负载因子，判断消息负载因子与当前已发送消息的写负载强度之和是否达到当前消息负载强度阈值，若是，则停止发送消息，直至消息负载因子与当前已发送消息的写负载强度之和小于当前消息负载强度阈值后，再发送写请求；否则，发送写请求；

其中，当前已发送消息的写负载强度为当前已发送消息的消息负载因子之和；

当异步发送模式下的生产者客户端在收到消息处理节点过载应答后，降低当前消息负载强度阈值；

当异步发送模式下的生产者客户端连续收到预设数量(如32条)的消息写请求成功应答后，提高消息负载强度阈值。

具体来说，消息处理节点收到生产者客户端发出的写请求后，根据请求中的消息长度计算消息负载因子，如果消息负载因子与当前写负载强度之和大于消息处理节点最大写负载强度，则预测此写请求将会超时，直接丢弃写请求，然后向生产者客户端发送消息处理节点过载应答；否则，将消息负载因子与当前写负载强度之和作为新的当前写负载强度，再将写请求加入消息写请求队列，消息写工作线程会从消息写请求队列中取出写请求并处理，在处理结束后将当前写负载强度减去消息负载因子。采用请求流量控制策略后，异步发送模式的生产者在收到过载应答或消息写请求处理失败应答后会降低自身消息发送速率，进而降低所有生产者客户端的总消息发送速率，减少消息处理节点负载强度。

在一种可选实施方式下，为了避免断电等系统故障导致的一致性错误，实现了崩溃恢复机制。具体地，上述多日志高并发消息队列处理方法，还包括：

在消息处理节点启动过程中创建异常退出文件，并使用检查点文件定期持久化消费队列、直接索引以及消息日志的最后刷盘时间；

正常退出时，将所有消息刷盘，并完成消费队列和索引文件的持久化，最后删除异常退出文件；

在消息处理节点启动过程中，检查是否还存在异常退出文件，若存在，则判定上次程序退出异常，执行如下崩溃恢复操作：

对于每一个消息日志，获取该消息日志的直接索引刷盘时间戳、消费队列刷盘时间戳和消息日志刷盘时间戳，并记上述三个时间戳中的最小值为t，对该消息日志的消息日志文件按照文件名升序排序，得到消息日志文件列表，从消息日志文件列表最后一个消息日志文件开始反向遍历(从后往前遍历)；

遍历过程中，对于每一个消息日志文件，读取消息日志文件中第一条消息，对比该消息的消息存储时间T与t的大小，若T小于t，则获取t时刻最后一条刷盘消息所在的消息日志文件F；否则，继续遍历下一个消息日志文件；

其中，在获取到消息日志文件F后，改变消息日志文件的遍历方向(变成从前往后)，从消息日志文件F开始依次尝试读取消息，并为每一条有效消息在消费队列文件和直接索引文件中构建索引，直至读取到一条无效消息，或读完后续所有消息日志文件，则完成该消息日志的崩溃恢复操作。

具体地，如图5所示，以消息日志0为例，阐述崩溃恢复过程：假设检查点文件中记录的直接索引刷盘时间点、消费队列刷盘时间点、消息日志0刷盘时间点分别为t1、t2、t3，存在t1<t2<t3。记最后有效刷盘时间t＝min(t1,t2,t3)＝t1，消息日志0存在两个消息日志文件，第一个消息日志文件存储的第一条消息为消息1，最后一条消息为消息2，第二个日志文件存储的第一条消息为消息3。消息日志文件名代表消息日志中第一条消息的物理偏移，据此，从小到大对消息日志0的所有消息日志文件排序，得到消息日志0的消息日志文件列表。从消息日志文件列表最后一个消息日志文件开始遍历。遍历过程中，对于每一个消息日志文件，读取文件中第一条消息，将消息存储时间T与t对比，如果T小于t，则得到t时刻最后一条刷盘消息所在的消息日志文件F；否则，继续遍历下一个文件。查找到文件F后，改变消息日志文件遍历方向，从文件F开始依次尝试读取消息，根据消息魔数以及校验码判断消息是否有效，为每一条有效消息在消费队列和直接索引中构建索引，直至读取到一条无效消息，或读完后续所有消息日志文件，完成消息日志0的崩溃恢复过程。对每个消息日志，重复执行上述流程。

由于本发明不保证消息日志、消费队列或者直接索引中同一消息不重复出现，需要消费者实现消息消费的幂等性。

在一种可选实施方式下，上述多日志高并发消息队列处理方法，还包括：

当生产者客户端发送的读请求到达消息处理节点后，由请求分发线程将请求分发至读请求处理线程池，并将读请求添加至消息读请求队列中；

采用消息读请求工作线程从消息读请求队列中取出消息读请求，根据读请求中消息的主题、队列或消息编号等属性，从对应的消费队列文件或者直接索引文件查找消息在消息日志中的位置，读取消息并返回给生产者客户端。

例如，消费队列按照队列中消息的逻辑顺序存储消费索引项，消费索引项存储了消息在消息日志中的物理偏移，消息长度和标签哈希值。以消费者客户端从主题A的逻辑队列0消费消息为例阐述消费过程：假设根据主题A对应的消息日志为消息日志0，则先读取主题A-逻辑队列0对应的消费队列文件，然后解析消费队列中的消费索引项得到消息在消息日志中的偏移和大小，最后依次读取，并根据消费者定义的消息过滤字段和消息标签的对比结果，对消息进行过滤后发送给消费者。

在一种可选实施方式下，当设置有消息最小副本数量时，上述多日志高并发消息队列处理方法，还包括：采用消息备份线程处理消息备份请求队列中的消息备份请求：定期执行消息备份操作，将本机消息日志发送到备份服务器中；在消息备份请求队列中存在消息备份请求时，执行备份动作。

在一种可选实施方式下，上述多日志高并发消息队列处理方法，还包括：采用元数据写线程在后台定期检查消息日志写入进度，当发现消息日志中存在新写入的消息时，从消息日志中读取消息并将消息信息写入消费队列文件和直接索引文件中。

为了进一步说明本发明所提供的多日志高并发消息队列处理方法，下面结合一具体实施例进行详述：

如图6所示为实现本发明所提供的多日志高并发消息队列处理机制的示意图，将基于多日志高并发消息队列处理机制的系统记为PDMMQ系统。PDMMQ系统包括：名服务器、消息处理节点、生产者客户端和消费者客户端。生产者客户端发送的请求到达消息处理节点后，由请求分发线程分发给对应的请求处理线程池。对于生产者生产者发送的写请求，请求分发线程首先根据消息长度计算消息负载因子，如果与当前写负载强度之和大于最大写负载强度，则预测消息写失败，向生产者客户端返回写失败应答，生产者生产者收到写失败应答后，会降低自身消息发送速率；否则，将写请求添加到消息写请求队列。消息写工作线程从消息写请求队列中获取写请求，使用基于主题模型的消息日志负载均衡算法将写请求分配到某一消息日志，然后获取消息日志写锁并写入消息。

为了减少内存拷贝次数，采用内存映射机制实现消息日志的写操作。同步写模式下，消息写内存映射缓冲区后，消息写工作线程还会向此日志的刷盘请求队列提交刷盘请求，并唤醒刷盘线程执行刷盘操作，在消息落盘后才会向生产者客户端返回写请求处理结果应答。在异步写模式下，消息写内存映射缓冲区后，即可向生产者客户端返回写请求处理结果应答。同时，元数据写线程会根据消息日志中已经写入的消息，异步写消费队列和直接索引。此外，如果设置了最小备份数，消息写工作线程会向备份请求队列提交备份请求，消息日志对应的观察线程对备份进度进行检测，等待备份完成后向生产者客户端返回写请求处理结果应答。

下面简要介绍PDMMQ系统所包含的四个主要组件：

(1)名服务器：管理并分发消息处理节点的路由信息。消息处理节点以心跳包的形式定期向所有名服务器广播自身IP地址、存储的消息的主题等信息，同时表明服务器在线状态。名服务器收到消息处理节点心跳包后会建立消息主题到消息处理节点地址的映射关系，并且在当生产者或消费者需要获取路由信息时，向其返回某个主题消息对应的消息处理节点地址等信息。

(2)消息处理节点：存储消息并处理消息读写请求。消息处理节点中存储了消息日志以及对应的元数据。对于生产者客户端发送的写请求，则根据消息主题，连同元数据写对应的消息日志后向生产者客户端返回写请求处理结果应答。同时，为提升消息读写速度，消费队列以及索引文件等冗余的消息元数据将以异步的方式持久化。若为消费者客户端发送的读请求，则根据查询方式，使用消费队列或索引文件查找消息在消息日志中的位置，读取消息并返回应答。

(3)生产者：完成消息发送过程。生产者客户端根据消息主题查找本地缓存中是否有对应消息处理节点信息，如果没有，首先向任意名服务器请求路由信息。获取路由信息后，消息被发送到消息处理节点。

(4)消费者：完成消息消费过程。指定消息的主题信息后，消费者查找本地缓存是否存在消息主题对应的消息处理节点信息，如果没有，首先向任意名服务器请求路由信息。获取路由信息后，向消息处理节点发送读请求，接收消息处理节点发送的消息内容。

实验证明，在没有损失读性能的情况下，本发明提高了单个消息处理节点的写吞吐率。在生产者异步发送消息场景中，本发明性能稳定且具有优秀的扩展性。同步写模式下，本发明的写吞吐率最高达到RocketMQ的73倍，Kafka的211.5倍，平均写请求响应时间最低为RocketMQ的0.4％，Kafka的0.1％；异步写模式下，本发明的写吞吐率最高达到RocketMQ的306.4倍，Kafka的2.1倍，平均写请求响应时间最低为RocketMQ的0.1％，Kafka的0.2％。

综上，本发明提出了一种基于多日志的高并发消息队列处理机制，使用多日志结构，多个消息写工作线程并行写多个日志文件，提升了系统整体写速度。消息写工作线程根据消息的主题将消息分配到不同消息日志，具有良好的数据局部性，实现了负载均衡。使用二阶段写机制，将写过程拆分为提交和刷盘两个阶段，并在刷盘阶段对短消息导致的小写请求进行聚合，提高了消息刷盘效率，进一步提高了写吞吐率；同时，请求流量控制策略通过对异步发送模式下的生产者总消息发送速率进行限制，有效解决了生产者异步发送消息场景下的系统过载问题，提升了系统可用性。在消息处理节点启动过程中，检查上次是否正常退出，如果上次异常退出，执行崩溃恢复过程，避免了断电等系统故障所导致的一致性错误。

总的来说，本发明提供的一种多日志高并发消息队列处理机制，可以由用户指定消息日志数量以及消息写工作线程数量，实现高速高并发的消息写过程。且在系统异常崩溃时，提供了崩溃恢复机制，避免了断电等系统故障所导致的一致性错误。

第二方面，本发明提供了一种多日志高并发消息队列处理系统，包括：存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时执行本发明第一方面所提供的多日志高并发消息队列处理方法。

相关技术方案同本发明第一方面所提供的多日志高并发消息队列处理方法，这里不做赘述。

第三方面，本发明还提供了一种计算机可读存储介质，所述计算机可读存储介质包括存储的计算机程序，其中，在所述计算机程序被处理器运行时控制所述存储介质所在设备执行本发明第一方面所提供的多日志高并发消息队列处理方法。

相关技术方案同本发明第一方面所提供的多日志高并发消息队列处理方法，这里不做赘述。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种多日志高并发消息队列处理方法，其特征在于，包括：

当生产者客户端发送的写请求到达消息处理节点后，由请求分发线程将请求分发至写请求处理线程池，并将写请求添加至消息写请求队列中；

由写请求处理线程池中的多个消息写工作线程并行的从消息写请求队列中获取对应的写请求，并将对应的写请求分配到多日志存储结构中的对应消息日志中，然后获取对应消息日志写锁并写入消息；

其中，多日志存储结构包括：多个消息日志；每个消息日志存在唯一写锁，且均包括：多个固定大小的消息日志文件，消息日志文件中存储有消息项，每个消息项中记录有消息体和消息元数据。

2.根据权利要求1所述的多日志高并发消息队列处理方法，其特征在于，消息写工作线程基于写请求中消息的主题将写请求分配到多日志存储结构中的对应消息日志中：将同一主题下的消息分配到相同的消息日志中。

3.根据权利要求2所述的多日志高并发消息队列处理方法，其特征在于，消息写工作线程根据写请求中消息的主题计算哈希值，并对消息日志数量取模，得到消息日志编号后，将写请求分配到该编号下的消息日志中。

4.根据权利要求1所述的多日志高并发消息队列处理方法，其特征在于，写入消息的方法，包括：

将消息的写入过程拆分为提交阶段和刷盘阶段；

在提交阶段执行消息提交操作：由消息写工作线程将消息写入消息日志的内存映射缓冲区；

在刷盘阶段执行刷盘动作：由刷盘线程将内存映射缓冲区内的消息数据持久化到硬盘；

其中，写入消息的模式包括：同步写模式和异步写模式；

在同步写模式下，为每个消息日志设置单独的刷盘线程；消息写工作线程完成其消息提交操作后，将刷盘请求加入刷盘请求队列，并唤醒对应的刷盘线程后等待；待对应的刷盘线程完成刷盘动作后，向生产者客户端返回写请求处理结果应答；

在异步写模式下，消息写工作线程完成其消息提交操作后即可向生产者客户端返回写请求处理结果应答。

5.根据权利要求4所述的多日志高并发消息队列处理方法，其特征在于，在同步写模式下，若内存映射缓冲区中需要刷盘的脏数据总长度小于预设长度，则由消息刷盘线程将刷盘动作推迟预设时间，若在预设时间段内有预设数量的刷盘请求到达，或新到的刷盘请求使脏数据总长度大于预设长度，则立即执行刷盘动作；否则，在预设时间结束后立即执行刷盘动作。

6.根据权利要求1所述的多日志高并发消息队列处理方法，其特征在于，在消息处理节点侧，在写请求到达时，由请求分发线程根据写请求中的消息长度计算写请求的消息负载因子，判断消息负载因子与当前消息写请求队列的写负载强度之和是否大于最大写负载强度，若是，则丢弃写请求，并向生产者客户端发送消息处理节点过载应答；否则，将写请求添加至消息写请求队列中；其中，当前消息写请求队列的写负载强度为当前消息写请求队列中所有写请求的消息负载因子之和；

与此同时，当异步发送模式下的生产者客户端在收到消息处理节点过载应答后，降低自身消息发送速率。

7.根据权利要求6所述的多日志高并发消息队列处理方法，其特征在于，异步发送模式下的生产者客户端在发送写请求之前，根据写请求中的消息长度计算消息负载因子，判断消息负载因子与当前已发送消息的写负载强度之和是否达到当前消息负载强度阈值，若是，则停止发送消息，直至消息负载因子与当前已发送消息的写负载强度之和小于当前消息负载强度阈值后，再发送写请求；否则，发送写请求；

其中，当前已发送消息的写负载强度为当前已发送消息的消息负载因子之和；

当异步发送模式下的生产者客户端在收到消息处理节点过载应答后，降低当前消息负载强度阈值；

当异步发送模式下的生产者客户端连续收到预设数量的消息写请求成功应答后，提高消息负载强度阈值。

8.根据权利要求1-7任意一项所述的多日志高并发消息队列处理方法，其特征在于，所述多日志存储结构使用主题-队列模型管理消息逻辑布局；每个主题下有多个逻辑队列，每个消息对应唯一的(主题，逻辑队列编号，逻辑队列偏移)三元组；

所述多日志存储结构还包括：消费队列文件和直接索引文件，用于存储消息索引数据；

消费队列文件按照消息在逻辑队列中的顺序存储消息消费索引项，消费索引项用于存储消息在逻辑队列中的位置；

直接索引文件用于记录一段时间内写入消息日志的消息的直接索引项的哈希表；哈希表的键为消息的主题键哈希值，值为消息的直接索引项，包括：消息在消息日志中的物理偏移、相对时间戳和后续索引序号；

消息日志文件名代表本文件第一个字节在整个消息日志中的物理偏移；消费队列文件名代表本文件第一条消息在逻辑队列中的序号；直接索引文件名代表本文件的创建时间戳。

9.根据权利要求8所述的多日志高并发消息队列处理方法，其特征在于，还包括：

在消息处理节点启动过程中创建异常退出文件，并使用检查点文件定期持久化消费队列、直接索引以及消息日志的最后刷盘时间；

正常退出时，将所有消息刷盘，并完成消费队列和索引文件的持久化，最后删除异常退出文件；

在消息处理节点启动过程中，检查是否还存在异常退出文件，若存在，则判定上次程序退出异常，执行如下崩溃恢复操作：

对于每一个消息日志，获取该消息日志的直接索引刷盘时间戳、消费队列刷盘时间戳和消息日志刷盘时间戳，并记上述三个时间戳中的最小值为t，对该消息日志的消息日志文件按照文件名升序排序，得到消息日志文件列表，从消息日志文件列表最后一个消息日志文件开始反向遍历；

遍历过程中，对于每一个消息日志文件，读取消息日志文件中第一条消息，对比该消息的消息存储时间T与t的大小，若T小于t，则获取t时刻最后一条刷盘消息所在的消息日志文件F；否则，继续遍历下一个消息日志文件；

其中，在获取到消息日志文件F后，改变消息日志文件的遍历方向，从消息日志文件F开始依次尝试读取消息，并为每一条有效消息在消费队列文件和直接索引文件中构建索引，直至读取到一条无效消息，或读完后续所有消息日志文件，则完成该消息日志的崩溃恢复操作。

10.一种多日志高并发消息队列处理系统，包括：存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时执行权利要求1-9任意一项所述的多日志高并发消息队列处理方法。