CN116643849A - 业务逻辑处理方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种业务逻辑处理方法、装置、计算机设备、存储介质和计算机程序产品。所述方法通过设置关注事件，而后基于事件管理线程通过事件来驱动业务逻辑，同时将业务逻辑依赖的对象属性需求抽离出来，写入至属性需求线程从而实现属性信息的同步处理，本申请可以实现业务逻辑与属性信息的双重解耦，能有效达到服务拆分的目的。

Description

业务逻辑处理方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种业务逻辑处理方法、装置、计算机设备、存储介质和计算机程序产品。

背景技术

随着计算机技术的发展，基于计算机的业务处理也越来越重要。而在基于计算机业务的逻辑处理中，普遍存在着耦合的现象。耦合表示两个子系统(或类)之间的关联程度，当一个子系统(或类)发生变化时对另一个子系统(或类)的影响很小，则称它们是松散耦合的；反之，如果变化的影响很大时，则称它们是紧密耦合的。耦合的强弱取决于模块间接间的复杂性、引用模块的位置和数据的传送方式等。在设计时应尽量使模块间的耦合度小，模块间的耦合度直接影响系统的可理解性、可测试性、可靠性和可维护性。

在部分技术场景，如传统技术的游戏业务逻辑内，耦合现象非常严重，游戏内包含有大量的逻辑耦合和上下文信息的耦合，无法实现服务拆分。

发明内容

基于此，有必要针对上述技术问题，提供一种能够的有效完成业务逻辑解耦，实现服务拆分的业务逻辑处理方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

第一方面，本申请提供了一种业务逻辑处理方法。所述方法包括：

响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；

通过所述从属业务服务进程，获取所述目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；

将所述关注事件处理集合写入至所述主业务服务进程中事件管理线程，并将所述属性需求集合写入至所述主业务服务进程中属性管理线程；

当通过所述事件管理线程识别到所述关注事件被触发时，基于所述被触发的所述关注事件，在所述从属业务服务进程中执行所述关注时间对应的预定义处理逻辑；

当通过所述属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在所述从属业务服务进程中执行所述属性子集信息对应的属性信息同步处理。

第二方面，本申请还提供了一种业务逻辑处理装置。所述装置包括：

登录响应模块，用于响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；

集合构建模块，用于通过所述从属业务服务进程，获取所述目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；

事件写入模块，用于将所述关注事件处理集合写入至所述主业务服务进程中事件管理线程，并将所述属性需求集合写入至所述主业务服务进程中属性管理线程；

事件驱动模块，用于当通过所述事件管理线程识别到所述关注事件被触发时，基于所述被触发的所述关注事件，在所述从属业务服务进程中执行所述关注时间对应的预定义处理逻辑；

属性同步模块，用于当通过所述属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在所述从属业务服务进程中执行所述属性子集信息对应的属性信息同步处理。

第三方面，本申请还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；

通过所述从属业务服务进程，获取所述目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；

将所述关注事件处理集合写入至所述主业务服务进程中事件管理线程，并将所述属性需求集合写入至所述主业务服务进程中属性管理线程；

当通过所述事件管理线程识别到所述关注事件被触发时，基于所述被触发的所述关注事件，在所述从属业务服务进程中执行所述关注时间对应的预定义处理逻辑；

当通过所述属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在所述从属业务服务进程中执行所述属性子集信息对应的属性信息同步处理。

第四方面，本申请还提供了一种计算机可读存储介质。所述计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；

通过所述从属业务服务进程，获取所述目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；

将所述关注事件处理集合写入至所述主业务服务进程中事件管理线程，并将所述属性需求集合写入至所述主业务服务进程中属性管理线程；

当通过所述事件管理线程识别到所述关注事件被触发时，基于所述被触发的所述关注事件，在所述从属业务服务进程中执行所述关注时间对应的预定义处理逻辑；

当通过所述属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在所述从属业务服务进程中执行所述属性子集信息对应的属性信息同步处理。

第五方面，本申请还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：

响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；

通过所述从属业务服务进程，获取所述目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；

将所述关注事件处理集合写入至所述主业务服务进程中事件管理线程，并将所述属性需求集合写入至所述主业务服务进程中属性管理线程；

当通过所述事件管理线程识别到所述关注事件被触发时，基于所述被触发的所述关注事件，在所述从属业务服务进程中执行所述关注时间对应的预定义处理逻辑；

当通过所述属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在所述从属业务服务进程中执行所述属性子集信息对应的属性信息同步处理。

上述业务逻辑处理方法、装置、计算机设备、存储介质和计算机程序产品，通过响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；通过从属业务服务进程，获取目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；将关注事件处理集合写入至主业务服务进程中事件管理线程，并将属性需求集合写入至主业务服务进程中属性管理线程；当通过事件管理线程识别到关注事件被触发时，基于被触发的关注事件，在从属业务服务进程中执行关注时间对应的预定义处理逻辑；当通过属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在从属业务服务进程中执行属性子集信息对应的属性信息同步处。本申请通过设置关注事件，而后基于事件管理线程通过事件来驱动业务逻辑，同时将业务逻辑依赖的对象属性需求抽离出来，写入至属性需求线程从而实现属性信息的同步处理，本申请可以实现业务逻辑与属性信息的双重解耦，能有效达到服务拆分的目的。

附图说明

图1为一个实施例中业务逻辑处理方法的应用环境图；

图2为一个实施例中业务逻辑处理方法的流程示意图；

图3为一个实施例中基于事件判定属性信息来识别判定关注事件步骤的流程示意图；

图4为一个实施例中将事件资源更新数据写入预设业务资源数据库步骤的流程示意图；

图5为一个实施例中跨进程事件处理步骤的流程示意图；

图6为一个实施例中事件补发处理步骤的流程示意图；

图7为一个实施例中现有技术中未执行事件补发处理步骤时的流程示意图；

图8为一个实施例中执行事件补发处理步骤时的流程示意图；

图9为一个实施例中游戏业务逻辑耦合情况的示意图；

图10为一个实施例中业务逻辑处理的解耦思路的示意图；

图11为一个实施例中事件驱动&&属性同步的原理示意图；

图12为一个实施例中令牌桶限流算法的原理示意图；

图13为一个实施例中业务逻辑处理装置的结构框图；

图14为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请实施例提供的业务逻辑处理方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信。数据存储系统可以存储服务器104需要处理的数据。数据存储系统可以集成在服务器104上，也可以放在云上或其他网络服务器上。目标对象可以在终端102上处理业务，而服务器104则用于为目标对象提供业务处理的环境，当服务器104识别到为目标对象提供的业务服务进入登录状态时，可以通过响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；通过从属业务服务进程，获取目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；将关注事件处理集合写入至主业务服务进程中事件管理线程，并将属性需求集合写入至主业务服务进程中属性管理线程；当通过事件管理线程识别到关注事件被触发时，基于被触发的关注事件，在从属业务服务进程中执行关注时间对应的预定义处理逻辑；当通过属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在从属业务服务进程中执行属性子集信息对应的属性信息同步处理。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备和便携式可穿戴设备，物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在本文中，需要理解的是，所涉及的术语：

GameSvr：实现核心游戏逻辑的服务进程。

PvpSvr：实现特定场景玩法的服务进程。

TaskSvr：实现游戏任务系统的服务进程。

DB：存储游戏数据的数据库服务。

在一个实施例中，如图2所示，提供了一种业务逻辑处理方法，以该方法应用于图1中的服务器104为例进行说明，包括以下步骤：

步骤201，响应目标对象登录事件，确定主业务服务进程和从属业务服务进程。

步骤203，通过从属业务服务进程，获取目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合。

其中，目标对象具体是指通过由服务器104所提供业务系统进行业务处理的用户，服务器104可以通过目标对象方的终端102，远程为目标对象提供业务系统服务，当目标对象通过终端登录业务系统，进行业务处理时，服务器即可识别到为目标对象提供的业务服务进入登录状态。主业务服务进程是指用于实现业务核心逻辑的进程。从属业务服务进程具体是指在服务器中，用于实现各类附属业务的进程。在其中一个实施例中，主业务服务进程具体是指实现核心游戏逻辑的服务进程GameSvr。而从属业务服务进程具体包括实现特定场景玩法的服务进程PvpSvr以及实现游戏任务系统的服务进程TaskSvr等多种根据游戏逻辑需要来设置的服务进程，从属业务服务进程可以与主业务服务进程进行交互。在现有的业务逻辑处理中，从属业务服务进程所实现的功能可能会与主业务逻辑高度耦合，此时很难将其实现的功能以模块的形式独立出来，而本申请的目的就在于实现从属业务服务进程与主业务服务进程解耦，从而实现服务拆分。本实施例中，通过从属业务服务进程来实现业务逻辑的处理只是以一个服务进程进行举例说明，在实际应用中，可以根据业务的需要，可以在服务器104中同时开启多个不同的从属业务服务进程来与实现主业务服务进程的交互，从而实现本申请的业务逻辑处理。目标对象对应的关注事件则具体与从属业务服务进程密切对应，服务器104可以通过关注事件的变化，来触发业务逻辑。关注事件处理集合即为基于关注事件所构建的集合，通过集合可以实现针对目标对象的事件管理。如在其中一个实施例中，从属业务服务进程用于实现游戏中的任务玩法，此时目标对象对应的关注事件即为目标对象正在执行的任务所绑定的事件，而关注事件处理集合则是目标对象正在执行的任务所绑定的事件条件。同理，对象属性需求为实现业务逻辑时，所需要的目标对象的属性，将所有的属性需求综合起来，即可构建属性需求集合。当从属业务服务进程用于实现游戏中的任务玩法，属性需求集合即为任务系统中玩家需要使用的属性需求集合。

具体地，本申请具体用于实现业务逻辑中，主业务服务进程和从属业务服务进程的解耦。因此，当识别到为目标对象提供的业务服务进入登录状态时，即可确定需要为目标对象对应的业务服务，并进行业务逻辑的处理，此时，针对每一个服务进程，都可以以事件来进行驱动。这里以确定的从属业务服务进程为例说明，首先通过从属业务服务进程来收集为目标对象提供业务服务过程中，目标对象需要关注的事件以及相应的属性需求，从而构建得到关注事件处理集合以及属性需求集合。在其中一个实施例中，从属业务服务进程具体为实现游戏任务系统的服务进程TaskSvr，此时当目标对象登录游戏后，TaskSvr会收集任务系统中玩家需要关注的事件处理集合(即正在执行的任务所绑定的事件条件)，将收集到的事件处理集合发送给实现核心游戏逻辑的服务进程GameSvr，从而开始游戏业务逻辑的处理。

步骤205，将关注事件处理集合写入至主业务服务进程中事件管理线程，并将属性需求集合写入至主业务服务进程中属性管理线程。

其中，事件管理线程是指在主业务服务进程中，用于进行事件管理，实现事件驱动的线程。而属性管理线程是指在主业务服务进程中，用于进行属性管理，实现属性同步的线程。

具体地，从属业务服务进程可以在构建出关注事件处理集合以及属性需求集合后，将这些数据发送到主业务服务进程中，而后主业务服务进程会将关注事件处理集合注册到目标对象的事件管理线程，从而在主业务服务进程中基于事件管理线程来实现事件驱动的管理。同时，主业务服务进程会将属性需求集合注册至目标对象的属性管理线程，从而在主业务服务进程中基于的属性管理线程来实现属性同步的管理。

步骤207，当通过事件管理线程识别到关注事件被触发时，基于被触发的关注事件，在从属业务服务进程中执行关注时间对应的预定义处理逻辑。

步骤209，当通过属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在从属业务服务进程中执行属性子集信息对应的属性信息同步处理。

其中，预定义处理逻辑具体是指根据从属业务服务进程的预先设置的操作，如在一个实施例中，从属业务服务进程为实现游戏任务系统的服务进程，则此时的预定义处理逻辑可以包括改变任务状态。

具体地，目标对象在终端102上进行业务处理时，可以在处理过程中触发关注事件，而主业务服务进程则可以通过事件管理线程来识别到目标对象触发关注事件的操作。比如在目标对象进行游戏内任务玩法的游玩时，当目标对象达成任务完成条件时，目标对象可以通过点击在游戏界面触发任务提交操作，而后主业务服务进程可以识别到目标对象的任务提交操作，而后将事件转发给到从属业务服务进程，从而在从属业务服务进程完成任务触发后的业务逻辑处理操作。在其中一个实施例中，在将事件转发给到从属业务服务进程前，主业务服务进程还可以执行一次事件处理逻辑，来进行事件过滤，只有过滤后的有用事件才会转发至从属业务服务进程内，如可以通过属性管理线程判断用户是否达成任务条件，只有达成任务条件后，主业务服务进程才会将事件转发给到从属业务服务进程。同时，服务器104还可以实现属性信息同步处理，当目标对象在游玩游戏时，属性管理线程内的属性会根据玩家的游玩进程发生改变，而每当属性管理线程内的部分属性发生变更时，主业务服务进程都会将发生变更的这部分信息同步给从属业务服务进程。从而在从属业务服务进程将具备主业务服务进程属性全集中的一部分属性集合。属性全集的信息会很多，而从属业务服务进程需要的属性子集信息是比较少的，从而减少了不必要的网络消耗。

上述业务逻辑处理方法，通过响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；通过从属业务服务进程，获取目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；将关注事件处理集合写入至主业务服务进程中事件管理线程，并将属性需求集合写入至主业务服务进程中属性管理线程；当通过事件管理线程识别到关注事件被触发时，基于被触发的关注事件，在从属业务服务进程中执行关注时间对应的预定义处理逻辑；当通过属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在从属业务服务进程中执行属性子集信息对应的属性信息同步处。。本申请通过设置关注事件，而后基于事件管理线程通过事件来驱动业务逻辑，同时将业务逻辑依赖的对象属性需求抽离出来，写入至属性需求线程从而实现属性信息的同步处理，本申请可以实现业务逻辑与属性信息的双重解耦，能有效达到服务拆分的目的。

在一个实施例中，如图3所示，步骤205包括：

步骤302，当通过事件管理线程识别到关注事件被触发时，从事件管理线程读取目标对象对应的事件判定属性信息。

步骤304，当基于事件判定属性信息以及预设事件触发处理逻辑判定关注事件为有用事件时，基于被触发的关注事件，在从属业务服务进程中执行关注事件对应的预定义处理逻辑。

其中，事件判定属性信息用于进行事件判定，服务器104中主业务服务进程可以通过事件判定属性信息进行一次事件处理逻辑的判定，确定当前被触发的关注事件是否需要处理，从而过滤掉不需要进行处理的无用事件。有用事件与无用事件相对，有用事件是指可用于在从属业务服务进程中执行预定义处理逻辑的事件，无用事件则是指不可用于在从属业务服务进程中执行预定义处理逻辑的事件。如对于游戏中的任务玩法，如果目标对象已经达成了任务完成的条件，那么用户触发的任务完成操作就是一个有用事件，而目标对象未达成任务完成的条件，那么用户触发的任务完成操作就是一个无用事件。

具体地，为了保证只有有用事件才会被推送至从属业务服务进程，保证业务逻辑处理的准确性以及及时性。服务器104可以在事件转发前添加对应的事件判定处理逻辑，当通过事件管理线程识别到关注事件被触发时，不会直接将事件发送至从属业务服务进程，而是先确定这个被触发的事件是否属于有用事件，只有有用事件才会被转发至从属业务服务进程来驱动对应的游戏业务处理及。而在进行判定时，具体可以通过目标对象所对应的属性信息来实现判定，因此，在目标对象触发关注事件后，主业务服务进程可以从属性管理线程读取目标对象对应的事件判定属性信息。基于事件判定属性信息判定被触发的关注事件的类型，只有当关注事件被判定为有用事件时，主业务服务进程才会将该事件转发至从属业务服务进程，而未通过判定时，该事件会被直接抛弃。本实施例中，通过读取事件判定属性信息来对被触发的关注事件进行判定，可以在事件驱动转发前，识别出用户触发的事件是否有用，从而避免将无用事件转发至从属业务服务进程，保证游戏业务逻辑的处理效率。

在一个实施例中，步骤302包括：当通过事件管理线程识别到关注事件被触发时，基于令牌桶限流算法从属性管理线程读取目标对象对应的事件判定属性信息。

其中，令牌桶算法是比较常见的限流算法之一，大概包括如下流程：1)所有的请求在处理之前都需要拿到一个可用的令牌才会被处理；2)根据限流大小，设置按照一定的速率往桶里添加令牌；3)桶设置最大的放置令牌限制，当桶满时、新添加的令牌就被丢弃或者拒绝；4)请求达到后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除；5)令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流。比如在游戏场景中，由于游戏场景会瞬时产生大量事件，但只要不持续产生事件，则一定时间段内的总体事件量可能并不多，也没必要开启过滤。而其他的限流算法(计数器、漏桶算法)并不满足这个特性，因此本申请采用令牌桶限流来进行事件过滤开启时机的优化。

具体地，由于本申请采用了事件驱动的方式来进行业务逻辑处理，而事件与消息最大的区别在于事件的发布订阅能力，除了通过事件驱动进行解耦外，还能有效过滤无用事件，减少网络异步开销。由于任务不同阶段关心的事件有所不同，而且有条件判定逻辑，当事件量(瞬时)比较大时，可以开启更细粒度的条件前置过滤逻辑，不满足条件的事件不用发给从属业务服务进程，而事件过滤开启时机优化具体可以通过令牌桶限流来实现，只有事件流量较大，令牌桶中令牌都被用完时，才会开启限流，从属性管理线程读取目标对象对应的事件判定属性信息来过滤掉无用事件。本实施例中，通过令牌桶限流来实现事件过滤开启时机优化，可以有效保证事件流量较大时的事件处理效率。

在其中一个实施例中，步骤205包括：当通过事件管理线程识别到关注事件被触发时，基于被触发的关注事件，在从属业务服务进程中通过跨进程事件处理执行关注事件对应的预定义处理逻辑。

其中，跨进程事件处理是指一种特殊的事件处理逻辑，它允许主业务服务进程在收到事件的瞬间就完成了事件处理逻辑，再收到后续事件时就可以立即处理了，而不需要等待事件。

具体地，在目前的业务逻辑处理中，主业务服务进程一般是通过阻塞异步模型来实现与多个不同服务进程的事件交互处理。假如游戏中包含有三个不同的进程Client、DS以及PvpSvr，当这些进程都激活时，当这些进程各自在同时产生了一个事件发送给主业务服务进程进行事件处理，且主业务服务进程自己也产生了一个事件需要处理，Client的事件1最先到，如果是阻塞异步模型，主业务服务进程处理事件1时需要一定时间，所以DS的事件2到来后只能先到事件队列里排队，等事件1处理完后才能处理事件2，随着未处理事件的不断增加，事件队列中会缓存很多事件，一旦主业务服务进程异常就有可能导致事件队列中的事件全部丢失。而如果采用不阻塞立即处理的跨进程事件处理模型，则主业务服务进程可以在收到事件1的瞬间直接就完成了事件处理逻辑，再收到事件2时就可以立即处理了，不需要等待，也不需要有事件队列了。本实施例中，通过跨进程事件处理的处理方式来进行不同的服务进程的事件处理，可以有效避免因核心逻辑的服务进程异常而导致的事件阻塞，提高业务逻辑的处理效率。

在其中一个实施例中，如图4所示，步骤205包括：

步骤401，通过在从属业务服务进程中通过跨进程事件处理执行关注事件对应的预定义处理逻辑，获取事件资源更新数据。

步骤403，将事件资源更新数据写入至预设业务资源数据库，执行当前被触发关注事件对应的下一关注事件。

步骤405，获取预设业务资源数据库反馈的数据写入结果消息。

步骤407，当数据写入结果消息为数据写入失败消息时，重新将事件资源更新数据写入至预设业务资源数据库。

具体地，如果在服务进程中采用跨进程事件处理的话，有可能会因为业务资源数据库的读写操作造成事件阻塞。而为了避免这种阻塞，服务器104在执行预定义处理逻辑的过程中，首先执行关注事件对应的预定义处理逻辑，当得到事件资源更新数据后，如果需要将数据保存至业务资源数据库DB中，则可以直接将这部分事件资源更新数据写入到业务资源数据库，同时不等待游戏资源数据的回复，直接认定事件资源更新数据已经写入成功，并直接执行当前被触发关注事件对应的下一关注事件，从而规避阻塞。而当接收到预设业务资源数据库反馈的数据写入失败消息时，则需要重新尝试写入。此时，需要重新将事件资源更新数据写入至预设业务资源数据库。在其中一个实施例中，应用本申请跨进程事件处理可以参照图5所示，如图5中左上图所示，在现有的事件队列处理方式下，如果主业务服务进程GameSvr出现异常，有可能导致事件队列中的事件全部丢失。而在进行跨进程事件处理时，GameSvr可以在收到事件时就直接处理，不需要等待，可以有效防止事件的丢失。而在从属业务服务进程中进行事件处理时，如图5中以及下左图所示，采用并发处理的处理方式可能乱序，而如图5中下中图所示，采用串行处理的方式处理效率较低，而如图5中下右图所示，采用本实施例中的处理方式，不堵塞效率高。不需要事件队列，可靠性高。本实施例中，通过直接将事件资源更新数据写入到预设业务资源数据库中，而不等预设业务资源数据库反馈结果，可以有效避免因预设业务资源数据库应答而造成的异步阻塞，提高事件处理效率。

在其中一个实施例中，如图6所示，在从属业务服务进程中执行关注事件对应的预定义处理逻辑之后还包括：

步骤601，读取从属业务服务进程反馈的事件处理结果消息。

步骤603，提取事件处理结果中的关注事件处理集合更新数据。

步骤605，基于关注事件处理集合更新数据对目标对象的事件管理线程进行更新。

步骤607，根据更新后的目标对象的事件管理线程执行事件补发处理。

其中，从属业务服务进程在执行预定义处理逻辑后，可以生成对应的事件处理结果，这个结果会被反馈到主业务服务进程中，事件处理结果消息中包含预定义处理逻辑对关注事件的处理结果。此外，在事件处理结果消息中还包含有关注事件的更新数据，用于对主业务服务进程内的事件管理线程内的关注事件进行更新。

具体地，本申请中还包含有事件处理之间的事件补发处理过程。事件补发主要用于在关注事件发生变化后，可以及时地进行事件补发，从而避免事件丢失。在其中一个具体的实施例中，如图7所示，主业务服务进程为GameSvr，从属业务服务进程具体为TaskSvr，在初始的游戏业务处理进程中，目标对象对应的关注事件只包含有事件1和事件5，如果产生了新的关注事件3号事件，但新关注的事件还未传递到GameSvr之前，GameSvr就产生了3号事件，由于当时GameSvr并不知道需要关注3号事件，所以将3号事件过滤了，这将导致本该由从属业务服务进程TaskSvr触发的3号事件丢失。此时，可以通过事件补发操作来避免3号事件的丢失，如图8所示，给事件增加了序号，Gemsvr和TaskSvr都维护了当前处理的序号。GameSvr产生事件1时设置事件1的序号seq为1，GameSvr的当前已处理完成的事件序号curseq＝0。TaskSvr收到事件1后发现过滤集合为空，所以就立即处理了事件1，同时将自己的已处理序号m_CurSeq的值设置为事件1seq的值1。同时在回复的消息中通知GameSvr已经处理了seq＝1的事件，即AckSeq＝1。GameSvr在收到此回复之前已经产生了seq＝101的事件3，将该事件缓存在了队列中。然后又产生了seq＝201的5号事件，5号事件发送给TaskSvr时把缓存队列中的事件集合作为过滤集也一起带上了，TaskSvr收到seq为201的5号事件时，发现过滤集合中包含了新增的3号事件，则挂起5号事件的处理逻辑，等待GameSvr补发3号事件，从而防止事件丢失。本实施例中，通过添加事件补发机制，可以有效地防止事件处理过程中的事件丢失，保证业务逻辑处理的准确性。

本申请还提供一种应用场景，该应用场景应用上述的业务逻辑处理方法。

具体地，该业务逻辑处理方法在该应用场景的应用如下：

当用户通过手机终端来实现手机游戏的游玩时，可以通过本申请的业务逻辑处理方法实现该手机游戏的业务逻辑处理。如对于手机游戏中的任务玩法，如图9中左图所示，在未启用本技术的方案，任务与上下文信息高度耦合，难以将任务玩法从核心游戏业务逻辑中独立出来。而图9中中间部分的图则是本申请中是使用事件和属性系统拆分逻辑的方案，图9中右图则是在事件和属性系统拆分逻辑的基础上，进一步拆分成微服务的方案，其中将任务系统拆分成独立的TaskSvr，TaskSvr把数据存在DB(数据库)中，实现了TaskSvr服务的无状态集群化。本申请中业务逻辑处理的解耦思路可以参照图10所示，业务逻辑处理中事件驱动&&属性同步的原理具体可以参照图11所示，玩家登录游戏后，TaskSvr会收集任务系统中玩家需要关注的事件处理集合(即正在执行的任务所绑定的事件条件)，将收集到的事件处理集合发送给GameSvr，GameSvr将其注册到玩家事件管理线程，当GameSvr上玩家的事件触发时，会执行到对应的事件处理逻辑1(该逻辑可以做过滤，也可以不做过滤，直接把事件转发给TaskSvr处理)，该事件处理逻辑中可以使用玩家的属性信息进行判定，事件处理逻辑判定不通过会直接丢弃该事件(即过滤无用事件)，如果判定通过则会将事件继续发送给TaskSvr，TaskSvr上也有玩家事件管理线程注册了该事件的处理逻辑2，处理逻辑2可以做一些自定义的操作，包括改变任务状态等，也可以使用从GameSvr上同步过来的部分属性信息。在玩家登录游戏后，TaskSvr除了收集事件处理逻辑外，也会收集任务系统中玩家需要使用的属性集合，将需要的属性集合发送给GameSvr，GameSvr会将其注册到属性系统，初始时会将被注册的这部分属性一次性发送到TaskSvr，之后每次这部分属性发生变更，GameSvr都会讲变更的信息同步给TaskSvr。从而TaskSvr将具备GameSvr属性全集中的一部分属性集合。属性全集的信息会很多，而TaskSvr需要的属性子集信息是比较少的，从而减少了不必要的网络消耗。同时在本申请的方案中，可以采用跨进程事件处理的处理方式来防止因事件队列堵塞引起的事件丢失，在把数据存到数据库(DB)，所以为了规避阻塞，存数据时不等数据库DB的回复，直接认为数据写成功了，如果数据写失败了，则后续尝试重新写入。此外，本申请中还能有效过滤非必要事件，从而减少网络异步开销。在进行过滤时，还可以进行有条件判定逻辑，当事件量(瞬时)比较大时，可以开启更细粒度的条件前置过滤逻辑，不满足条件的事件不用发给TaskSvr。本申请中具体基于令牌桶限流算法来进行事件过滤开启时机优化，具体可以参照图12所示，TaskSvr为实现游戏任务系统的服务进程，GameSvr为实现核心游戏逻辑的服务进程。首先，TaskSvr根据配置出关注的所有事件集合{1，3，5}。当未开启过滤机制时，所有事件都不会存缓存队列，只会立即发送或者直接丢弃，不在事件集合中的无效事件丢弃。而在当大量无效事件将令牌桶消耗完，切换到更精细的时间条件过滤。在这个过程中，大部分5号事件的条件集合不满足条件，被过滤丢到缓存队列，同时3号事件的条件集合不满足条件，被过滤丢到缓存队列。而在TaskSvr处理完1号事件后，还可以新增3号事件条件ackseq＝1，以在GameSvr中实现对1号事件的补发操作。而在令牌桶容量恢复已满，并且收到上一条时间的ackseq时，丢弃时间缓存的队列为空才关闭条件过滤确认机制。

应该理解的是，虽然如上的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的业务逻辑处理方法的业务逻辑处理装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个业务逻辑处理装置实施例中的具体限定可以参见上文中对于业务逻辑处理方法的限定，在此不再赘述。

在一个实施例中，如图13所示，提供了一种业务逻辑处理装置，包括：集合构建模块、事件注册模块和逻辑处理模块，其中：

登录响应模块1302，用于响应目标对象登录事件，确定主业务服务进程和从属业务服务进程。

集合构建模块1304，用于通过从属业务服务进程，获取目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合。

事件写入模块1306，用于将关注事件处理集合写入至主业务服务进程中事件管理线程，并将属性需求集合写入至主业务服务进程中属性管理线程。

事件驱动模块1308，用于当通过事件管理线程识别到关注事件被触发时，基于被触发的关注事件，在从属业务服务进程中执行关注时间对应的预定义处理逻辑。

属性同步模块1310，用于当通过属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在从属业务服务进程中执行属性子集信息对应的属性信息同步处理。

在其中一个实施例中，逻辑处理模块1306具体用于：当当通过事件管理线程识别到关注事件被触发时，从事件管理线程读取目标对象对应的事件判定属性信息；当基于事件判定属性信息以及预设事件触发处理逻辑判定关注事件为有用事件时，基于被触发的关注事件，在从属业务服务进程中执行关注事件对应的预定义处理逻辑。

在其中一个实施例中，逻辑处理模块1306还用于：当通过事件管理线程识别到关注事件被触发时，基于令牌桶限流算法从属性管理线程读取目标对象对应的事件判定属性信息。

在其中一个实施例中，逻辑处理模块1306还用于：当通过事件管理线程识别到关注事件被触发时，基于被触发的关注事件，在从属业务服务进程中通过跨进程事件处理执行关注事件对应的预定义处理逻辑。

在其中一个实施例中，逻辑处理模块1306还用于：通过在从属业务服务进程中通过跨进程事件处理执行关注事件对应的预定义处理逻辑，获取事件资源更新数据；将事件资源更新数据写入至预设业务资源数据库，执行当前被触发关注事件对应的下一关注事件；获取预设业务资源数据库反馈的数据写入结果消息；当数据写入结果消息为数据写入失败消息时，重新将事件资源更新数据写入至预设业务资源数据库。

在其中一个实施例中，还包括事件补发模块，用于：读取从属业务服务进程反馈的事件处理结果消息；提取事件处理结果中的关注事件处理集合更新数据；基于关注事件处理集合更新数据对事件管理线程进行更新；根据更新后的事件管理线程执行事件补发处理。

上述业务逻辑处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图14所示。该计算机设备包括处理器、存储器、输入/输出接口(Input/Output，简称I/O)和通信接口。其中，处理器、存储器和输入/输出接口通过系统总线连接，通信接口通过输入/输出接口连接到系统总线。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储业务逻辑处理中产生数据。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种业务逻辑处理方法。

本领域技术人员可以理解，图14中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (10)

1.一种业务逻辑处理方法，其特征在于，所述方法包括：

响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；

通过所述从属业务服务进程，获取所述目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；

将所述关注事件处理集合写入至所述主业务服务进程中事件管理线程，并将所述属性需求集合写入至所述主业务服务进程中属性管理线程；

当通过所述事件管理线程识别到所述关注事件被触发时，基于所述被触发的所述关注事件，在所述从属业务服务进程中执行所述关注时间对应的预定义处理逻辑；

当通过所述属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在所述从属业务服务进程中执行所述属性子集信息对应的属性信息同步处理。

2.根据权利要求1所述的方法，其特征在于，所述当通过所述事件管理线程识别到所述关注事件被触发时，基于所述被触发的所述关注事件，在所述从属业务服务进程中执行所述关注时间对应的预定义处理逻辑包括：

当通过所述事件管理线程识别到所述关注事件被触发时，从所述事件管理线程读取目标对象对应的事件判定属性信息；

当基于所述事件判定属性信息以及预设事件触发处理逻辑判定所述关注事件为有用事件时，基于所述被触发的关注事件，在所述从属业务服务进程中执行所述关注事件对应的预定义处理逻辑。

3.根据权利要求2所述的方法，其特征在于，所述当通过所述事件管理线程识别到所述关注事件被触发时，从所述事件管理线程读取目标对象对应的事件判定属性信息包括：

当通过所述事件管理线程识别到所述关注事件被触发时，基于令牌桶限流算法从所述属性管理线程读取目标对象对应的事件判定属性信息。

4.根据权利要求1所述的方法，其特征在于，所述当通过所述事件管理线程识别到所述关注事件被触发时，基于所述被触发的所述关注事件，在所述从属业务服务进程中执行所述关注时间对应的预定义处理逻辑包括：

当通过所述事件管理线程识别到关注事件被触发时，基于所述被触发的关注事件，在所述从属业务服务进程中通过跨进程事件处理执行所述关注事件对应的预定义处理逻辑。

5.根据权利要求4所述的方法，其特征在于，所述在所述从属业务服务进程中通过跨进程事件处理执行所述关注事件对应的预定义处理逻辑包括：

通过在所述从属业务服务进程中通过跨进程事件处理执行所述关注事件对应的预定义处理逻辑，获取事件资源更新数据；

将所述事件资源更新数据写入至预设业务资源数据库，执行当前被触发关注事件对应的下一关注事件；

获取预设业务资源数据库反馈的数据写入结果消息；

当所述数据写入结果消息为数据写入失败消息时，重新将所述事件资源更新数据写入至预设业务资源数据库。

6.根据权利要求1至5任意一项所述的方法，其特征在于，所述在所述从属业务服务进程中执行所述关注事件对应的预定义处理逻辑之后还包括：

读取从属业务服务进程反馈的事件处理结果消息；

提取所述事件处理结果中的关注事件处理集合更新数据；

基于所述关注事件处理集合更新数据对所述事件管理线程进行更新；

根据更新后的所述事件管理线程执行事件补发处理。

7.一种业务逻辑处理装置，其特征在于，所述装置包括：

登录响应模块，用于响应目标对象登录事件，确定主业务服务进程和从属业务服务进程；

集合构建模块，用于通过所述从属业务服务进程，获取所述目标对象对应的关注事件和对象属性需求，分别构建关注事件处理集合以及属性需求集合；

事件写入模块，用于将所述关注事件处理集合写入至所述主业务服务进程中事件管理线程，并将所述属性需求集合写入至所述主业务服务进程中属性管理线程；

事件驱动模块，用于当通过所述事件管理线程识别到所述关注事件被触发时，基于所述被触发的所述关注事件，在所述从属业务服务进程中执行所述关注时间对应的预定义处理逻辑；

属性同步模块，用于当通过所述属性管理线程识别到属性信息变化时，基于变化的属性子集信息，在所述从属业务服务进程中执行所述属性子集信息对应的属性信息同步处理。

8.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述的方法的步骤。

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

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