用于游戏进程的RPC处理方法、设备、介质及程序产品

技术领域

本申请涉及虚拟世界技术领域，特别涉及一种用于游戏进程的RPC处理方法、设备、介质及程序产品。

背景技术

在游戏服务器内部的点对点RPC通信中，通常采用发送方和接收方的身份标识号ID信息散列Hash固定的路由。然而，当海量的游戏对象进行动态扩缩容时，极易导致系统消息无法正确传递。

在相关技术中，消息队列可以实现异步通信和解耦，提高系统信息传递的可靠性和扩展性。

然而，消息队列的可靠性需要将消息持久化到硬盘上，所用开销巨大；同时，游戏服务器的玩家对象可能达到百万量级，现有的消息队列最多支持数万级别，不能满足游戏服务器数量的要求。

发明内容

本申请提供了一种用于游戏进程的RPC处理方法、设备、介质及程序产品，所述技术方案如下：

根据本申请的一方面，提供了一种用于游戏进程的RPC处理方法，所述方法包括：

在角色对象从第一游戏逻辑进程迁移到第二游戏逻辑进程的过程中，在所述第一游戏逻辑进程中暂停所述角色对象的远程过程调用RPC的运行；所述角色对象是游戏中的虚拟角色的数据的集合；

将所述角色对象的数据从所述第一游戏逻辑进程转移至所述第二游戏逻辑进程；

将第一路由信息修改为第二路由信息，所述第一路由信息用于将发送给所述角色对象的RPC消息路由至所述第一游戏逻辑进程，所述第二路由信息用于将发送给所述角色对象的RPC消息路由至所述第二游戏逻辑进程；

在所述第二游戏逻辑进程中恢复所述角色对象的RPC的运行。

根据本申请的另一方面，提供了一种用于游戏进程的RPC处理装置，所述装置包括：

RPC运行暂停模块，用于在角色对象从第一游戏逻辑进程迁移到第二游戏逻辑进程的过程中，在所述第一游戏逻辑进程中暂停所述角色对象的远程过程调用RPC的运行；所述角色对象是游戏中的虚拟角色的数据的集合；

数据转移模块，用于将所述角色对象的数据从所述第一游戏逻辑进程转移至所述第二游戏逻辑进程；

路由信息修改模块，用于将第一路由信息修改为第二路由信息，所述第一路由信息用于将发送给所述角色对象的RPC消息路由至所述第一游戏逻辑进程，所述第二路由信息用于将发送给所述角色对象的RPC消息路由至所述第二游戏逻辑进程；

RPC运行恢复模块，用于在所述第二游戏逻辑进程中恢复所述角色对象的RPC的运行。

根据本申请的另一方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上方面所述的用于游戏进程的RPC处理方法。

根据本申请的另一方面，提供了一种计算机可读存储介质，所述可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如上方面所述的用于游戏进程的RPC处理方法。

根据本申请的另一方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机指令，所述计算机指令存储在计算机可读存储介质中，处理器从所述计算机可读存储介质读取并执行所述计算机指令，以实现上述如上方面所述的用于游戏进程的RPC处理方法。

本申请实施例提供的技术方案可以包括如下有益效果：

通过在转移角色对象的数据之前暂停远程过程调用RPC的运行，并在转移角色对象的数据之后恢复远程过程调用RPC的运行，能够确保转移后数据的完整性，提高游戏服务器中海量游戏对象之间的远程过程调用的可靠性，避免系统信息的传递错误。

附图说明

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

图1是本申请一个示例性实施例提供的计算机系统的结构框图；

图2是本申请一个示例性实施例提供的游戏服务器的游戏逻辑进程网络示意图；

图3是本申请一个示例性实施例提供的用于游戏进程的RPC处理方法的流程图；

图4是本申请一个示例性实施例示出的用于RPC处理方法的连接建立的示意图；

图5是本申请一个示例性实施例提供的用于游戏进程的RPC处理方法的示意图；

图6是本申请一个示例性实施例提供的对象转移失败的RPC处理方法的示意图；

图7是本申请一个示例性实施例提供的涉及转移第四RPC消息的流程图；

图8是本申请一个示例性实施例提供的涉及离线转移的RPC处理方法的示意图；

图9是本申请一个示例性实施例示出的用于游戏进程的RPC处理装置的方框图；

图10是本申请一个示例性实施例示出的计算机设备1000的结构框图。

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。例如，本申请中涉及到的攻击操作等对象行为都是在充分授权的情况下获取的。

应当理解，尽管在本公开可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一参数也可以被称为第二参数，类似地，第二参数也可以被称为第一参数。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1示出了本申请一个示例性实施例提供的计算机系统的结构框图。该计算机系统100包括：第一终端110、服务器120、第二终端130。

第一终端110安装和运行有支持虚拟场景的客户端111。当第一终端110运行客户端111时，第一终端110的屏幕上显示客户端111的用户界面。该客户端111可以是策略游戏(Simulation Game，SLG)、仿真程序、大逃杀射击游戏、虚拟现实(Virtual Reality，VR)应用程序、增强现实(Augmented Reality，AR)程序、地图程序、虚拟现实游戏、增强现实游戏、第一人称射击游戏(First-Person Shooting Game，FPS)、第三人称射击游戏(Third-Personal Shooting Game，TPS)、多人在线战术竞技游戏(Multiplayer Online BattleArena Games，MOBA)中的任意一种。在本实施例中，以该客户端111是策略游戏来举例说明。第一终端110是第一用户112使用的终端，第一用户112使用第一终端110控制位于虚拟场景中的第一虚拟对象进行活动，第一虚拟对象可以称为第一用户112的虚拟对象。第一虚拟对象的活动包括但不限于：移动、跳跃、传送、释放技能、使用道具、攻击、与其它对象交互中的至少一种。示意性的，第一虚拟对象是第一虚拟对象，比如仿真人物角色或动漫人物角色。

第二终端130安装和运行有支持虚拟场景的客户端131。当第二终端130运行客户端131时，第二终端130的屏幕上显示客户端131的用户界面。该客户端131可以是SLG、仿真程序、大逃杀射击游戏、VR应用程序、AR程序、地图程序、虚拟现实游戏、增强现实游戏、FPS、TPS、MOBA中的任意一种。在本实施例中，以该客户端131是SLG游戏来举例说明。第二终端130是第二用户132使用的终端，第二用户132使用第二终端130控制位于虚拟场景中的第二虚拟对象进行活动，第二虚拟对象可以称为第二用户132的虚拟对象。示意性的，第二虚拟对象是第二虚拟对象，比如仿真人物角色或动漫人物角色。

可选地，第一虚拟对象和第二虚拟对象处于同一虚拟场景中。可选地，第一虚拟对象和第二虚拟对象可以属于同一个阵营、同一个队伍、同一个组织、具有好友关系或具有临时性的通讯权限。可选的，第一虚拟对象和第二虚拟对象可以属于不同的阵营、不同的队伍、不同的组织或具有敌对关系。

可选地，第一终端110和第二终端130上安装的客户端是相同的，或两个终端上安装的客户端是不同操作系统平台(安卓或iOS)上的同一类型客户端。第一终端110可以泛指多个终端中的一个，第二终端130可以泛指多个终端中的另一个，本实施例仅以第一终端110和第二终端130来举例说明。第一终端110和第二终端130的设备类型相同或不同，该设备类型包括：智能手机、平板电脑、电子书阅读器、MP3播放器、MP4播放器、膝上型便携计算机和台式计算机中的至少一种。

图1中仅示出了两个终端，但在不同实施例中存在多个其它终端140可以接入服务器120。可选地，还存在一个或多个其它终端140是开发者对应的终端，在其它终端140上安装有支持虚拟场景的客户端的开发和编辑平台，开发者可在其它终端140上对客户端进行编辑和更新，并将更新后的客户端安装包通过有线或无线网络传输至服务器120，第一终端110和第二终端130可从服务器120下载客户端安装包实现对客户端的更新。

第一终端110、第二终端130以及其它终端140通过无线网络或有线网络与服务器120相连。

服务器120包括一台服务器、多台服务器、云计算平台和虚拟化中心中的至少一种。服务器120用于为支持虚拟场景的客户端提供后台服务。可选地，服务器120承担主要计算工作，终端承担次要计算工作；或者，服务器120承担次要计算工作，终端承担主要计算工作；或者，服务器120和终端之间采用分布式计算架构进行协同计算。

在一个示意性的例子中，服务器120包括处理器122、用户账号数据库123、对战服务模块124、面向用户的输入/输出接口(Input/Output Interface，I/O接口)125。其中，处理器122用于加载服务器121中存储的指令，处理用户账号数据库123和对战服务模块124中的数据；用户账号数据库123用于存储第一终端110、第二终端130以及其它终端140所使用的用户账号的数据，比如用户账号的头像、用户账号的昵称、用户账号的战斗力指数，用户账号所在的服务区；对战服务模块124用于提供多个对战房间供用户进行对战，比如1V1对战、3V3对战、5V5对战等；面向用户的I/O接口125用于通过无线网络或有线网络和第一终端110和/或第二终端130建立通信交换数据。

下面介绍本申请涉及的一些名词释义：

传输控制协议(Transmission Control Protocol，TCP)：是一种面向连接的、可靠的、基于字节流的传输层通信协议。

远程过程调用(Remote Procedure Call，RPC)：一种分布式计算的通信协议，允许进程请求另一个进程的服务，而无需了解底层网络细节。

角色(Character)对象：虚拟角色在服务器进程上的数据的集合。

ETCD：ETCD是一个分布式键值存储系统，用于存储和检索数据。

散列算法(Hash Algorithm，Hash)：又称哈希算法、杂凑算法，是一种将任意长度的输入数据映射到固定长度输出的算法。

主题(Topic)：在消息队列中，一个Topic是一种消息分类方式，它定义了一组相关的消息。当生产者发布消息到Topic时，消费者可以订阅该Topic并接收相关的消息。

数据描述语言(Protocol Buffers，Protobuf)：是一种轻便高效的结构化数据存储格式，可用于结构化数据的序列化，具有语言无关、平台无关、可扩展性的特性，常用于通讯协议、服务端数据交换场景。

现实生活中的游戏服务器主机，通常在一个机房里，内部的网络环境相对稳定。在游戏服务器内部通信过程中，TCP是作为基础网络协议被广泛使用，在服务器内部的点对点RPC通信中，通常采用发送方和接收方身份标识号(Identity Document，ID)信息Hash固定的路由，以保证消息传输的可靠性和顺序性。

然而，当服务器现有服务无法满足玩家需求时，实时扩容可能导致Hash选择路由Router的变化，而路由进程的崩溃或物理链接出现问题则可能导致消息无法正确传递。这种消息不可靠的情况可能会导致业务无法正常处理，系统信息传递的可靠性和扩展性可能会受到影响。

消息队列服务软件(Rabbit Message Queue，RabbitMQ)、分布式发布订阅消息系统(Kafka)、开放源代码消息中间件(ActiveMQ)处理等中间件可以实现异步通信和解耦，提高系统信息传递的可靠性和扩展性。

但是游戏业务的数据，大部分往往更关注实时性，而非可靠性。例如，玩家位置信息的同步以及外观信息的同步。消息队列的可靠性需要将消息持久化到硬盘上，带来开销巨大。

同时游戏服务器的玩家对象特别多，可能达到百万量级，每一个玩家对象在消息队列里面就是一个Topic。现在的消息队列最多支持的Topic万级别，不能满足游戏服务器数量的要求。

请参考图2，图2示出了本申请一个示例性实施例提供的游戏服务器的游戏逻辑进程网络示意图。如图2所示：

游戏逻辑进程(Process，P)上缓存有Character对象，Character对象可以在不同游戏逻辑进程P之间迁移，比如Character对象由P1迁移至P3；其中，游戏逻辑进程P可以动态地增加或者减少。

路由(Router)是游戏逻辑进程P之间的路由，上面有Character ID至PID的路由缓存；其中，所有Router是相互连接的，比如路由Router1、路由Router2、路由Router3相互连接。

ETCD用于服务治理，缓存进程信息。当RPC消息无法送达下一个节点时，如果下一个节点就是目标游戏逻辑进程P，那么当前游戏逻辑进程P作为最后一个路由节点，需要判断目标游戏逻辑进程P是否存在。对于有ETCD监听的情况，根据ETCD提供的节点信息判断；对于没有ETCD监听的情况，直接判断有无网络连接。

请参考图3，其示出了本申请一个示例性实施例提供的用于游戏进程的RPC处理方法的流程图。该方法可以由服务器执行，比如，该服务器可以是图1所示系统中的服务器120。如图3所示，该方法可以包括步骤310、步骤320、步骤330和步骤340。

步骤310：在角色对象从第一游戏逻辑进程迁移到第二游戏逻辑进程的过程中，在第一游戏逻辑进程中暂停角色对象的远程过程调用RPC的运行；角色对象是游戏中的虚拟角色的数据的集合。

也就是说，当角色对象从一个游戏逻辑进程(即第一游戏逻辑进程)迁移到另一个游戏逻辑进程(即第二游戏逻辑进程)时，在该迁移过程中，在第一游戏逻辑进程中暂停角色对象的远程过程调用RPC的运行。

其中，角色对象是游戏中的虚拟角色的数据的集合。

步骤320：将角色对象的数据从第一游戏逻辑进程转移至第二游戏逻辑进程。

也就是说，在步骤310暂停角色对象的远程过程调用RPC的运行之后，将角色对象的数据从第一游戏逻辑进程转移至第二游戏逻辑进程。

其中，角色对象的数据是角色对象在第一游戏逻辑进程上缓存的所有状态信息，以确保角色对象状态信息的完整性。

具体比如，角色对象的数据可以包括虚拟对象的连接信息、窗口信息、RPC信息、位置信息、属性信息、标识信息、对象类型信息等。其中，属性信息可以包括虚拟对象的生命值、武力值、体力值、魔法值、等级、角色所属工会、经验、金钱、身上的物品等；标识信息可以包括虚拟对象的角色名、ID等；对象类型信息可以包括虚拟对象的角色职业信息等。

在一些实施例中，在步骤320将角色对象的数据从第一游戏逻辑进程转移至第二游戏逻辑进程之前，可以将角色对象的数据序列化，获取要转移的数据的优先级，以实现数据转移的高效性。

步骤330：将第一路由信息修改为第二路由信息，第一路由信息用于将发送给角色对象的RPC消息路由至第一游戏逻辑进程，第二路由信息用于将发送给角色对象的RPC消息路由至第二游戏逻辑进程。

路由信息指的是哈希表(Hash Table)，可以通过哈希表将角色对象ID索引到对应的逻辑进程。例如，角色ID至第一进程，修改为角色ID至第二进程。

在步骤320转移角色对象的数据之后，修改该角色对象对应的路由信息，以便第二游戏逻辑进程可以接收到发送给该角色对象的消息。

将第一路由信息修改为第二路由信息。其中，第一路由信息是将发送给角色对象的RPC消息路由至第一游戏逻辑进程的路由信息，第二路由信息是将发送给角色对象的RPC消息路由至第二游戏逻辑进程的路由信息。

其中，第一路由信息与第二路由信息是不同的。在角色对象的数据转移之前，角色对象对应的路由信息是用于将发送给角色对象的RPC消息路由至第一游戏逻辑进程的一个路由信息(即第一路由信息)；在完成角色对象的数据转移之后，将角色对象对应的第一路由信息修改为用于将发送给角色对象的RPC消息路由至第二游戏逻辑进程的另一个路由信息(即第二路由信息)。

比如，将发送给角色对象的RPC消息路由至第一游戏逻辑进程的第一路由信息是Router A，将发送给角色对象的RPC消息路由至第二游戏逻辑进程的第二路由信息是Router B。那么，在完成角色对象的数据转移之后，需要将角色对象的路由信息由Router A修改为Router B，以便后续发送给角色对象的RPC消息直接发送至第二游戏逻辑进程缓存，避免RPC消息的丢失，确保RPC信息的完整性。

步骤340：在第二游戏逻辑进程中恢复角色对象的RPC的运行。

在步骤330修改为路由信息之后，在第二游戏逻辑进程中恢复角色对象的RPC的运行，以便恢复远程过程调用RPC的逻辑功能，恢复正常状态。

其中，上述步骤310暂停RPC运行指的是，角色对象接收RPC信息，放入缓存但不处理；相应的，步骤340恢复RPC运行指的是，处理RPC信息，即从缓存区取出消息，恢复处理。

需要说明的是，此时第一游戏逻辑进程和第二游戏逻辑进程的角色对象都缓存有完整的角色对象的数据，包括完整的RPC信息。

在一些实施例中，在步骤340在第二游戏逻辑进程中恢复角色对象的RPC的运行之后，销毁第一游戏逻辑进程的角色对象和角色对象的数据，以避免不同的游戏逻辑进程中的冗余缓存，节约服务器的存储资源。

综上所述，本申请实施例所示的方案，通过在转移角色对象的数据之前暂停远程过程调用RPC的运行，并在转移角色对象的数据之后恢复远程过程调用RPC的运行，能够确保转移后数据的完整性，提高游戏服务器中海量游戏对象之间的远程过程调用的可靠性，避免系统信息的传递错误。

请参考图4，图4其示出了本申请一个示例性实施例示出的用于RPC处理方法的连接建立的示意图。不同的Character对象通常位于不同的游戏逻辑进程P，当不同的Character对象进行消息传递前，需要先建立连接。

如图4所示，发送端和接收端通过两次握手建立会话(session)，无需通过三次握手建立连接。由于游戏服务器通常在一个机房里，内部的网络环境相对稳定，只需要确认发送端的消息包能被接收端确认即可。相对于三次握手建立连接的方式，两次握手的方式可以节约流量。

发送端发送RPC消息时，无连接则建立连接，直接向接收端发送消息包并缓存在本地，等待正向反馈(Acknowledgement，ACK)。接收端收到消息包后向发送端回复ACK1+session ID，发送端收到session ID后进入session状态。

相应地，连接的断开包括主动断开和被动断开。

其中，主动断开可以是发送方主动断开连接；或者是发送方一段时间不发包，主动关闭虚连接；或者是发送关闭(Close)消息通知对端关闭。

其中，被动断开可以是消息路由时发现对端下线，触发未找到(not Found)消息，直接关闭连接。

在一些实施例中，在第二游戏逻辑进程中恢复角色对象的RPC的运行之前，还包括：

将第一游戏逻辑进程中的第一RPC消息转移至第二游戏逻辑进程；第一RPC消息是第一游戏逻辑进程从暂停角色对象的RPC的运行的时间点，到将第一路由信息修改为第二路由信息的时间点之间接收到的，发送给角色对象的RPC消息；

在第二游戏逻辑进程中恢复角色对象的RPC的运行，包括：

在第一RPC消息转移完成后，在第二游戏逻辑进程中对第一RPC消息以及第二RPC消息进行有序化处理；第二RPC消息是第二游戏逻辑进程在将第一路由信息修改为第二路由信息之后接收到的，发送给角色对象的RPC消息；

在对第一RPC消息以及第二RPC消息有序化处理完成后，在第二游戏逻辑进程中恢复角色对象的RPC的运行。

需要说明的是，上述步骤310中暂停角色对象的远程过程调用RPC的运行，指的是暂停远程过程调用RPC的逻辑功能，服务器仍然可以接收RPC消息并缓存到第一游戏逻辑进程中，这是为了不影响第一游戏逻辑进程接收RPC消息的功能以及保证RPC信息的完整性。

也就是说，可能存在一部分RPC消息是在暂停RPC运行期间接收的，这一部分RPC消息没有随着步骤320角色对象的数据转移缓存在第二游戏逻辑进程，仍然缓存在第一游戏逻辑进程中。

因此，本申请实施例提出了如下技术方案：在第二游戏逻辑进程中恢复角色对象的RPC的运行之前，将第一游戏逻辑进程中的第一RPC消息转移至第二游戏逻辑进程。其中，第一RPC消息指的是第一游戏逻辑进程从暂停角色对象的RPC的运行的时间点，到将第一路由信息修改为第二路由信息的时间点之间接收到的，发送给角色对象的RPC消息。

在一些实施例中，可以在第二游戏逻辑进程中恢复角色对象的RPC的运行之前，判断是否有上述第一RPC消息的存在。若存在上述第一RPC消息，则将上述第一RPC消息转移至第二游戏逻辑进程；若没有，则不需要进行该转移步骤。

另外，在步骤330修改路由信息之后，可能存在一部分消息直接缓存到第二游戏逻辑进程，这一部分消息就是第二RPC消息，针对第二游戏逻辑进程同时存在第一RPC消息和第二RPC消息的情况，本申请实施例提出了如下技术方案：

在第二游戏逻辑进程中恢复角色对象的RPC的运行，可以包括：

在第一RPC消息转移完成后，对第二游戏逻辑进程中的第一RPC消息以及第二RPC消息进行有序化处理；其中，第二RPC消息指的是第二游戏逻辑进程在将第一路由信息修改为第二路由信息之后接收到的，发送给角色对象的RPC消息。

其中，可以使用Protobuf对RPC消息进行序列化处理，使用RPC消息的序号对RPC消息进行排序。

在上述有序化处理完成后，在第二游戏逻辑进程中恢复角色对象的RPC的运行。

本申请实施例提出了一种优化方案，避免了在转移过程中，因远程过程调用PRC运行的暂停而可能丢失的RPC消息，能够保证转移后RPC信息的完整性，避免系统信息传递出错。另外，还提出了在第二游戏逻辑进程的有序化处理方案，提高恢复RPC运行的处理效率。

RPC的迁移：

游戏逻辑进程P上的Character对象，会在服务器进行动态扩缩容，或者在不同游戏区域移动的时候，将Character对象的所有状态迁移到目标游戏逻辑进程P，并自动恢复，Character对象上的RPC信息也是迁移时需要转移的状态之一。

Character对象进入迁移状态后，暂停RPC的运行；将连接信息、窗口信息，等序列化带到迁移目标端进程；在创建迁移目标Character对象的时候，恢复RPC信息。此时，迁移两端的Character对象都有完整的RPC信息。当迁移结束后，源的RPC信息随着Character对象的销毁而销毁。

请参考图5，其示出了本申请一个示例性实施例提供的用于游戏进程的RPC处理方法的示意图。如图5所示，涉及迁移流程中的消息接收：

步骤51、发送端的Character对象发送RPC消息；

步骤52、在迁移流程中，部分RPC消息路由至迁移发起端Character对象的游戏逻辑进程，将该RPC部分消息中转至迁移目标端Character对象的游戏逻辑进程；部分RPC消息路由至迁移目标端Character对象的游戏逻辑进程；

步骤53、迁移完成后，恢复RPC处理，进行ACK回复。

迁移流程中，有一个步骤时修改Router上的路由表信息，存在一部分RPC消息通过旧路由将数据转发到迁移发起端，一部分RPC消息通过新路由将数据转发到了迁移目标端。

对于发送到迁移发起端的消息，直接转发至迁移目标端，迁移目标端上的Character对象接收到RPC消息后，对RPC消息进行缓存。Character对象结束迁移后，统一触发RPC处理和ACK回复。RPC的窗口自动将两类消息有序化，当整个迁移流程的时长控制在一定范围内，ACK的回复不会延迟太多，发送端不会因为超时触发重发，整个迁移过程不会有任何消息重发，额外打包。

现有技术是将消息发给一个消息队列这个中间件，消息的容量取决于中间件的容量。本技术方案，消息直接缓存在发送的Character对象本身的进程上，也就是说进行了分散存储，就不存在数量限制了。

在一些实施例中，上述实施例所示的方法还包括：

在对象转移失败的情况下，在第一游戏逻辑进程中恢复角色对象的RPC的运行；

对象转移失败，是指角色对象从第一游戏逻辑进程迁移到第二游戏逻辑进程的过程失败。

若存在上述步骤320转移失败的情况，即角色对象的数据从第一游戏逻辑进程迁移到第二游戏逻辑进程的过程失败，在第一游戏逻辑进程中恢复角色对象的RPC的运行。

其中，上述转移失败的原因通常包括硬件损坏、断电、网线损坏、内存不足等，导致游戏逻辑进程之间无法进行通信。其中，上述转移失败的情况是偶有发生的，但若不预先设置补救措施，会造成消息丢失。

本申请实施例提出了一种优化方案，避免了在转移过程中，因转移失败而可能导致RPC消息的丢失情况，能够提高本技术方案的全面性，避免系统信息传递出错。

在一些实施例中，在第一游戏逻辑进程中恢复角色对象的RPC的运行，包括：

在对象转移失败发生在将第一路由信息修改为第二路由信息之后的情况下，将第一路由信息修改为第三路由信息，第三路由信息用于将发送给角色对象的RPC消息路由至第一游戏逻辑进程；

将第二游戏逻辑进程中的第三RPC消息转移给第一游戏逻辑进程；第三RPC消息是第二游戏逻辑进程从将第一路由信息修改为第三路由信息的时间点，到转移过程失败的时间点之间接收到的，发送给角色对象的RPC消息；

在第三RPC消息转移完成后，在第一游戏逻辑进程中恢复角色对象的RPC的运行。

当对象转移失败的情况，发生在将第一路由信息修改为第二路由信息之后时，将第二路由信息修改为第一路由信息。其中，第一路由信息指的是用于将发送给角色对象的RPC消息路由至第一游戏逻辑进程的路由信息。

也就是说，当发生转移失败时，若此时角色对象对应的路由信息已经修改为第二路由信息，需要将角色对象对应的路由信息修改回用于将发送给角色对象的RPC消息路由至第一游戏逻辑进程的路由信息，使得第一游戏逻辑进程后续恢复正常接收消息的状态后，保证消息的完整性。

在将第二路由信息修改为第一路由信息之后，将第二游戏逻辑进程中的第三RPC消息转移给第一游戏逻辑进程。其中，第三RPC消息指的是第二游戏逻辑进程从将第二路由信息修改为第一路由信息的时间点到转移过程失败的时间点之间，接收到的发送给角色对象的RPC消息。

也就是说，此时，需要将第二游戏逻辑进程上缓存的发送给角色对象的RPC消息，转移到第一游戏逻辑进程。

在第三RPC消息转移完成后，在第一游戏逻辑进程中恢复角色对象的RPC的运行。

在上述修改路由信息以及转移消息的步骤之后，就可以在第一游戏逻辑进程中恢复角色对象的RPC的运行，恢复RPC的逻辑功能。

本申请实施例提出了一种优化方案，当对象转移失败发生在路由信息修改之后的时候，将第二游戏逻辑进程的第三RPC消息转移至第一游戏逻辑进程，避免系统信息传递出错，保证迁移完成前RPC消息的完整性。

请参考图6，其示出了本申请一个示例性实施例提供的对象转移失败的RPC处理方法的示意图。如图6所示，涉及迁移失败的恢复：

步骤61、发送端的Character对象发送RPC消息；

步骤62、在迁移流程中，部分RPC消息路由至迁移发起端Character对象的游戏逻辑进程，将该RPC部分消息中转至迁移目标端Character对象的游戏逻辑进程；部分RPC消息路由至迁移目标端Character对象的游戏逻辑进程；

步骤63、若迁移失败，恢复迁移发起端Character对象的状态；

步骤64、RPC超时，发送端的Character对象重传RPC消息至迁移发起端Character对象的游戏逻辑进程。

在迁移过程中，存在各种失败的情况，当迁移失败时候，需要在迁移发起端恢复Character对象的状态，使其重新处理业务。

对于RPC消息，在迁移过程中，所有的RPC消息需要有序地在失败恢复后触发。按照上面的迁移中的消息处理策略，在迁移成功或者失败之前，发送端都不会收到ACK。因此，迁移失败的时候只需要恢复路由表消息，RPC重发流程自然会保证最终消息的保序到达。

在一些实施例中，上述实施例所示的方法还包括：

在角色对象从第二游戏逻辑进程中离线的情况下，通过第二游戏进程缓存第四RPC消息，第四RPC消息是第二游戏进程在角色对象离线后接收到的，发送给角色对象的RPC消息；

在角色对象从第三游戏逻辑进程中上线的情况下，将第二游戏逻辑进程中缓存的第四RPC消息转移至第三游戏逻辑进程。

其中，离线是指客户端对象和服务器对象失去联系，在本申请实施例中，指的是角色对象与第二游戏逻辑进程失去联系。在离线期间，若有其他角色对象向该角色对象发送RPC消息，将该RPC消息缓存在该角色对象离线前的游戏逻辑进程中。当角色对象从新的游戏逻辑进程中上线时，将该RPC消息转移至新的游戏逻辑进程。

若发生角色对象从第二游戏逻辑进程中离线的情况时，可以通过第二游戏进程缓存第二游戏进程在角色对象离线后接收到的，发送给角色对象的RPC消息，也就是第四RPC消息，避免消息发生失败造成的丢失情况。当角色对象从第三游戏逻辑进程中上线时，再将第二游戏逻辑进程中缓存的第四RPC消息转移至第三游戏逻辑进程。

本申请实施例的技术方案，优化了角色对象的离线后的消息处理方案，将离线后的RPC消息缓存在角色对象的离线前的游戏逻辑进程内，当角色对象从新的游戏逻辑进程上线时，再将该部分的RPC消息转移至新的游戏逻辑进程，避免信息丢失。

请参考图7，其示出了本申请一个示例性实施例提供的涉及转移第四RPC消息的流程图。如图7所示，在角色对象从第三游戏逻辑进程中上线的情况下，将第二游戏逻辑进程中缓存的第四RPC消息转移至第三游戏逻辑进程，可以实现为步骤710、步骤720和步骤730：

步骤710：在角色对象从第三游戏逻辑进程中上线的情况下，通过第三游戏逻辑进程注册角色对象对应的路由信息。

其中，注册角色对象对应的路由信息指的是角色对象向路由进程上的路由对象发送一个RPC消息，该RPC消息包含角色对象ID和游戏逻辑进程ID。

当角色对象从第二游戏逻辑进程中离线后又从第三游戏逻辑进程中上线时，通过第三游戏逻辑进程注册角色对象对应的路由信息。

步骤720：通过路由组件检测到注册的角色对象对应的路由信息，与第二游戏逻辑进程中离线的角色对象的路由信息存在冲突，向第二游戏逻辑进程发送确认消息，确认消息用于确认是否存在第四RPC消息。

也就是说，需要判断上述第四RPC消息是否存在。具体地，当检测到离线的角色对象的路由信息存在冲突时，向第二游戏逻辑进程发送确认消息，其中，确认消息用于确认是否存在第四RPC消息。

其中，可以通过路由组件检测到注册的角色对象对应的路由信息，与第二游戏逻辑进程中离线的角色对象的路由信息存在冲突。路由组件存储有游戏逻辑进程ID对应的IP地址，可以通过角色对象ID索引到需要送达信息的游戏逻辑进程ID的IP地址。当检测到相同角色对象ID的游戏逻辑进程ID的IP地址不同时，代表路由信息冲突。

步骤730：通过第二游戏逻辑进程，将第四RPC消息转移至第三游戏逻辑进程。

也就是说，在上述步骤720之后，就可以通过第二游戏逻辑进程，将第四RPC消息转移至第三游戏逻辑进程。

综上，本申请实施例具体说明了转移第四RPC消息的技术方案，避免角色对象离线再上线造成的信息丢失或者信息无法处理的情况。

请参考图8，其示出了本申请一个示例性实施例提供的涉及离线转移的RPC处理方法的示意图。如图8所示，涉及Character对象下线再上线处理：

在移动网络下，虚拟角色的Character对象可能存在短时间下线再上线的情况，例如乘车经过山洞。当Character对象下线，可能存在有一些消息没有确认、连接没关闭等情况。下线行为不会等待RPC的连接全部关闭，并且玩家可以在极短的时间内在其他进程上线，上线后可能会出现发送端的消息发送到最新的Character对象上的情况，而且新Character对象由于没有之前的连接信息而无法处理消息。

针对这类问题，在Character对象下线时，增加RPC模块离线托管、转移的能力，创建Character对象时，根据进程的托管数据，恢复Character对象上RPC数据。具体流程如下：

步骤81、销毁Character对象时，判断与Character对象的离线游戏逻辑进程是否有连接，有连接的情况下主动通知发送端关闭连接，并将数据转移到Character对象的离线游戏逻辑进程。

步骤82、发送端发送关闭确认信息，等待连接正常关闭后清理连接，此时路由表信息不能清理。

步骤83、Character对象重新在新的游戏逻辑进程登录上线时，登录注册路由表。

步骤84、通过路由组件检测到路由表冲突，向角色对象的原进程发起确认信息。

步骤85、若角色对象的原进程上有连接信息，取回之前的连接信息转移到角色对象新登录的进程上，也即将Character对象的离线游戏逻辑进程缓存的数据转移到当前上线的游戏逻辑进程。

请参考图9，图9其示出了本申请一个示例性实施例示出的用于游戏进程的RPC处理装置的方框图，该装置可以用于执行如图3或图7所示方法中，由服务器执行的全部或部分步骤；如图9所示，该装置包括：

RPC运行暂停模块901，用于在角色对象从第一游戏逻辑进程迁移到第二游戏逻辑进程的过程中，在第一游戏逻辑进程中暂停角色对象的远程过程调用RPC的运行；角色对象是游戏中的虚拟角色的数据的集合；

数据转移模块902，用于将角色对象的数据从第一游戏逻辑进程转移至第二游戏逻辑进程；

路由信息修改模块903，用于将第一路由信息修改为第二路由信息，第一路由信息用于将发送给角色对象的RPC消息路由至第一游戏逻辑进程，第二路由信息用于将发送给角色对象的RPC消息路由至第二游戏逻辑进程；

RPC运行恢复模块904，用于在第二游戏逻辑进程中恢复角色对象的RPC的运行。

在一些实施例中，该装置还包括RPC消息转移模块905，用于在第二游戏逻辑进程中恢复角色对象的RPC的运行之前，将第一游戏逻辑进程中的第一RPC消息转移至第二游戏逻辑进程；第一RPC消息是第一游戏逻辑进程从暂停角色对象的RPC的运行的时间点，到将第一路由信息修改为第二路由信息的时间点之间接收到的，发送给角色对象的RPC消息；

RPC运行恢复模块904，还用于在第一RPC消息转移完成后，在第二游戏逻辑进程中对第一RPC消息以及第二RPC消息进行有序化处理；第二RPC消息是第二游戏逻辑进程在将角色对象对应的路由信息修改为第一路由信息之后接收到的，发送给角色对象的RPC消息；

在对第一RPC消息以及第二RPC消息有序化处理完成后，在第二游戏逻辑进程中恢复角色对象的RPC的运行。

在一些实施例中，该装置还包括转移失败恢复模块906，用于在对象转移失败的情况下，在第一游戏逻辑进程中恢复角色对象的RPC的运行；

对象转移失败，是指角色对象从第一游戏逻辑进程迁移到第二游戏逻辑进程的过程失败。

在一些实施例中，转移失败恢复模块906，还用于在对象转移失败发生在将第一路由信息修改为第二路由信息之后的情况下，将第二路由信息修改为第一路由信息；

将第二游戏逻辑进程中的第三RPC消息转移给第一游戏逻辑进程；第三RPC消息是第二游戏逻辑进程从将第二路由信息修改为第一路由信息的时间点，到转移过程失败的时间点之间接收到的，发送给角色对象的RPC消息；

在第三RPC消息转移完成后，在第一游戏逻辑进程中恢复角色对象的RPC的运行。

在一些实施例中，该装置还包括离线缓存模块907，用于在角色对象从第二游戏逻辑进程中离线的情况下，通过第二游戏进程缓存第四RPC消息，第四RPC消息是第二游戏进程在角色对象离线后接收到的，发送给角色对象的RPC消息；

在角色对象从第三游戏逻辑进程中上线的情况下，将第二游戏逻辑进程中缓存的第四RPC消息转移至第三游戏逻辑进程。

在一些实施例中，离线缓存模块907，还用于在角色对象从第三游戏逻辑进程中上线的情况下，通过第三游戏逻辑进程注册角色对象对应的路由信息；

通过路由组件检测到注册的角色对象对应的路由信息，与第二游戏逻辑进程中离线的角色对象的路由信息存在冲突，向第二游戏逻辑进程发送确认消息，确认消息用于确认是否存在第四RPC消息；

通过第二游戏逻辑进程，将第四RPC消息转移至第三游戏逻辑进程。

图10示出了本申请一个示例性实施例示出的计算机设备1000的结构框图。该计算机设备可以实现为本申请上述方案中的服务器。该计算机设备1000包括中央处理单元(Central Processing Unit，CPU)1001、包括随机存取存储器(Random Access Memory，RAM)1002和只读存储器(Read-Only Memory，ROM)1003的系统存储器1004，以及连接系统存储器1004和中央处理单元1001的系统总线1005。该计算机设备1000还包括用于存储操作系统1009、应用程序1010和其他程序模块1011的大容量存储设备1006。

该大容量存储设备1006通过连接到系统总线1005的大容量存储控制器(未示出)连接到中央处理单元1001。该大容量存储设备1006及其相关联的计算机可读介质为计算机设备1000提供非易失性存储。也就是说，该大容量存储设备1006可以包括诸如硬盘或者只读光盘(Compact Disc Read-Only Memory，CD-ROM)驱动器之类的计算机可读介质(未示出)。

不失一般性，该计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、可擦除可编程只读寄存器(Erasable Programmable Read Only Memory，EPROM)、电子抹除式可复写只读存储器(Electrically-Erasable Programmable Read-OnlyMemory，EEPROM)闪存或其他固态存储其技术，CD-ROM、数字多功能光盘(DigitalVersatile Disc，DVD)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知该计算机存储介质不局限于上述几种。上述的系统存储器1004和大容量存储设备1006可以统称为存储器。

根据本公开的各种实施例，该计算机设备1000还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即计算机设备1000可以通过连接在该系统总线1005上的网络接口单元1007连接到网络1008，或者说，也可以使用网络接口单元1007来连接到其他类型的网络或远程计算机系统(未示出)。

该存储器还包括至少一条计算机程序，该至少一条计算机程序存储于存储器中，中央处理器1001通过执行该至少一条计算机程序来实现上述各个实施例所示的方法中的全部或者部分步骤。

在示例性实施例中，还提供了一种芯片，芯片包括可编程逻辑电路和/或程序指令，当芯片在计算机设备上运行时，用于实现上述方面所述的用于游戏进程的RPC处理方法。

在示例性实施例中，还提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器从计算机可读存储介质读取并执行该计算机指令，以实现上述各方法实施例提供的用于游戏进程的RPC处理方法。

在示例性实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，计算机程序由处理器加载并执行以实现上述各方法实施例提供的用于游戏进程的RPC处理方法。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，上述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。