CN117692877A - 面向计费c++应用的分布式消息分发方法及系统 - Google Patents

面向计费c++应用的分布式消息分发方法及系统 Download PDF

Info

Publication number
CN117692877A
CN117692877A CN202410148834.0A CN202410148834A CN117692877A CN 117692877 A CN117692877 A CN 117692877A CN 202410148834 A CN202410148834 A CN 202410148834A CN 117692877 A CN117692877 A CN 117692877A
Authority
CN
China
Prior art keywords
event
scf
application
processing
api
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202410148834.0A
Other languages
English (en)
Other versions
CN117692877B (zh
Inventor
郭聪明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Whale Cloud Technology Co Ltd
Original Assignee
Whale Cloud Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Whale Cloud Technology Co Ltd filed Critical Whale Cloud Technology Co Ltd
Priority to CN202410148834.0A priority Critical patent/CN117692877B/zh
Publication of CN117692877A publication Critical patent/CN117692877A/zh
Application granted granted Critical
Publication of CN117692877B publication Critical patent/CN117692877B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/41—Billing record details, i.e. parameters, identifiers, structure of call data record [CDR]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提出一种面向计费C++应用的分布式消息分发方法及系统，包括：业务应用启动并通过SCF API进行初始化，加载分发规则和消费路由；生产者处理业务逻辑后，通过SCF API将事件分发至消息中间件或内存数据库；消费者从消息中间件获取事件，进行去重和业务处理后，清理事件；通过自动重试、双重持久化机制和幂等性检查流程确保数据安全；实施批量消息处理和二进制序列化，以及事件压缩；SCF应用管理和流处理调度监控业务应用，进行异常通知、积压监控和负载均衡。本发明能够灵活处理不同用户的话单，优化并发处理，且根据业务规则分析，动态地对用户进行分组管理，这在处理融合套餐等复杂场景时尤其有用。

Description

面向计费C++应用的分布式消息分发方法及系统
技术领域
本发明涉及属于流式数据处理领域，具体涉及面向计费C++应用的分布式消息分发方法及系统。
背景技术
随着5G技术的全球部署与商用化，其高速率、大容量和低时延的特性促使移动通信市场迅速膨胀，电信运营商面临着处理日益增加的数据量的挑战。尤其是计费系统，作为运营商收入和客户服务的关键环节，必须能够处理海量的话单数据，并确保计费的精确性和实时性。
传统的计费系统大多设计于4G及其之前的技术环境，这些系统通常依赖于集中式的数据处理架构，这在处理5G环境下数据量和数据速度的双重增长时显得不够充分。在5G时代，计费话单的数量不仅大幅增长，而且话单的结构也更为复杂，单条话单可能包含数百个字段，这对数据处理的性能提出了更高的要求。此外，由于5G服务的多样性，话单处理必须严格遵守时序性，确保按照正确的顺序计费，避免因乱序而导致计费错误。
目前，业界急需一种高效、可扩展、并且能保证数据传输安全和话单处理时序性的新型计费系统。该系统需要支持高并发的数据处理，能够适应话单数的几何级数增长，并且在保证数据完整性的基础上，提供快速、可靠的计费服务。此外，计费系统还应能够适应5G用户比例的不断提高和服务类型的日益丰富，能够在硬件资源有限的情况下，实现话单处理性能的最优化。
现有技术中的计费系统通常采用集中式处理架构，这在5G环境下显得力不从心。而分布式流式计算框架作为一种新兴技术，虽然在计算密集型应用如融合计费、佣金结算等业务场景中展现了较好的性能，但在数据共享、流程编排等方面仍存在局限。现有技术未能充分解决在有限硬件资源下如何高效地处理持续增长的海量话单数据，同时保证计费话单的时序性和数据传输的安全可靠。
发明内容
为克服现有技术的不足，本发明提出面向计费C++应用的分布式消息分发方法及系统，通过分布式分组分发技术，能够灵活处理不同用户的话单，优化并发处理，系统根据业务规则分析，动态地对用户进行分组管理，这在处理融合套餐等复杂场景时尤其有用，而且能够根据错误的具体类型进行差异化处理，有效降低异常情况对业务流程的影响。
为实现上述目的，本发明提供面向计费C++应用的分布式消息分发方法，包括：
步骤S1：业务应用启动并通过SCF API进行初始化，加载分发规则和消费路由；
步骤S2：业务应用（生产者）处理业务逻辑后，通过SCF API将事件分发至消息中间件或内存数据库；
步骤S3：业务应用（消费者）从消息中间件获取事件，进行去重和业务处理后，清理事件；
步骤S4：通过自动重试、双重持久化机制和幂等性检查流程确保数据安全；
步骤S5：实施批量消息处理和二进制序列化，以及事件压缩，减少处理延迟和资源消耗；
步骤S6：SCF应用管理和流处理调度监控业务应用，进行异常通知、积压监控和负载均衡。
进一步地，步骤S1包括：
步骤S11：启动业务应用程序；
步骤S12：业务应用程序调用SCF API的初始化接口；
步骤S13：SCF API从内存数据库ZMDB中加载分发规则；
步骤S14：SCF API从内存数据库ZMDB中加载消费路由信息。
进一步地，步骤S2包括：
步骤S21：生产者完成业务处理；
步骤S22：生产者调用SCF API的事件输入接口；
步骤S23：生产者调用SCF API的事件分发接口；
步骤S24：将正常事件输出到消息中间件MQ；
步骤S25：将异常事件输出到内存数据库ZMDB。
进一步地，步骤S3包括：
步骤S31：消费者调用SCF API接口获取事件；
步骤S32：消费者执行事件去重处理；
步骤S33：消费者进行业务处理；
步骤S34：消费者完成业务处理后调用流处理API接口；
步骤S35：流处理API接口执行事件清理。
进一步地，步骤S6包括：
步骤S61：SCF应用管理监控业务应用；
步骤S62：发现消费者异常时，发送通知至流处理调度；
步骤S63：流处理调度执行积压监控；
步骤S64：流处理调度进行负载均衡评估；
步骤S65：需要时，流处理调度发送高低水通知至SCF应用管理；
步骤S66：SCF应用管理进行负载均衡调节；
步骤S67：SCF应用管理发送消费路由更新通知至SCF API。
面向计费C++应用的分布式消息分发方法的系统，适用于上述的面向计费C++应用的分布式消息分发方法，包括SCF API模块、SCF调度管理模块和SCF应用管理模块；
SCF API模块：作为核心的接口模块，它由两个子模块组成：
生产者API：提供接口供业务应用上传话单事件，包括负载分发、目标消费者匹配、数据路由计算，以及确保数据传输的安全性和压缩效率；
消费者API：提供接口供业务应用下载话单事件，管理数据路由到指定的消费者，并保持处理的顺序性；
SCF调度管理模块：负责协调SCF API模块，执行任务包括：
负载均衡管理：动态调整资源分配，以响应不同的系统负载情况；
消费者异常管理：监测和响应消费者进程的异常，保障系统稳定性；
分发规则管理：配置和更新话单分发的规则；
消费路由管理：维护数据路由信息，确保消息准确分发；
SCF应用管理模块：监控和管理生产者和消费者应用的运行状态，职责包括：
应用启停：控制业务应用的生命周期，包括启动和停止操作；
应用监控：实时监控应用性能和状态，提供运行数据；
高低水调节：根据系统负载动态调整资源分配；
故障自动接管：在应用出现故障时自动采取恢复措施。
进一步地，生产者API是SCF系统中负责事件分发的模块，包括分布式分组分发技术、数据安全传输策略和高效传输压缩技术。
进一步地，分布式分组分发技术具体如下：
用户关联分析：通过分析用户之间的关联关系（如融合套餐和额外订购的套餐），对用户进行动态分组；
分布式分组技术：对用户和销售品实例进行关联分析，创建无关联用户的不同分组，以提高计费业务处理的并发度和独立性；
事件分发：系统将话单抽象为事件，通过用户关联分组进行事件分发，保证计费处理的时序性，避免同一用户的多条话单被并行处理；
路由计算：引入路由计算算法，包括主题选择算法和路由选择算法，以确保事件按照业务规则正确分发到消费者；
负载均衡调节：当生产者事件分发存在不均衡时，通过消费者事件路由的负载均衡调节来确保事件处理的均衡性；
高并发实时处理：实现了解耦、重新编排和横向扩展的计费流程，使不同用户分组的计费流程可以并发执行，提高了处理效率；
总的来说，该系统提供了一种有效的方法，通过用户分组和分布式技术来优化复杂的计费业务流程，确保数据处理的效率和准确性。
进一步地，数据安全传输策略包括事件生产者的错误处理和持久化、异常数据自动回收机制和幂等性检查流程，具体如下：
所述事件生产者的错误处理和持久化包括：
尝试记录异常输入事件到MDB，如果因为ERR_MDB_OVERSTOCK失败，则直接报告错误，如果因为其他原因失败，尝试记录到文件系统；
尝试记录异常输出事件到MDB，如果因为ERR_MDB_OVERSTOCK失败，尝试记录到文件，如果文件写入成功，设置状态位禁止进一步发送，如果文件写入失败，报告错误并停止业务应用；
所述异常数据自动回收机制包括：
从异常输入事件表中获取待回收事件，检查异常输出表中是否有关联记录，如果有，从异常输出事件表中获取待回收记录；
调用流处理事件输入接口处理异常事件，重新发送事件，设置事件状态为已回收；
将已回收事件移至历史表，并从当前异常表中删除；
所述幂等性检查流程包括：
对于可能的重复消费场景，如生产者重复发送，建立生产者检查点，对于消费者可能的重复消费情况，如消费进度更新失败或消费者实例重复启动，建立消息处理检查点；
使用检查点信息辨识重复消息，并防止这些消息被再次消费。
进一步地，高效传输压缩技术包括序列化与反系列化和压缩处理；
所述序列化与反序列化流程包括：
事件对象转换为二进制数据进行序列化，以便通过消息中间件进行传输，采用自定义的序列化协议，确保所有数值类型字段采用网络字节序列化，以保持异构系统间的兼容性；
消息体包括自定义属性和事件协议包集合，自定义属性和事件协议包序列化后拼接在消息体头部，多个事件序列化后的数据组成事件协议包集合；
每个事件的序列化结果包含校验码、协议包长度、事件格式标识和属性协议包集合，不同类型的属性有不同的属性值协议包格式；
所述压缩处理包括，将序列化后的事件数据进行批量打包，使用zlib库对批量打包后的数据进行压缩，压缩后的数据写入消息队列（MQ）。
与现有技术相比，本发明的有益效果是：
1.本发明提供了面向计费C++应用的分布式消息分发方法及系统，通过分布式分组分发技术，能够灵活处理不同用户的话单，优化并发处理，而且能够支持端到端的快速响应，即使在高流量情况下也能保持低延迟。
2.本发明提供了面向计费C++应用的分布式消息分发方法及系统，系统根据业务规则分析，动态地对用户进行分组管理，这在处理融合套餐等复杂场景时尤其有用。
3.本发明提供了面向计费C++应用的分布式消息分发方法及系统，系统设计了详细的异常处理逻辑，能够根据错误的具体类型进行差异化处理，有效降低异常情况对业务流程的影响。
4.本发明提供了面向计费C++应用的分布式消息分发方法及系统，自定义的序列化方案和高效的压缩算法能够减少系统资源消耗，提高数据传输效率，采用模块化设计，便于后续维护和扩展，支持新业务场景的快速集成。
5.本发明提供了面向计费C++应用的分布式消息分发方法及系统，通过用户关联分组并发处理，减少了批价锁冲突和环节内等待时间，提高了整体业务流程效率，允许计费流程进行解耦和重新编排，提高系统的灵活性和响应速度。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明步骤流程示意图；
图2是本发明系统流程图；
图3为本发明系统架构图；
图4是本发明分组计费流程示意图；
图5是本发明分布式分组分发示意图；
图6是路由计算算法示意图；
图7是数据安全传输策略示意图；
图8是压缩处理示意图；
图9是协议格式示意图；
图10是二次压缩处理示意图。
具体实施方式
下面将结合附图、通过对本发明的优选实施方式的描述，更加清楚、完整地阐述本发明的技术方案。
MQ：Message Queue
消息中间件，独立的分布式消息存储集群，用于实现应用和数据的解耦，保证消息的安全性。
SCF：Streaming Computing Framework
流式计算框架，基于消息中间件MQ封装的分布式计费调度框架，主要用于计费流程话单的流转调度。
ZMDB：ZsmartMemory Database
浩鲸科技自主研发的分布式内存数据库，主要用于存储计费高频访问的核心数据，加快计费应用的数据访问性能。
如图1所示，本发明为：
步骤S1：业务应用启动并通过SCF API进行初始化，加载分发规则和消费路由；
步骤S2：业务应用（生产者）处理业务逻辑后，通过SCF API将事件分发至消息中间件或内存数据库；
步骤S3：业务应用（消费者）从消息中间件获取事件，进行去重和业务处理后，清理事件；
步骤S4：通过自动重试、双重持久化机制和幂等性检查流程确保数据安全；
步骤S5：实施批量消息处理和二进制序列化，以及事件压缩，减少处理延迟和资源消耗；
步骤S6：SCF应用管理和流处理调度监控业务应用，进行异常通知、积压监控和负载均衡。
具体如图2所示，包括：
1.SCF应用管理负责业务应用部署、启停、监控和高低水调节，以及应用故障时的故障自动接管。
2.SCF提供SCF API接口供业务应用调用，主要过程如下：
1)业务应用启动时，调用SCF API提供的初始化接口，SCF API从内存数据库ZMDB中加载分发规则和消费路由。
2)业务应用（生产者）进行业务处理后，调用SCF API提供的事件输入/事件分发接口完成事件的分发处理，并把正常事件输出到消息中间件MQ中，异常事件输出内存数据库ZMDB中。
3)业务应用（消费者）调用SCF API接口从消息中间件MQ中获取一个批次的路由事件，先对该批次路由事件进行事件去重处理，然后再对去重后的路由事件业务处理；业务处理完成后，业务应用（消费者）调用流处理API接口进行事件清理。
3.SCF应用管理监控业务应用，当发现消费者异常时，发送消费者异常通知给流处理调度。
4.流处理调度进行积压监控和负载均衡评估，当需要增减进程数时，发送“高低水通知”给SCF应用管理；SCF调度管理进行负载均衡调节，并发送“消费路由更新通知”给SCFAPI。
本方法的实施步骤可以概括为以下几个阶段：
1.系统初始化：
1)启动业务应用，并调用SCF API的初始化接口。
2)从内存数据库ZMDB中加载分发规则和消费路由。
2.事件生产和分发：
1)生产者进行业务处理后，调用SCF API提供的事件输入/事件分发接口完成事件的分发处理。
2)将正常事件输出到消息中间件MQ中，将异常事件输出到内存数据库ZMDB中。
3.事件消费处理：
1)消费者调用SCF API接口从消息中间件MQ中获取一批路由事件。
2) 对该批路由事件进行事件去重处理，然后进行业务处理。
3) 业务处理完成后，调用流处理API接口进行事件清理。
4. 数据安全保障：
1)在消息发送端，通过自动重试和ZMDB分布式内存数据库和文件系统的双重持久化机制，以及异常数据自动回收机制，保证生产端的数据不会丢失。
2)在消费端，通过幂等性检查流程，保证数据不会被重复消费。
5. 性能优化：
1)提供批量消息收发接口以减少话单的平均处理时延，提高系统的吞吐量。
2)实现二进制序列化协议，以及基于事件路由分组的批量话单事件的二次高效压缩，减少网络IO和MQ存储资源的消耗。
6. 监控与异常处理：
1)SCF应用管理监控业务应用，当发现消费者异常时，发送消费者异常通知给流处理调度。
2)流处理调度进行积压监控和负载均衡评估，当需要增减进程数时，发送“高低水通知”给SCF应用管理。
SCF调度管理进行负载均衡调节，并发送“消费路由更新通知”给SCF API。
如图3所示，为本发明的系统架构图，具体如下：
1.SCF API
基于MQ封装的SCF客户端接口，实现计费话单的有序、安全和高效传输，采用事件对象抽象的方式供预处理、拣重、批价、合帐等业务应用调用。SCF API分为生产者API和消费者API，通过MQ数据路由进行生产者和消费者之间的话单流转。
1)MQ数据路由
生产者与消费者之间事件流转的路由通道。通过定义消息中间件的不同主题区分目标消费者，通过定义不同的消息队列区分数据路由。
2)生产者API
生产者把事件均衡分发到各个数据路由中。支持按条件配置匹配确定目标消费者，按分布式分组分发算法计算确定数据路由，保证数据分发的严格时序性要求。生产者API通过数据安全传输策略和高效传输压缩算法，保证话单流转的安全和高效。
3)消费者API
消费者从指定数据路由中获取事件。一个消费者负责多个数据路由的接收，一个数据路由只能分配给一个消费者处理，保证多进程并发场景下消费的严格时序性。
2.SCF调度管理
负责SCF API的统一调度管理，包括负载均衡管理、消费者异常管理、分发规则管理和消费路由管理。
3.SCF应用管理
负责SCF生产者和消费者应用的监控管理，包括应用启停、应用监控、高低水调节、故障自动接管。
作为一种具体实施方式，分布式用户分组技术具体如下：
分布式用户分组技术，可以基于业务规则的动态分析，通过关联分组算法对用户进行关联关系管理。业务应用可以基于用户关联关系实现并行处理，且不会引发并发数据库锁冲突问题。同时，由于关联用户在一个进程处理，如果关联用户的当前环节处理完成后，可以直接进入下一个环节，不用等待其它非关联用户处理完成，整个计费流程可以实现横向扩展。
分布式分组分发技术，是基于分布式用户分组的一种路由选择算法，可以确保路由分发的负载均衡和严格时序性，可以实现无锁的应用多进程高并发处理。
SCF将MQ消息中间件作为底层设施之一，将应用通过文件进行数据流转的方式改造为通过消息进行数据流转。每个应用不再需要关心哪些应用会发送过来数据，不需要关心自己要把数据发送给哪个应用，而是通过独立的数据管理集群进行消息的中转和使用。
为了避免业务模块和特定的消息中间件实现耦合，也为了简化业务代码改造，SCF定义了一个中间层，让业务代码以更抽象的方式进行数据的生产和消费，而不需要关心底层是否是消息中间件，或具体是哪种中间件实现。
SCF在自己的中间层中，还根据业务需求提供了更严格的消息时序性保证：SCF不依赖消息中间件，自行管理队列信息以及生产者发送数据时的队列选择算法。可以按照特定业务字段进行队列选择；支持根据复数字段进行二次队列选择，以满足业务模块更复杂的数据发送要求。
传统的用户分组，一般是基于用户取模或者帐户取模确定用户分组标识，一旦确定之后就不会变更。分布式用户分组，是基于用户套餐关联关系进行动态分析，可以随着用户套餐的变更而动态变化；
因为业务上用户之间存在多层的嵌套关联关系，比如：融合套餐，优惠时需要参考套餐下的多个用户的费用进行处理，融合套餐下的用户还可以同时再订购其它的套餐。所以，必须基于业务规则分析，将用户进行动态分组。由于计费套餐业务涉及到用户，商品等，所以引入分布式用户分组技术，需要按照用户，销售品实例进行关联关系动态分析，将无关联的用户生成不同的分组。
用户资料数据如果按照关联用户分组进行计算，如表1所示：先进行用户关联关系分析，销售品P1下的三个用户通过销售品P1存在直接关联关系。所以用户S1、S2、S3需要被划分在同一个用户分组1。其中用户S1还订购了销售品P2，那么P2下的所有用户与P1下的用户也存在关联关系，即用户S4通过用户S1和P1下的其它用户也间接存在关联关系。所以S1，S2，S3，S4都存在关联关系，最终都需要被划分到用户分组1。对于用户S5只订购了销售品P3，且P3没有其它用户，所以S5不存在其它关联用户，则S5被单独划分到用户分组2。本方案实现将用户进行业务分析之后，按照关联关系进行分组管理。计费业务处理按分组并发，增加并发度。同时没有关联关系的用户的业务处理流程相互独立，互不影响，不用强制等待；
表1
进行“关联用户”分析后，计费流程可以按用户分组尽可能多地进行并发处理，从而减少相同环节内等待的时间，提升环节内处理效率，同时可以避免共享套餐多用户并发扣减累积量的批价锁冲突。
计费流程环节间也不再进行相互等待，直接按照用户分组维度进行计费流程处理。如图4所示，不同用户分组的计费流程可以并发，比如：用户关联分组1的批价处理完成之后，直接可以进入实时优惠环节处理，不用等待其它分组的批价处理完成。整个计费流程可以进行解耦、重新编排、横向扩展，实现高并发实时计费处理。
如图5所示，SCF将话单抽象为事件，话单包含的数据抽象为事件的属性。对数据的读写进行了统一抽象，业务应用只需要在发送和消费时，在内部数据和SCF事件对象之间进行一层转换， 不触动核心业务逻辑，不关心消息的发送目标和消费来源，就可以快速接入SCF，SCF提供SCF事件分发API和事件接收API用于业务应用的接入。
通过用户关联分组进行事件分发确保计费处理的严格时序性要求。由于SCF事件分发时，按用户关联分组分发，对于同一个用户，可以确保只会分发到一个事件路由中，而且对于消费者，同一个时间只会有一个消费者消费一个事件路由，所以同一个用户的多条话单不会被同时处理，可以确保严格的时序性。
通过按用户关联分组进行哈希计算分发，确保生产者事件分发到事件路由中可以确保分发的均衡性，当生产者事件分发存在不均衡时，还可以通过消费者的事件路由的负载均衡调节来确保事件处理的均衡性。
SCF通过SCF事件分发API支持分布式分组分发的路由计算，路由计算算法如图6所示：
1、主题选择算法：通过主题选择算法决定事件分发给哪些消费者，由生产者指定事件格式类型，生产者API根据指定的事件格式类型确定分发的主题，消费者订阅消费组时根据指定主题进行消费。
1）支持一个生产者生成的消息分发给多个消费者进行消费，支持多个生产者生成的消息分发给一个消费者进行消费。
2）支持生产者输出事件时，根据配置的条件规则进行事件判断，可以按条件输出到不同主题，或者按条件进行事件过滤。
2、路由选择算法：根据分发规则配置确定事件分发到那个数据路由，分发规则支持参考事件属性，支持参考多个事件属性计算路由。
分发规则配置示例如表2所示：
表2
1）对于“1-哈希算法，参考1个路由属性”路由计算方法，根据事件中的用户关联分组标识进行哈希计算后，得到的哈希值确定具体的数据路由。
2）对于“2-按路由属性值配置计算”，需要根据客户分组标识查找路由属性值配置，根据查找到的数据路由范围，再根据用户标识进行哈希计算，得到的哈希值确定具体的数据路由。路由属性值配置主要包括如下属性：路由属性值分组标识、路由属性值、路由范围开始、路由范围结束。
数据安全传输策略：
如图7所示，除了消息中间件自身提供的数据安全机制，SCF在业务端的数据生产和消费流程也增加了额外的数据安全策略。
在消息发送端，通过自动重试+异常数据通过ZMDB分布式内存数据库和文件系统的双重持久化机制，辅以异常数据自动回收机制，保证生产端的数据不会丢失。
而在消费端，计费系统要求数据不能重复消费，以避免造成重复扣费等。通过归纳分析业务系统发送端和消费端所有可能导致重复消费的场景，SCF设计了一套幂等性检查流程。SCF通过ZMDB分布式内存数据库记录消息消费进度，发送端进行消息发送的连续性编号，消费端进行消息消费连续性检查，最终实现消费排重，达到幂等性的要求，保证了线上系统消息消费0重复。
在事件生产者的事件发送接口内部流程中，一些流程可能会出现错误，此时需要记录相关信息到错误记录表，以方便其它模块回收重处理。根据发生错误的位置的不同，如何记录错误信息也有所区别。比如消息发送失败，则会先进行重发，如果重发多次还是失败，则需要进行消息的异常持久化，这里采用MDB和文件的双重持久化机制。
为了便于异常事件回收和问题定位，这里需要记录异常输入事件和异常输出事件至MDB中，如果MDB写入失败，则根据不同的错误返回码做出不同的处理，详细逻辑如下：
1)如果流框发现MDB写入失败原因是 ERR_MDB_OVERSTOCK， SCF不会尝试将异常事件记录到文件中，而是直接返回错误，告知业务应用事件发送失败。（备注：如果是MDB数据量写入远大于配置的最大记录数，说明业务应用产生了大量的异常输入事件，属于系统级异常，MDB会抛出包含特定错误信息的异常，SCF遇到这种异常，会转换为特定的错误码，本文用 ERR_MDB_OVERSTOCK 代指）
a)此时异常事件没有保存到MDB和文件，数据也没有发送到下一个环节，业务应用也没有进行消费确认，相当于这批数据没有消费处理过。
b)业务应用重启后，重新处理不会导致消息丢失或重复。
2)如果流框发现MDB写入失败原因不是 ERR_MDB_OVERSTOCK，则会尝试将异常事件记录到文件中。
a)文件写入成功，则流框继续后面的输出事件处理流程。
b)文件写入失败，则流框反馈失败，业务侧终止运行。同上，由于业务应用也、没有进行消费确认，不会导致消息丢失或重复。
1)如果流框发现MDB写入失败原因是 ERR_MDB_OVERSTOCK，继续尝试写文件
a)文件写入成功，接口返回成功，流处理API内部置状态位为禁止发送。下次调用事件发送接口时，立即返回失败。
这样业务应用会将当前批次的数据进行消费确认，避免已发送成功的小部分数据，后面重复发送。
b)文件写入失败，接口返回失败，此时会出现极端异常场景。
2)如果流框发现MDB写入失败原因不是 ERR_MDB_OVERSTOCK，继续尝试写文件
a)文件写入成功，接口返回成功
b)文件写入失败，接口返回失败，此时会出现极端异常场景。
3)极端异常场景：
a)流处理API内部尽可能保证在异常场景下，消息既不重复，也不丢失。但在一些极端异常场景下，仍会出现SCF无法同时保证不重复和不丢失的情况。基于数据安全性考虑，SCF采取保证数据不丢失，但可能重复的处理方式。
b)如果异常输出事件写MDB失败，写首选文件失败，写备用文件也失败，3者同时失败的情况下，为了保证消息不丢失，流处理API事件发送接口返回错误，业务应用终止处理。
c)但此时已经有一部分数据发送出去，当业务应用重启后，这部分数据会再次发送，导致数据重复。对于这种极端场景下的重复数据，通过消费端的幕等性流程来避免数据重复。
异常事件回收是独立的常驻应用程序，定时通过数据访问接口从异常事件表中获取状态为待回收的记录，对于每一条记录，调用流处理API事件处理接口进行处理，然后将事件重新发送出去，状态改为已回收，之后将记录写入到异常事件历史表中，从异常事件表删除该记录。
主要流程如下：
幂等性检查流程，主要是为了解决在某些特定场景下，比如生产端消息重复发送等，如何避免消费端消息重复消费的方案。
可能导致消息重复消费的主要场景如下：
SCF 封装的消息发送接口，由自动重试机制。当消息发送失败时，会自动重试。存在这样一种可能：消费发送成功，但是服务端没有及时返回响应报文（如网络问题等），这样SCF 人为消费没有发送成功，重试发送，会导致同一条消息多次发送。这种情况下，多条消息的 MSG_ID 不同，但是 SERVICE_MSG_ID 相同。
1)消费进度更新失败
MQ 消费进度更新操作是无确认操作，即不保证消费进度一定更新成功。当消费者实例和路由的消费关系发生变化，或消费者实例发生重启时，会从 MQ 服务端获取最新的消费进度。如果消费进度更新失败，消费者实例就会取到旧的消费进度，导致重复消费。
2)消费者重复启动
SCF 通过应用实例标识关联一个消费者实例及其可使用的路由。如果多一个消费者实例启动了多个进程，会导致跨进程重复消费。
3)消费路由重复分配
如果由于异常情况（比如人工修改路由等），导致不同的消费者实例消费了同一个路由，会导致跨进程重复消费。
根据前面描述的消息重复消费场景，按场景采取不同的消息排重方案。
一、设置消息处理检查点和生产者检查点。
MQ 更新消费进度是无确认操作，因此增加消息处理检查点表，缓存消息处理进度。但是应该注意，这张检查点表不等价于消费进度，任何直接涉及消费进度的操作（比如消费进度的查询，更新等）仍然以 MQ 服务端为准。这张表是消费进度的“本地”副本，只用于消费排重检查。
只通过消费检查点无法处理生产者重复发送导致的重复消费，重复发送的消息，其 msg_id 和 offset 是不一样的，无法通过消费检查点识别。为此引入生产者检查点处理生产者重复发送导致的重复消费。
指一个队列上，一个生产者进程生成的最新消息的序号（APP_MSG_SEQ），生产者检查点使用 map 保存检查点信息如下：
1)key ：进程唯一标识（app_unique_id）+路由（route）
2)value：通过一个结构体记录检查点信息，至少包括：
a)app_msg_seq：消息序号
b)state_time：检查点信息更新时间
二、根据不同的场景进行方案可行性分析：
通过生产者检查点解决生产者重复发送导致的重复消费。
通过 APP_UNIQUE_ID + APP_MSG_SEQ，可以确保同一个进程（APP_UNIQUE_ID）发送到同一个队列上的消息正常情况下是单调递增的（APP_MSG_SEQ）。只要 APP_MSG_SEQ 违反单调递增规则，即说明消息是生产端重复发送的。
1)消费进度更新失败
消息处理检查点表缓存消费进度是同步调用的，即使 MQ 集群更新消费进度失败，消息处理检查点表中的数据是可靠的。
2)消费者实例重复启动
在使用消息处理检查点表缓存消费进度是，会通过 state_time 和 consumer_inst 进行过滤。
如果消费者实例更新消息处理检查点表失败，说明由其它进程在同时更新同一条记录，即说明消息实例重复启动或消费路由重复分配。
高效压缩：
如图8所示，消息中间件自身只提供了单条消息的收发接口，为了满足计费系统的性能要求，SCF提供了批量消息收发接口，来减少话单的平均处理时延，提高系统的吞吐量。
进行数据的收发时，计费话单和中间件消息之间需要进行序列化和反序列化。在调研测试了Protocol Buffers 和 JSON 序列化协议后，两者在性能、灵活性、复杂性上各有优劣，Protocol Buffers 虽然性能优异，但是灵活性太差，不易维护。JSON则是性能和数据压缩率较差。最终SCF自行实现了一个二进制序列化协议，在提供Protocol Buffers同等级性能的同时，报文字段可弹性添加。
计费月话单量达到几百亿级别，每条话单计费信息字段超过百个，计费话单跨计费应用流转环节数达10+多，导致计费话单交互时SCF需要耗费巨大的网络IO和MQ存储资源。SCF为了缩减网络IO和MQ存储资源占用，在二进制系列化的一级压缩基础上，基于事件路由分组的批量话单事件，统一打包后进行二次高效压缩。
序列化与反序列化具体如下：
业务进程调用流处理API收发的基本单位是事件，而在流处理API内部，是使用消息中间件进行消息的收发的。流处理API内部不能直接收发事件对象，在发送消息时，需要按照一定的协议将事件对象序列化为二进制数据，在拉取消息时，将二进制数据反序列化得到对应的事件对象。
考虑过使用JSON方案，但JSON方案效率太低，不足Protobuf的1/10。而Protobuf灵活性太差，不易维护。最终决定使用自定义的序列化方案，经初步测试，其性能比Protobuf更高，数据压缩上则稍差一筹，同样的数据，自定义序列化方案编码后的数据，是Protobuf的1.5倍。
1)网络字节序
对于所有数值类型的字段，必须采取网络字节序，以避免主机字节序不同的异构系统中，数值字段解析存在差异。需要使用网络字节序的字段有：协议包长度、事件格式标识、属性ID、属性类型、属性值协议包长度、用户定义类型、元素值长度等。
2)消息体
消息体包含自定义属性和事件协议包集合。
3)自定义属性
消息自定义属性按协议格式序列化后拼接在消息体的头部，作为消息体一部分发送，在消息解码时先按协议解码出自定义消息属性，剩余数据设置给消息体供后续解码出事件数据。
4)事件协议包集合
流处理API发送事件时，会将多个事件打包到一条消息里，多个事件序列化后的数据组成的整体，就是事件协议包集合。
5)事件协议包
一个事件序列化后的结果。
a)校验码：4字节二进制数据，用于解析时辅助校验，值固定为 0xFF FE FD FC。
b)协议包长度：4字节整型，整个事件协议包的大小。
c)事件格式标识：4字节整型。
d)事件属性协议包集合：连续保存的一组事件协议包数据，根据“协议包长度”字段的值，可以判断事件属性协议包集合的结束位置。
6)事件属性协议包集合
一个事件包含的全部属性序列化的结果。事件属性协议包集合由若干个事件属性序列化后的结果拼接而成。
7)事件属性协议包
事件的一个属性的序列化结果。
a)属性ID：4字节整型。
b)属性类型：4字节整型。（理论上1字节就可以保存属性类型，4字节是为了方便字节对齐）
c)属性值协议包长度：4字节整型。属性值协议包部分的长度，单位字节。
d)属性值协议包：一个事件属性对象的属性值部分序列化后的结果。
e)不同类型的属性，其属性值存储格式有一定不同。
8)属性值协议包
不同类型的属性，有不同的属性值协议包格式，对应的存储格式有所不同：
a)普通类型：没有单独说明的所有类型，都归在普通类型下，这些类型的属性，直接保存属性值即可。
b)用户自定义类型和对应的数组类型：用户自定义类型，用户自定义数组类型，这两种类型的属性值部分，开始处有一个额外的字段：用户定义类型，该字段为4字节整型，保存用户自定义的数据类型标识。
c)字符串数组：由于字符串数组每个元素的长度都可能是不同的，因此需要为每个元素增加一个字段，元素值长度字段，来保存一个字符串元素的长度。
二次高压技术具体如下：
流处理API的事件分发接口，接收一批待发送事件后，经过事件拆分，路由计算后，输出事件按照目标路由进行分组，逐组进行处理。
处理一组输出事件的主要操作，就是要将输出事件进行序列化，得到消息体数据，调用路由消息接口进行消息发送。事件序列化可能将多个输出事件打包序列化为一个消息体数据。
SCF为了减少网络IO和MQ存储，提升应用处理性能，引入了二次高效的MQ压缩技术。MQ压缩技术，即对环节间交互的话单事件批量打包后，采用zlib库压缩数据后写入MQ，可压缩到原始数据的1/10~1/20，详细如图10所示；
这里压缩的效果主要取决于批量话单打包时事件分组的效果，如果只有少量的话单事件分到同一个路由分组，则压缩效果就会比较差；反之，如果较多的话单事件分到同一个路由分组，则压缩效果就会比较好。我们想要获得最佳的压缩效果，需要确保从上游环节MQ中获取的一批话单事件，给下游环节分发时，不会被打散分发到多个数据路由中，这就对我们的事件分组提出了更高的要求，既要确保严格时序性，又要确保上下游保持一致性，才能发挥最佳的压缩效果。
上述具体实施方式仅仅对本发明的优选实施方式进行描述，而并非对本发明的保护范围进行限定。在不脱离本发明设计构思和精神范畴的前提下，本领域的普通技术人员根据本发明所提供的文字描述、附图对本发明的技术方案所作出的各种变形、替代和改进，均应属于本发明的保护范畴。本发明的保护范围由权利要求确定。

Claims (10)

1.面向计费C++应用的分布式消息分发方法，其特征在于，包括：
步骤S1：业务应用启动并通过SCF API进行初始化，加载分发规则和消费路由；
步骤S2：生产者处理业务逻辑后，通过SCF API将事件分发至消息中间件或内存数据库；
步骤S3：消费者从消息中间件获取事件，进行去重和业务处理后，清理事件；
步骤S4：通过自动重试、双重持久化机制和幂等性检查流程确保数据安全；
步骤S5：实施批量消息处理和二进制序列化，以及事件压缩，减少处理延迟和资源消耗；
步骤S6：SCF应用管理和流处理调度监控业务应用，进行异常通知、积压监控和负载均衡。
2.根据权利要求1所述的面向计费C++应用的分布式消息分发方法，其特征在于，步骤S1包括：
步骤S11：启动业务应用程序；
步骤S12：业务应用程序调用SCF API的初始化接口；
步骤S13：SCF API从内存数据库ZMDB中加载分发规则；
步骤S14：SCF API从内存数据库ZMDB中加载消费路由信息。
3.根据权利要求1所述的面向计费C++应用的分布式消息分发方法，其特征在于，步骤S2包括：
步骤S21：生产者完成业务处理；
步骤S22：生产者调用SCF API的事件输入接口；
步骤S23：生产者调用SCF API的事件分发接口；
步骤S24：将正常事件输出到消息中间件MQ；
步骤S25：将异常事件输出到内存数据库ZMDB。
4.根据权利要求1所述的面向计费C++应用的分布式消息分发方法，其特征在于，步骤S3包括：
步骤S31：消费者调用SCF API接口获取事件；
步骤S32：消费者执行事件去重处理；
步骤S33：消费者进行业务处理；
步骤S34：消费者完成业务处理后调用流处理API接口；
步骤S35：流处理API接口执行事件清理。
5.根据权利要求3所述的面向计费C++应用的分布式消息分发方法，其特征在于，步骤S6包括：
步骤S61：SCF应用管理监控业务应用；
步骤S62：发现消费者异常时，发送通知至流处理调度；
步骤S63：流处理调度执行积压监控；
步骤S64：流处理调度进行负载均衡评估；
步骤S65：需要时，流处理调度发送高低水通知至SCF应用管理；
步骤S66：SCF应用管理进行负载均衡调节；
步骤S67：SCF应用管理发送消费路由更新通知至SCF API。
6.面向计费C++应用的分布式消息分发方法的系统，适用于权利要求1-5任一项所述的面向计费C++应用的分布式消息分发方法，其特征在于，包括SCF API模块、SCF调度管理模块和SCF应用管理模块；
SCF API模块：作为核心的接口模块，它由两个子模块组成：
生产者API：提供接口供业务应用上传话单事件，包括负载分发、目标消费者匹配、数据路由计算，以及确保数据传输的安全性和压缩效率；
消费者API：提供接口供业务应用下载话单事件，管理数据路由到指定的消费者，并保持处理的顺序性；
SCF调度管理模块：负责协调SCF API模块，执行任务包括：
负载均衡管理：动态调整资源分配，以响应不同的系统负载情况；
消费者异常管理：监测和响应消费者进程的异常，保障系统稳定性；
分发规则管理：配置和更新话单分发的规则；
消费路由管理：维护数据路由信息，确保消息准确分发；
SCF应用管理模块：监控和管理生产者和消费者应用的运行状态，职责包括：
应用启停：控制业务应用的生命周期，包括启动和停止操作；
应用监控：实时监控应用性能和状态，提供运行数据；
高低水调节：根据系统负载动态调整资源分配；
故障自动接管：在应用出现故障时自动采取恢复措施。
7.根据权利要求6所述的面向计费C++应用的分布式消息分发方法的系统，其特征在于，生产者API是SCF系统中负责事件分发的模块，包括分布式分组分发技术、数据安全传输策略和高效传输压缩技术。
8.根据权利要求7所述的面向计费C++应用的分布式消息分发方法的系统，其特征在于，分布式分组分发技术具体如下：
用户关联分析：通过分析用户之间的关联关系，对用户进行动态分组；
分布式分组技术：对用户和销售品实例进行关联分析，创建无关联用户的不同分组，以提高计费业务处理的并发度和独立性；
事件分发：系统将话单抽象为事件，通过用户关联分组进行事件分发，保证计费处理的时序性，避免同一用户的多条话单被并行处理；
路由计算：引入路由计算算法，包括主题选择算法和路由选择算法，以确保事件按照业务规则正确分发到消费者；
负载均衡调节：当生产者事件分发存在不均衡时，通过消费者事件路由的负载均衡调节来确保事件处理的均衡性；
高并发实时处理：实现解耦、重新编排和横向扩展的计费流程，使不同用户分组的计费流程并发执行。
9.根据权利要求7所述的面向计费C++应用的分布式消息分发方法的系统，其特征在于，数据安全传输策略包括事件生产者的错误处理和持久化、异常数据自动回收机制和幂等性检查流程，具体如下：
所述事件生产者的错误处理和持久化包括：
尝试记录异常输入事件到MDB，如果因为ERR_MDB_OVERSTOCK失败，则直接报告错误，如果因为其他原因失败，尝试记录到文件系统；
尝试记录异常输出事件到MDB，如果因为ERR_MDB_OVERSTOCK失败，尝试记录到文件，如果文件写入成功，设置状态位禁止进一步发送，如果文件写入失败，报告错误并停止业务应用；
所述异常数据自动回收机制包括：
从异常输入事件表中获取待回收事件，检查异常输出表中是否有关联记录，如果有，从异常输出事件表中获取待回收记录；
调用流处理事件输入接口处理异常事件，重新发送事件，设置事件状态为已回收；
将已回收事件移至历史表，并从当前异常表中删除；
所述幂等性检查流程包括：
对于可能的重复消费场景，如生产者重复发送，建立生产者检查点，对于消费者可能的重复消费情况，如消费进度更新失败或消费者实例重复启动，建立消息处理检查点；
使用检查点信息辨识重复消息，并防止这些消息被再次消费。
10.根据权利要求7所述的面向计费C++应用的分布式消息分发方法的系统，其特征在于，高效传输压缩技术包括序列化与反系列化和压缩处理；
所述序列化与反序列化流程包括：
事件对象转换为二进制数据进行序列化，以便通过消息中间件进行传输，采用自定义的序列化协议，确保所有数值类型字段采用网络字节序列化，以保持异构系统间的兼容性；
消息体包括自定义属性和事件协议包集合，自定义属性和事件协议包序列化后拼接在消息体头部，多个事件序列化后的数据组成事件协议包集合；
事件的序列化结果包含校验码、协议包长度、事件格式标识和属性协议包集合，不同类型的属性有不同的属性值协议包格式；
所述压缩处理包括，将序列化后的事件数据进行批量打包，使用zlib库对批量打包后的数据进行压缩，压缩后的数据写入消息队列。
CN202410148834.0A 2024-02-02 2024-02-02 面向计费c++应用的分布式消息分发方法及系统 Active CN117692877B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410148834.0A CN117692877B (zh) 2024-02-02 2024-02-02 面向计费c++应用的分布式消息分发方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410148834.0A CN117692877B (zh) 2024-02-02 2024-02-02 面向计费c++应用的分布式消息分发方法及系统

Publications (2)

Publication Number Publication Date
CN117692877A true CN117692877A (zh) 2024-03-12
CN117692877B CN117692877B (zh) 2024-05-03

Family

ID=90139471

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410148834.0A Active CN117692877B (zh) 2024-02-02 2024-02-02 面向计费c++应用的分布式消息分发方法及系统

Country Status (1)

Country Link
CN (1) CN117692877B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106815338A (zh) * 2016-12-25 2017-06-09 北京中海投资管理有限公司 一种大数据的实时存储、处理和查询系统
CN110688399A (zh) * 2019-08-26 2020-01-14 远光软件股份有限公司 一种流式计算实时报表系统及方法
CN111552907A (zh) * 2020-04-29 2020-08-18 成都新致云服信息技术有限公司 消息处理方法、装置、设备和存储介质
CN117290122A (zh) * 2023-02-28 2023-12-26 北京荣大科技股份有限公司 一种基于Kafka的多环境有序性生产消费的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106815338A (zh) * 2016-12-25 2017-06-09 北京中海投资管理有限公司 一种大数据的实时存储、处理和查询系统
CN110688399A (zh) * 2019-08-26 2020-01-14 远光软件股份有限公司 一种流式计算实时报表系统及方法
CN111552907A (zh) * 2020-04-29 2020-08-18 成都新致云服信息技术有限公司 消息处理方法、装置、设备和存储介质
CN117290122A (zh) * 2023-02-28 2023-12-26 北京荣大科技股份有限公司 一种基于Kafka的多环境有序性生产消费的方法

Also Published As

Publication number Publication date
CN117692877B (zh) 2024-05-03

Similar Documents

Publication Publication Date Title
US8799906B2 (en) Processing a batched unit of work
US7502843B2 (en) Server queuing system and method
CN111784329B (zh) 业务数据的处理方法和装置、存储介质、电子装置
CN106375241B (zh) 批量数据处理方法、前端系统、主机及批量数据处理系统
CN114253748B (zh) 一种消息处理系统和消息处理方法
CN111400011B (zh) 一种实时任务调度方法、系统、设备及可读存储介质
US11995706B2 (en) Coordination process restart device and coordination process restart method
CN113687956A (zh) 消息路由分发方法、装置、计算机设备及存储介质
CN116777182B (zh) 半导体晶圆制造执行任务派工方法
CN117290122A (zh) 一种基于Kafka的多环境有序性生产消费的方法
CN112199432A (zh) 一种基于分布式的高性能数据etl装置及控制方法
CN117692877B (zh) 面向计费c++应用的分布式消息分发方法及系统
CN118193238A (zh) 一种业务信息的处理方法、装置、设备及存储介质
CN111314476A (zh) 企业间异步化的消息传输方法及系统
CN115022402B (zh) 一种基于一栈式集成技术的agent采集方法及系统
CN111431664A (zh) 基于json数据协议的派工数据包封装下达方法及装置
CN115617768A (zh) 日志管理方法、系统、电子设备及存储介质
CN110336847B (zh) 支付报文传输系统及方法
CN117742998B (zh) 一种面向计费采集数据转发的高性能队列方法及系统
CN116361016B (zh) 一种网络控制器消息处理方法、系统
CN118093147B (zh) 一种基于任务链和分治法的海量数据汇总方法及系统
CN111143280B (zh) 一种数据调度方法、系统、装置及存储介质
WO2022037293A1 (zh) 消息中间件的布局方法、装置、服务器及存储介质
US20240168828A1 (en) Adaptively optimizing function call performance
CN118733300A (zh) 一种基于事件消息的业务处理方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant