CN115396339B - 一种异常报文处理方法及装置 - Google Patents

Abstract

本申请提供一种异常报文处理方法及装置，涉及数据通讯领域，也可用于金融领域，包括：从Kafka中获取客户端发送的业务请求报文；将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎；其中，所述存储引擎包括与业务应用系统共用的内存储器及分布式数据库；若调用业务处理接口处理所述业务请求报文失败，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。本申请能够在复用业务应用系统的存储设备的情况下，利用Kafka完成对异常业务请求报文的处理。

Description

一种异常报文处理方法及装置

技术领域

本申请涉及数据通讯领域，可以用于金融领域，具体是一种异常报文处理方法及装置。

背景技术

在金融业务的支付交易场景中，不同业务系统之间通过报文进行异步通讯。传统架构中，不同业务系统之间多采用消息队列(Message Queue，简称MQ)进行点对点的消息传输，通过事务机制保障消息传输的可靠性。为了降低对该技术的依赖，可采用分布式发布订阅消息系统(也称Kafka)作为消息异步处理的中间件进行技术替代，但Kafka基于的是消息订阅消费模式，在消息传送的过程中，没有严格的事务机制，因此对于消息能且仅能被传输一次的应用场景并不适用。

业务系统中的业务应用通过Kafka获取消息后，为保证消息的可靠消费，会同步保存位点信息到远程字典服务(Remote Dictionary Server，简称Redis)中，再同步调用下游业务应用进行业务处理；如果业务处理成功，则将位点信息从Redis中移除；最后同步提交位点信息。针对长时间保存在Redis中的位点信息，通过业务应用的定时任务重新获取消息并重新发送到Kafka对应主题中进行消费。

然而，上述现有的消费方案至少存在以下问题：

第一，为了保证消息的可靠消费，业务应用将位点信息保存至Redis，需要额外引入和部署Redis组件，增加了对系统架构进行设计及维护的复杂度。

第二，目前同步保存位点信息的方式限制了消息消费的速率。

第三，消息可靠消费作为分布式架构转型过程中一种保障机制，后续会应用于越来越多的业务场景中，需要满足消息治理、便于运维及可扩展等诸多特性，目前其与业务应用深度耦合的实现方式不具有通用性，也不便于后续的扩展。

发明内容

针对现有技术中的问题，本申请提供一种异常报文处理方法及装置，能够在复用业务应用系统的存储设备的情况下，利用Kafka完成对异常业务请求报文的处理。

为解决上述技术问题，本申请提供以下技术方案：

第一方面，本申请提供一种异常报文处理方法，包括：

从Kafka中获取客户端发送的业务请求报文；

将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎；其中，所述存储引擎包括与业务应用系统共用的内存储器及分布式数据库；

若调用业务处理接口处理所述业务请求报文失败，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。

进一步地，在从Kafka中获取客户端发送的业务请求报文之前，还包括：

检测当前时刻是否为预设的报文获取时刻；

若是，检测所述Kafka中是否有未处理的报文。

进一步地，在将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎之前，还包括：

将所述业务请求报文记录至报文执行日志中；

检测所述业务请求报文对应的消息体大小是否满足预设的阈值；若是，将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎。

进一步地，调用业务处理接口处理所述业务请求报文，包括：

根据所述业务处理请求对应的业务类型调用对应的业务处理接口；

通过所述业务处理接口将所述业务请求报文发送至对应的业务处理实例进行处理；所述业务处理实例运行于所述业务应用系统中。

进一步地，所述业务处理实例为多个；所述通过所述业务处理接口将所述业务请求报文发送至对应的业务处理实例进行处理，包括：

根据预设的业务处理限流策略判断是否要将业务请求报文转发至业务处理实例进行业务处理；

若是，根据预设的业务处理负载均衡策略选择一个业务处理实例，并将所述业务请求报文发送至该业务处理实例进行处理。

进一步地，所述根据所述位点信息将所述业务请求报文重新加载至所述Kafka中，包括：

查询所述存储引擎中是否有存储时长超过预设时长的位点信息；

若有，根据所述位点信息确定需要被重新加载的所述业务请求报文；

将所述业务请求报文复制至所述Kafka中。

第二方面，本申请提供一种异常报文处理装置，包括：

报文获取单元，用于从Kafka中获取客户端发送的业务请求报文；

位点保存单元，用于将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎；其中，所述存储引擎包括与业务应用系统共用的内存储器及分布式数据库；

重新加载单元，用于若调用业务处理接口处理所述业务请求报文失败，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。

进一步地，所述的异常报文处理装置，还包括：

时刻检查单元，用于检测当前时刻是否为预设的报文获取时刻；

存在检查单元，用于当检测当前时刻为预设的报文获取时刻时，检测所述Kafka中是否有未处理的报文。

进一步地，所述的异常报文处理装置，还包括：

日志记录单元，用于将所述业务请求报文记录至报文执行日志中；

报文大小检查单元，用于检测所述业务请求报文对应的消息体大小是否满足预设的阈值；若是，将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎。

进一步地，所述重新加载单元，包括：

接口调用模块，用于根据所述业务处理请求对应的业务类型调用对应的业务处理接口；

实例处理模块，用于通过所述业务处理接口将所述业务请求报文发送至对应的业务处理实例进行处理；所述业务处理实例运行于所述业务应用系统中。

进一步地，所述业务处理实例为多个；所述实例处理模块，包括：

处理实例判断模块，用于根据预设的业务处理限流策略判断是否要将业务请求报文转发至业务处理实例进行业务处理；

处理实例选取模块，用于当有能够进行业务处理的业务处理实例时，根据预设的业务处理负载均衡策略选择一个业务处理实例，并将所述业务请求报文发送至该业务处理实例进行处理。

进一步地，所述重新加载单元，包括：

位点信息查询模块，用于查询所述存储引擎中是否有存储时长超过预设时长的位点信息；

重载报文确定模块，用于当有存储时长超过预设时长的位点信息时，根据所述位点信息确定需要被重新加载的所述业务请求报文；

报文复制模块，用于将所述业务请求报文复制至所述Kafka中。

第三方面，本申请提供一种电子设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述异常报文处理方法的步骤。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述异常报文处理方法的步骤。

第五方面，本申请提供一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现所述异常报文处理方法的步骤。

针对现有技术中的问题，本申请提供的异常报文处理方法及装置，能够保证Kafka中消息的可靠消费，使用异步保存位点信息的方式来提高消费的吞吐量；利用业务处理限流机制、负载均衡机制及熔断机制等提升了对消息消费的控制能力；使用可扩展的存储引擎保存位点信息，兼容并降低了对存储硬件的要求；增加可扩展的过滤器，实现消息的有效治理，方便应用进行灵活扩展。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例中异常报文处理方法的流程图之一；

图2为本申请实施例中异常报文处理方法的流程图之二；

图3为本申请实施例中异常报文处理方法的流程图之三；

图4为本申请实施例中处理所述业务请求报文的流程图；

图5为本申请实施例中发送至对应的业务处理实例进行处理的流程图；

图6为本申请实施例中重新加载至所述Kafka的流程图；

图7为本申请实施例中异常报文处理装置的结构图之一；

图8为本申请实施例中异常报文处理装置的结构图之二；

图9为本申请实施例中异常报文处理装置的结构图之三；

图10为本申请实施例中重新加载单元的结构图；

图11为本申请实施例中实例处理模块的结构图；

图12为本申请实施例中重新加载单元的结构图；

图13为本申请实施例中的电子设备的结构示意图；

图14为本申请实施例中异常报文处理的组件示意图；

图15为本申请实施例中异步网关结构示意图；

图16为本申请实施例中异步网关消息可靠消费处理流程示意图；

图17为本申请实施例中消费阶段流程示意图；

图18为本申请实施例中重处理阶段流程示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请提供的异常报文处理方法及装置，可用于金融领域，也可用于除金融领域之外的任意领域，本申请提供的异常报文处理方法及装置的应用领域不做限定。

本申请技术方案中对数据的获取、存储、使用及处理等均符合国家法律法规的相关规定。

一实施例中，参见图1，为了能够在复用业务应用系统的存储设备的情况下，利用Kafka完成对异常业务请求报文的处理，本申请提供一种异常报文处理方法，包括：

S101：从Kafka中获取客户端发送的业务请求报文；

S102：将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎；其中，所述存储引擎包括与业务应用系统共用的内存储器及分布式数据库；

S103：若调用业务处理接口处理所述业务请求报文失败，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。

可以理解的是，参见图16，本申请实施例中的参与方至少包括：参与机构、报文传输系统、Kafka、异步网关、存储引擎及业务应用系统。其中，参与机构可以是指与执行步骤S101至步骤S103的金融机构存在金融业务交互的其他金融机构；也就是说，参与机构可以作为客户端部署于执行步骤S101至步骤S103的金融机构之外；而报文传输系统、Kafka、异步网关、业务应用系统均可部署于执行步骤S101至步骤S103的金融机构之内。

具体地，参见图14，参与机构向报文传输系统发送业务请求报文，报文传输系统根据现有的报文路由策略，利用现有的报文传输方法将业务请求报文传输至Kafka。异步网关从Kafka中获取客户端发送的业务请求报文，再经过步骤S102及步骤S103的过程，完成对业务请求报文的处理。

需要说明的是，第一，对业务请求报文进行业务层面的处理由业务应用系统完成，具体是异步网关通过调用业务处理接口，使业务应用系统完成对业务请求报文的处理。

第二，在对Kafka中的消息(业务请求报文)进行处理时，业务请求报文对应的位点信息是被异步网关存储于存储引擎中的。

具体的，在Kafka中，消息的消费机制可以为“最多消费一次”或“至少消费一次”两种。本申请实施例基于“至少消费一次”的机制，在从Kafka获取消息后，对其位点信息的保存机制进行了优化，通过设置异步网关以及存储引擎实现了消息的可靠消费，复用了与业务应用系统原有的内存储器及分布式数据库，无需在另外部署远程字典服务(RemoteDictionary Server，简称Redis)。相当于较现有技术而言，进行了存储资源的优化复用以及组织架构的精简，提升了消息消费的速率，便于实现消息治理及业务应用层面的自定义扩展。

为了更清楚地说明本申请实施例中，异步网关对业务请求报文的处理过程，下面阐述异步网关的功能及组织架构。

该异步网关用于保障本申请实施例场景下Kafka消息的可靠消费。在Kafka“至少消费一次”的机制下，该异步网关能够在从Kafka获取消息后，完成消息的位点信息保存及消息处理。具体地，在完成位点信息保存后，该异步网关通过远程过程调用(RemoteProcedure Call，简称RPC)的方式触发下游业务应用系统进行具体的业务处理，并依据业务处理返回结果进行位点信息的提交与移除。此外，该异步网关内部设置有前置过滤器及后置过滤器，通过限流、熔断等多种技术手段提升了对消息处理的治理能力，提升组件的通用性。具体流程可以参见图14。

异步网关的组织架构参见图15所示。异步网关包括消息组件及重处理组件两个功能组件。

①消息组件

消费组件负责从Kafka中进行消息拉取，然后对消息进行异步处理，同步线程等待。待所有异步处理完成后，触发当前线程进行位点信息提交，然后进行下一消息的拉取及消费。异步处理所涉及到的子组件包括：前置过滤器、业务处理及后置过滤器。

其中，前置过滤器包括：1)日志过滤器；(其功能对应于步骤S301)2)消息去重过滤器；3)消息体大小检查过滤器；(其功能对应于步骤S302)4)可扩展的自定义过滤器。后置过滤器包括：位点信息移除过滤器及消费情况统计过滤器。各过滤器均以插件的方式部署于异步网关中，业务方可对插件进行定制化开发，并方便地注入到异步网关中使其生效。插件的部署及生效方式可以参见现有技术。

“业务处理”远程过程调用的方式触发下游业务应用系统进行具体的业务处理，调用过程中可以使用内置的熔断降级过滤器及限流过滤器等对自身及下游服务进行保护。

为保证消息的可靠消费，避免消息丢失，本申请实施例中还部署了存储引擎，用于保存位点信息，存储引擎可以扩展使用数据库、日志及内存储器等。

②重处理组件

重处理组件的主要作用是使用定时任务定时从存储引擎中查询并获取长时间存在的位点信息，然后根据该位点信息去Kafka中重新获取消息，并将消息重新发送至对应的主题队列中，保证了消息的可靠传输。其中，主题队列可以理解为Kafka中的逻辑队列，每个主题队列中均可以存储多条消息。关于重处理组件的功能参见步骤S601至S603的阐述。

从上述描述可知，本申请提供的异常报文处理方法，能够保证Kafka中消息的可靠消费，使用异步保存位点信息的方式来提高消费的吞吐量；利用业务处理限流机制、负载均衡机制及熔断机制等提升了对消息消费的控制能力；使用可扩展的存储引擎保存位点信息，兼容并降低了对存储硬件的要求；增加可扩展的过滤器，实现消息的有效治理，方便应用进行灵活扩展。

一实施例中，参见图2，在从Kafka中获取客户端发送的业务请求报文之前，还包括：

S201：检测当前时刻是否为预设的报文获取时刻；

S202：若是，检测所述Kafka中是否有未处理的报文。

可以理解的是，在本申请实施例中，异步网关可以定时/定期的方式从Kafka中获取客户端发送的业务请求报文。例如，假设规定每个五分钟进行一次获取操作，假设认为上次进行获取的时刻是第0分钟，那么本次进行获取的时刻应该是第5分钟时，由此，第1分钟、第2分钟、第3分钟及第4分钟均不是报文获取时刻。

从上述描述可知，本申请提供的异常报文处理方法，能够在预设的时刻从Kafka中获取客户端发送的业务请求报文。

一实施例中，参见图3，在将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎之前，还包括：

S301：将所述业务请求报文记录至报文执行日志中；

S302：检测所述业务请求报文对应的消息体大小是否满足预设的阈值；若是，将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎。

可以理解的是，在本申请实施例中，参见图15，由于异步网关中设置有前置过滤器，该前置过滤器至少能够完成如下操作：

①将所述业务请求报文记录至报文执行日志中

②检测所述业务请求报文对应的消息体大小是否满足预设的阈值；具体地，若业务请求报文对应的消息体过大，可以将业务请求报文记录到单独的日志中，后续人工分析后再行处理；

③进行位点信息去重；具体地，每条业务请求报文由主题及位点信息唯一确定，也就是说，主题+位点信息可以作为业务请求报文的主键(标识)；因此，通过查询主键(标识)可以进行位点信息去重。比如，异步网关从kafka消费消息后，还没有提交offset进程就挂掉了，这样重新启动后会从头开始消费，会有大量的重复报文。

还需说明的是，前置过滤器支持可扩展的自定义过滤器。

从上述描述可知，本申请提供的异常报文处理方法，能够利用前置过滤器对业务处理报文进行业务处理前的检查。

一实施例中，参见图4，调用业务处理接口处理所述业务请求报文，包括：

S401：根据所述业务处理请求对应的业务类型调用对应的业务处理接口；

可以理解的是，金融业务类型繁多，各业务类型可能对应不同的业务处理接口，因此，本申请实施例可以根据业务处理请求对应的业务类型调用对应的业务处理接口。

S402：通过所述业务处理接口将所述业务请求报文发送至对应的业务处理实例进行处理；所述业务处理实例运行于所述业务应用系统中。

可以理解的是，前文已经阐述，异步网关是以远程过程调用的方式使业务应用系统处理业务请求报文的。具体地，是调用业务处理接口处理业务请求报文。

需要说明的是，参见图5，所述业务处理实例可以为多个；步骤S402，包括：根据预设的业务处理限流策略判断是否要将业务请求报文转发至业务处理实例进行业务处理(S501)；若是，根据预设的业务处理负载均衡策略选择一个业务处理实例，并将所述业务请求报文发送至该业务处理实例进行处理(S502)。

其中，执行S501的目的在于判断当前是否有能够进行业务处理的实例；所谓实例可以是指一台能够进行业务处理的服务器上运行的程序实例。如果此时所有业务处理实例均处于忙碌状态，则没有能够进行业务处理实例。在这种情况下，异步网关可以对业务请求报文对应的位点信息进行异常处理，例如，将业务请求报文放入异常处理队列，由异常处理分支进行旁路处理，如旁路处理多次仍不成功，则触发告警、将业务请求报文记录入日志或数据库，由人工介入进行处理。

执行S502的目的在于使各业务处理实例处理与其自身处理能力(如吞吐量)匹配的业务，以免发生过载，造成业务处理效率降低。具体实施时，可以根据业务处理限流策略进行更精细的流量控制，例如，业务处理限流策略可以设置各业务处理实例可以承载多少业务流量，超过限制，则不再向对应的业务处理实例上发送业务流量。

在业务处理请求处理完成后，异步网关中设置的后置过滤器还能完成如下操作：

①利用位点信息移除过滤器，从存储引擎中移除业务请求报文对应的位点信息；需要说明的是，参见步骤S103，若调用业务处理接口处理业务请求报文失败(可能是调用失败，可能是处理失败)，位点信息会保留于存储引擎中，等到异步网关在执行步骤S601至步骤S603时，进行进一步的处理。

②利用消费情况统计过滤器，对消息处理效率等进行统计。

从上述描述可知，本申请提供的异常报文处理方法，能够调用业务处理接口处理所述业务请求报文。

一实施例中，参见图6，所述根据所述位点信息将所述业务请求报文重新加载至所述Kafka中，包括：

S601：查询所述存储引擎中是否有存储时长超过预设时长的位点信息；

S602：若有，根据所述位点信息确定需要被重新加载的所述业务请求报文；

S603：将所述业务请求报文复制至所述Kafka中。

可以理解的是，由于在调用业务处理接口处理业务请求报文失败的情况下(可能是调用失败，可能是处理失败)，位点信息会保留于存储引擎中，因此，通过查询存储引擎中是否有存储时长超过预设时长的位点信息可以判断出处理失败的业务请求报文。异步网关会将这种处理失败的业务请求报文重新加载至Kafka中，以重新执行步骤S101至步骤S103的过程，尝试重新对其进行处理。关于S603，需要说明的是，由于被处理失败的业务请求报文在此前曾经被尝试处理过，若想要再重新对其进行处理，需要将其进行复制至Kafka队列数据结构的队尾处或者复制至Kafka错误队列，由异常处理分支进行处理。

比如，某个业务请求报文在调用下游业务处理实例处理接口因为网络抖动、服务器忙碌等原因连续报错的时候，比如连续重试3次还是报错，则该业务请求报文可能实际并没有完成处理，需要将超时或未响应的业务请求报文再次触发重新处理流程，所以需要再次将消息放入kafka。

从上述描述可知，本申请提供的异常报文处理方法，能够根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。

为了更好地说明本申请提供的方法，下面举一实例，参见图16。

第一，消费阶段(参见图17)

①数据拉取

调用Kafka客户端接口，使用拉的方式同步从Kafka服务端拉取数据，如果两秒内有数据则直接返回并进行下一步异步消费；否则一直等待直至两秒，返回空数据集合，然后重复进行数据拉取操作。

②异步消费

针对已经拉取到的数据，将每一条数据的处理都放到线程池中处理。

具体地，首先，利用前置过滤器对消息进行处理。

然后，利用存储接口将位点信息保存于存储引擎中。存储接口以使用文件系统进行存储为例，存储结构为键值结构：

key为：自定义前缀-主题分区-位点-主题；

value为：时间戳。

位点信息存储成功后，进行调用下游服务进行业务处理。业务处理完成后，移除位点信息；如果执行失败，则不做任何处理，即处理失败的位点信息会长时间保存在存储引擎中，最后通过定时任务进行处理。

最后，利用后置过滤器对消息进行处理。

③位点提交

待所有数据在线程池中处理完成后，同步进行位点提交，并继续拉取消息进行可靠消费。

第二，重处理阶段(参见图18)

保存在存储引擎中的位点信息可以分为两类：正在消费消息的位点及消费失败的位点，其中长时间保存的位点即为消费失败的位点。

首先，异步网关从存储引擎中获取消费失败的位点信息，默认获取十分钟前创建的位点信息；然后根据位点信息去Kafka中获取其对应的(原)消息，并将该消息进行复制后重新发送到Kafka队列数据结构的主题中；最后将位点信息从存储引擎中删除。

基于同一发明构思，本申请实施例还提供了一种异常报文处理装置，可以用于实现上述实施例所描述的方法，如下面的实施例所述。由于异常报文处理装置解决问题的原理与异常报文处理方法相似，因此异常报文处理装置的实施可以参见基于软件性能基准确定方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

一实施例中，参见图7，为了能够在复用业务应用系统的存储设备的情况下，利用Kafka完成对异常业务请求报文的处理，本申请提供一种异常报文处理装置，包括：报文获取单元701、位点保存单元702及重新加载单元703。

报文获取单元701，用于从Kafka中获取客户端发送的业务请求报文；

位点保存单元702，用于将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎；其中，所述存储引擎包括与业务应用系统共用的内存储器及分布式数据库；

重新加载单元703，用于若调用业务处理接口处理所述业务请求报文失败，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。

一实施例中，参见图8，所述的异常报文处理装置，还包括：时刻检查单元801及存在检查单元802。

时刻检查单元801，用于检测当前时刻是否为预设的报文获取时刻；

存在检查单元802，用于当检测当前时刻为预设的报文获取时刻时，检测所述Kafka中是否有未处理的报文。

一实施例中，参见图9，所述的异常报文处理装置，还包括：日志记录单元901及报文大小检查单元902。

日志记录单元901，用于将所述业务请求报文记录至报文执行日志中；

报文大小检查单元902，用于检测所述业务请求报文对应的消息体大小是否满足预设的阈值；若是，将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎。

一实施例中，参见图10，所述重新加载单元703，包括：接口调用模块1001及实例处理模块1002。

接口调用模块1001，用于根据所述业务处理请求对应的业务类型调用对应的业务处理接口；

实例处理模块1002，用于通过所述业务处理接口将所述业务请求报文发送至对应的业务处理实例进行处理；所述业务处理实例运行于所述业务应用系统中。

一实施例中，参见图11，所述业务处理实例为多个；所述实例处理模块1002，包括：处理实例判断模块1101及处理实例选取模块1102。

处理实例判断模块1101，用于根据预设的业务处理限流策略判断是否要将业务请求报文转发至业务处理实例进行业务处理；

处理实例选取模块1102，用于当有能够进行业务处理的业务处理实例时，根据预设的业务处理负载均衡策略选择一个业务处理实例，并将所述业务请求报文发送至该业务处理实例进行处理。

一实施例中，参见图12，所述重新加载单元703，包括：

位点信息查询模块1201，用于查询所述存储引擎中是否有存储时长超过预设时长的位点信息；

重载报文确定模块1202，用于当有存储时长超过预设时长的位点信息时，根据所述位点信息确定需要被重新加载的所述业务请求报文；

报文复制模块1203，用于将所述业务请求报文复制至所述Kafka中。

从硬件层面来说，为了能够在复用业务应用系统的存储设备的情况下，利用Kafka完成对异常业务请求报文的处理，本申请提供一种用于实现所述异常报文处理方法中的全部或部分内容的电子设备的实施例，所述电子设备具体包含有如下内容：

处理器(Processor)、存储器(Memory)、通讯接口(Communications Interface)和总线；其中，所述处理器、存储器、通讯接口通过所述总线完成相互间的通讯；所述通讯接口用于实现所述异常报文处理装置与核心业务系统、用户终端以及相关数据库等相关设备之间的信息传输；该逻辑控制器可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该逻辑控制器可以参照实施例中的异常报文处理方法的实施例，以及异常报文处理装置的实施例进行实施，其内容被合并于此，重复之处不再赘述。

可以理解的是，所述用户终端可以包括智能手机、平板电子设备、网络机顶盒、便携式计算机、台式电脑、个人数字助理(PDA)、车载设备、智能穿戴设备等。其中，所述智能穿戴设备可以包括智能眼镜、智能手表、智能手环等。

在实际应用中，异常报文处理方法的部分可以在如上述内容所述的电子设备侧执行，也可以所有的操作都在所述客户端设备中完成。具体可以根据所述客户端设备的处理能力，以及用户使用场景的限制等进行选择。本申请对此不作限定。若所有的操作都在所述客户端设备中完成，所述客户端设备还可以包括处理器。

上述的客户端设备可以具有通讯模块(即通讯单元)，可以与远程的服务器进行通讯连接，实现与所述服务器的数据传输。所述服务器可以包括任务调度中心一侧的服务器，其他的实施场景中也可以包括中间平台的服务器，例如与任务调度中心服务器有通讯链接的第三方服务器平台的服务器。所述的服务器可以包括单台计算机设备，也可以包括多个服务器组成的服务器集群，或者分布式装置的服务器结构。

图13为本申请实施例的电子设备9600的系统构成的示意框图。如图13所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图13是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

一实施例中，异常报文处理方法功能可以被集成到中央处理器9100中。其中，中央处理器9100可以被配置为进行如下控制：

S101：从Kafka中获取客户端发送的业务请求报文；

S102：将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎；其中，所述存储引擎包括与业务应用系统共用的内存储器及分布式数据库；

S103：若调用业务处理接口处理所述业务请求报文失败，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。

从上述描述可知，本申请提供的异常报文处理方法，能够保证Kafka中消息的可靠消费，使用异步保存位点信息的方式来提高消费的吞吐量；利用业务处理限流机制、负载均衡机制及熔断机制等提升了对消息消费的控制能力；使用可扩展的存储引擎保存位点信息，兼容并降低了对存储硬件的要求；增加可扩展的过滤器，实现消息的有效治理，方便应用进行灵活扩展。

在另一个实施方式中，异常报文处理装置可以与中央处理器9100分开配置，例如可以将数据复合传输装置异常报文处理装置配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现异常报文处理方法的功能。

如图13所示，该电子设备9600还可以包括：通讯模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图13中所示的所有部件；此外，电子设备9600还可以包括图13中没有示出的部件，可以参考现有技术。

如图13所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通讯功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通讯模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通讯模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通讯终端的情况相同。

基于不同的通讯技术，在同一电子设备中，可以设置有多个通讯模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通讯模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

本申请的实施例还提供能够实现上述实施例中的执行主体为服务器或客户端的异常报文处理方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的执行主体为服务器或客户端的异常报文处理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

S101：从Kafka中获取客户端发送的业务请求报文；

S102：将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎；其中，所述存储引擎包括与业务应用系统共用的内存储器及分布式数据库；

S103：若调用业务处理接口处理所述业务请求报文失败，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。

从上述描述可知，本申请提供的异常报文处理方法，能够保证Kafka中消息的可靠消费，使用异步保存位点信息的方式来提高消费的吞吐量；利用业务处理限流机制、负载均衡机制及熔断机制等提升了对消息消费的控制能力；使用可扩展的存储引擎保存位点信息，兼容并降低了对存储硬件的要求；增加可扩展的过滤器，实现消息的有效治理，方便应用进行灵活扩展。

本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (15)

1.一种异常报文处理方法，其特征在于，包括：

从Kafka中获取客户端发送的业务请求报文；

将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎；其中，所述存储引擎包括与业务应用系统共用的内存储器及分布式数据库；

若调用业务处理接口处理所述业务请求报文失败，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。

2.根据权利要求1所述的异常报文处理方法，其特征在于，在从Kafka中获取客户端发送的业务请求报文之前，还包括：

检测当前时刻是否为预设的报文获取时刻；

若是，检测所述Kafka中是否有未处理的报文。

3.根据权利要求1所述的异常报文处理方法，其特征在于，在将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎之前，还包括：

将所述业务请求报文记录至报文执行日志中；

检测所述业务请求报文对应的消息体大小是否满足预设的阈值；若是，将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎。

4.根据权利要求1所述的异常报文处理方法，其特征在于，调用业务处理接口处理所述业务请求报文，包括：

根据所述业务处理请求对应的业务类型调用对应的业务处理接口；

通过所述业务处理接口将所述业务请求报文发送至对应的业务处理实例进行处理；所述业务处理实例运行于所述业务应用系统中。

5.根据权利要求4所述的异常报文处理方法，其特征在于，所述业务处理实例为多个；所述通过所述业务处理接口将所述业务请求报文发送至对应的业务处理实例进行处理，包括：

根据预设的业务处理限流策略判断是否要将业务请求报文转发至业务处理实例进行业务处理；

若是，根据预设的业务处理负载均衡策略选择一个业务处理实例，并将所述业务请求报文发送至该业务处理实例进行处理。

6.根据权利要求1所述的异常报文处理方法，其特征在于，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中，包括：

查询所述存储引擎中是否有存储时长超过预设时长的位点信息；

若有，根据所述位点信息确定需要被重新加载的所述业务请求报文；

将所述业务请求报文复制至所述Kafka中。

7.一种异常报文处理装置，其特征在于，包括：

报文获取单元，用于从Kafka中获取客户端发送的业务请求报文；

位点保存单元，用于将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎；其中，所述存储引擎包括与业务应用系统共用的内存储器及分布式数据库；

重新加载单元，用于若调用业务处理接口处理所述业务请求报文失败，根据所述位点信息将所述业务请求报文重新加载至所述Kafka中。

8.根据权利要求7所述的异常报文处理装置，其特征在于，还包括：

时刻检查单元，用于检测当前时刻是否为预设的报文获取时刻；

存在检查单元，用于当检测当前时刻为预设的报文获取时刻时，检测所述Kafka中是否有未处理的报文。

9.根据权利要求7所述的异常报文处理装置，其特征在于，还包括：

日志记录单元，用于将所述业务请求报文记录至报文执行日志中；

报文大小检查单元，用于检测所述业务请求报文对应的消息体大小是否满足预设的阈值；若是，将所述业务请求报文在所述Kafka中的位点信息保存至存储引擎。

10.根据权利要求7所述的异常报文处理装置，其特征在于，所述重新加载单元，包括：

接口调用模块，用于根据所述业务处理请求对应的业务类型调用对应的业务处理接口；

实例处理模块，用于通过所述业务处理接口将所述业务请求报文发送至对应的业务处理实例进行处理；所述业务处理实例运行于所述业务应用系统中。

11.根据权利要求10所述的异常报文处理装置，其特征在于，所述业务处理实例为多个；所述实例处理模块，包括：

处理实例判断模块，用于根据预设的业务处理限流策略判断是否要将业务请求报文转发至业务处理实例进行业务处理；

处理实例选取模块，用于当有能够进行业务处理的业务处理实例时，根据预设的业务处理负载均衡策略选择一个业务处理实例，并将所述业务请求报文发送至该业务处理实例进行处理。

12.根据权利要求7所述的异常报文处理装置，其特征在于，所述重新加载单元，包括：

位点信息查询模块，用于查询所述存储引擎中是否有存储时长超过预设时长的位点信息；

重载报文确定模块，用于当有存储时长超过预设时长的位点信息时，根据所述位点信息确定需要被重新加载的所述业务请求报文；

报文复制模块，用于将所述业务请求报文复制至所述Kafka中。

13.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至6任一项所述的异常报文处理方法的步骤。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至6任一项所述的异常报文处理方法的步骤。

15.一种计算机程序产品，包括计算机程序/指令，其特征在于，该计算机程序/指令被处理器执行时实现权利要求1至6任一项所述的异常报文处理方法的步骤。