跨进程的游戏角色间的通信方法、存储介质及处理器与流程

本发明涉及网络通信领域，具体而言，涉及一种跨进程的游戏角色间的通信方法、存储介质及处理器。

背景技术：

网络游戏中玩家与玩家之间的通信是必不可少的内容。比较明显的例子如聊天，交易。此外还有大量的其他的业务通信，比如moba(multiplayeronlinebattlearena，多人在线战术竞技游戏)游戏类型中，玩家之间相互点赞，邀请组队，互赠礼物等等。

如今，大型的吃鸡类，moba类型游戏的服务器都是采用分布式架构部署的，也即，服务器采用多服结构，由众多服务器进程同时提供服务，玩家依据一定策略分布在不同的游戏进程。许多传统的网络游戏会采用分区，分服的方式运行。而这种大dau(dailyactiveuser，日活跃用户数量)类型的游戏采用的是一种“大世界”的概念，玩家角度所有玩家都在“一个世界”里面进行游戏，而实际上，玩家是分布在后台不同的服务器进程中。

新的游戏类型发展带来新的架构需求，新的架构下，一些游戏传统的业务也迎来了挑战，比如玩家之间的通信方法。

在传统的单服模式架构下的游戏中，玩家在同一个游戏进程中进行游戏。此时，玩家之间，在服务器进程里面，可以通过id直接获取到对方的内存对象，从而可以直观的进行通信。

而在分布式架构下，从玩家体验上看是同一个游戏世界，而实际上玩家分布在不同的后台游戏进程(称之为game进程)，玩家之间无法直接通信。

为了实现分布式架构下玩家间通信的处理方式主要包括如下两种：第一种是广播在线状态的方式，每个玩家登陆时，把自己的在线状态广播到每个game进程，并在game进程中维持一份代理数据结构，这样，每一个game进程都持有一份在线的玩家的状态，玩家通信时，通过玩家id获取对方玩家的代理，然后进行通信。第二种是通过数据库(database，db)中转的方式，将所有与玩家需要通信的消息直接写入数据库，然后对方玩家通过轮询的方式，从数据库查看是否有新的消息到来，然后进行处理消息。

但是，采用第一种方式进行处理，对玩家的数量限制存在较大的局限，一般只能用于少量game进程共同服务一个区的情况，一旦玩家整体数量级上升，如百万dau类的游戏，服务器的广播消耗和维持玩家代理数据结构的内存消耗都将无法承受。采用第二种方式进行处理，增加db读写的压力；由于db的数据是被动式的，很难定义一个合适的从db拉取消息的策略；消息的响应不够及时，代码重复，工作量大。

针对相关技术中分布在不同进程中的游戏角色之间进行通信的工作量大，资源消耗多的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种跨进程的游戏角色间的通信方法、存储介质及处理器，以至少解决相关技术中分布在不同进程中的游戏角色之间进行通信的工作量大，资源消耗多的技术问题。

根据本发明实施例的一个方面，提供了一种跨进程的游戏角色间的通信方法，包括：获取第一标识信息，其中，第一标识信息为目标进程中的目标游戏角色的标识信息；基于第一标识信息确定第二标识信息，其中，第二标识信息为目标游戏角色当前使用的目标游戏服的标识信息；按照第二标识信息与目标游戏服进行通信交互。

可选地，第一标识信息由第二标识信息，以及预先为目标游戏角色分配的编号构成。

可选地，按照第二标识信息与目标游戏服进行通信交互包括：获取待发送的第一消息；对第一标识信息和第一消息进行封装；将封装后的第一消息发送至目标游戏服。

可选地，基于远程方法调用协议对第一标识信息和第一消息进行封装。

可选地，将封装后的第一消息发送至目标游戏服，包括：获取第一配置参数，其中，第一配置参数为第一消息对应的配置参数；基于第一配置参数确定目标代理；通过目标代理发送封装后的第一消息。

可选地，基于第一配置参数确定目标代理，包括：判断目标进程是否为当前进程，且第一配置参数是否为目标参数；如果目标进程是当前进程，则确定目标代理为本地代理；如果第一配置参数是目标参数，则确定目标代理为安全代理；如果目标进程不是当前进程，且第一配置参数不是目标参数，则确定目标代理为跨进程代理。

可选地，在目标代理为安全代理的情况下，通过目标代理发送封装后的第一消息，包括：将封装后的第一消息存储至数据库；发送第一通知消息至目标游戏服，其中，第一通知消息用于通知数据库中存储有封装后的第一消息。

可选地，第一消息为对目标游戏角色执行目标操作所产生的消息。

可选地，按照第二标识信息与目标游戏服进行通信交互包括：接收目标游戏服发送的第二消息；判断当前游戏角色是否在线；基于判断结果对第二消息执行相应的操作。

可选地，基于判断结果对第二消息执行相应的操作，包括：如果当前游戏角色在线，则解析第二消息，并基于解析后的第二消息操作当前游戏角色；如果当前游戏角色离线，则基于第二配置参数处理第二消息，其中，第二配置参数为第二消息对应的配置参数。

可选地，在基于解析后的第二消息操作当前游戏角色之前，该方法包括：判断解析后的第二消息是否为第二通知消息，其中，第二通知消息用于通知数据库中存储有封装后的第三消息；如果解析后的第二消息不是第二通知消息，则基于解析后的第二消息操作当前游戏角色；如果第二消息是第二通知消息，则从数据库中获取封装后的第三消息，解析封装后的第三消息，并基于解析后的第三消息操作当前游戏角色。

可选地，第二配置参数包括如下之一：安全参数、丢弃参数、回复参数、查询缓存参数和预设参数。

可选地，在第二配置参数为丢弃参数的情况下，基于第二配置参数处理第二消息，包括：丢弃第二消息。

可选地，在第二配置参数为回复参数的情况下，基于第二配置参数处理第二消息，包括：将第二消息存储至数据库，并按照预设方式发送第二通知消息至目标游戏服，其中，第二通知消息在目标游戏角色离线的情况下被丢弃或被存储至数据库。

可选地，在第二配置参数为缓存参数的情况下，基于第二配置参数处理第二消息，包括：判断缓存中是否存在当前游戏角色；如果缓存中存在当前游戏角色，则基于保存参数处理第二消息；如果缓存中不存在当前游戏角色，则将第二消息存储至数据库。

可选地，在第二配置参数为预设参数的情况下，第二配置参数中携带有预设处理方法的标识信息，其中，基于第二配置参数处理第二消息，包括：基于标识信息，获取当前进程的预设处理方法；通过预设处理方法处理第二消息。

可选地，在当前游戏角色重新上线之后，该方法还包括：获取未处理的离线消息；基于离线消息，获取数据库存储的封装后的第三消息；解析封装后的第三消息；基于解析后的第三消息操作当前游戏角色。

根据本发明实施例的另一方面，还提供了一种跨进程的游戏角色间的通信方法，包括：触发当前进程获取到第一标识信息，其中，第一标识信息为目标进程中的目标游戏角色的标识信息；基于第一标识信息与目标游戏服进行通信交互，其中，第一标识信息中携带有目标游戏角色当前使用的目标游戏服的第二标识信息。

根据本发明实施例的另一方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述的跨进程的游戏角色间的通信方法。

根据本发明实施例的另一方面，还提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述的跨进程的游戏角色间的通信方法。

在本发明实施例中，通过在进程之上抽象一个游戏服层，并且通过地址信息设计，使得游戏角色的标识信息可以解析出游戏服的标识信息，因此，可以让不同进程中的玩家之间如同在同一个进程中一样，以直接调用逻辑接口的方式，直观的进行通信，从而可以适配多进程的服务器架构，使得玩家可以跨进程通信，并且适配超大dau的应用场景，使得效率不受dau人数的限制，进而解决了相关技术中分布在不同进程中的游戏角色之间进行通信的工作量大，资源消耗多的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种跨进程的游戏角色间的通信方法的流程图；

图2是根据本发明实施例的另一种跨进程的游戏角色间的通信方法的流程图；

图3是根据本发明实施例的一种跨进程的游戏角色间的通信装置的示意图；以及

图4是根据本发明实施例的另一种跨进程的游戏角色间的通信装置的示意图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本发明实施例，提供了一种跨进程的游戏角色间的通信方法，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的一种跨进程的游戏角色间的通信方法的流程图，如图1所示，该方法包括如下步骤：

步骤s102，获取第一标识信息，其中，第一标识信息为目标进程中的目标游戏角色的标识信息；

步骤s104，基于第一标识信息确定第二标识信息，其中，第二标识信息为目标游戏角色当前使用的目标游戏服的标识信息；

步骤s106，按照第二标识信息与目标游戏服进行通信交互。

可选地，第一标识信息可以由第二标识信息，以及预先为目标游戏角色分配的编号构成。

网络游戏中的玩家之间可以进行业务交互，当前玩家可以通过对其他玩家的游戏角色(即上述的目标游戏角色)进行业务操作，例如，点赞、交易、赠送礼物等，实现玩家间的通信。

在本发明实施例中，以rpc(remoteprocedurecall，远程方法调用的通信方式)通信的方式实现玩家间的通信。在分布式架构下，玩家分布在不同的游戏服务器进程中，为了实现通过rpc通信的方式进行通信，需要确定玩家的“地址信息”。服务器玩家之间的通信，不同于玩家自身客户端与服务器的rpc通信，玩家客户端与服务器由tcp链接，具备清晰的连接关系，但是服务器玩家之间没有实际的物理连接。

在保证服务器进程与进程之间能够通信的基础上，本发明实施例在进程上抽象了一个游戏服gameservice层，每个gameservice运行在一个game进程上，因此，gameservice和game进程具备一对一的映射关系。并且为每个gameservice分配一个编号serv_id(也即游戏服的标识信息)，并且定制开服的配置脚本中分配gameservice与进程的绑定关系。并且，进程之间的rpc通过一定设计，实现基于gameservice的rpc通信，其中，serv_id为gameservice的路由信息，只要获得serv_id，即可将消息发往该gameservice。

创建玩家角色时，可以进行预先规划，例如每个serv_id可以服务10万玩家，则player_guid(也即游戏角色的标识信息)为serv_id*100000+increment_player_id(也即为游戏角色分配的编号)，其中，increment_player_id自增计数。例如，serv_id＝1001，其第一个玩家player_guid为100100000，第10万个玩家player_guid为100199999。在此基础上，player_guid具有唯一性，并且，在拿到一个player_guid之后，可以使用player_guid/100000方便的计算出serv_id。

在此基础上，通过抽象了不同进程之间：hall_player到hall_player的直接方法上的通信，使得无论玩家是否在线都能够正确、方便的处理。因此，对于业务的编写人员可以避免陷入，例如寻找对方服务器，查找玩家是否在线并分情况处理的各种细节。直接以类似同一个进程中在线交互的情况进行处理。

在一种可选的实施例中，当前玩家与目标玩家之间进行通信时，可以获取到目标玩家的目标游戏对象的player_guid，进一步可以解析得到gameservice的serv_id，通过serv_id可以与gameservice进行通信交互，由gameservice基于player_guid与目标游戏对象进行通信交互，从而实现基于gameservice实现玩家与玩家之间的通信。

通过本发明上述实施例，通过在进程之上抽象一个游戏服层，并且通过地址信息设计，使得游戏角色的标识信息可以解析出游戏服的标识信息，因此，可以让不同进程中的玩家之间如同在同一个进程中一样，以直接调用逻辑接口的方式，直观的进行通信，从而可以适配多进程的服务器架构，使得玩家可以跨进程通信，并且适配超大dau的应用场景，使得效率不受dau人数的限制，进而解决了相关技术中分布在不同进程中的游戏角色之间进行通信的工作量大，资源消耗多的技术问题。

可选地，按照第二标识信息与目标游戏服进行通信交互包括：获取待发送的第一消息；对第一标识信息和第一消息进行封装；将封装后的第一消息发送至目标游戏服。

其中，第一消息可以为对目标游戏角色执行目标操作所产生的消息。上述的目标操作可以是玩家针对不同业务(包括但不限于聊天、交易、点赞、组队、赠送礼物等)进行的操作。

在一种可选的实施例中，当前玩家在游戏过程中，可以对目标玩家的目标游戏角色进行操作，并生成相应的消息(即上述的第一消息)。玩家间的通信可以通过rpc通信的方式实现，也即可以基于rpc协议对需要发送的消息和player_guid进行封装，得到rpc消息(即上述封装后的第一消息)，进一步发送给serv_id对应的gameservice。

本发明实施例采用的封装方法可以让使用这个接口编写业务逻辑的开发人员能够以自然，简单的方式调用。例如，以a玩家给b玩家点赞为例进行说明，假设一局战斗之后，a玩家给b玩家点赞，则a服务器收到客户端请求之后，需要向b玩家的服务器发送跨进程的通信请求，调用如下：

playera.hall_player(playerb_guid).onlike(playera_guid)

其中，playera可以是玩家a所在进程中a的内存实体对象；hall_player是跨进程调用的关键方法，由于游戏的主要逻辑进程叫大厅进程，因此被称为“hall”；playerb_guid是b玩家的唯一编号，这个id全局唯一，并且可以解析出b玩家所在serv_id信息，既可以转化为玩家的地址信息addr＝(serv_id,player_guid)；onlike可以是实现在玩家player对象上的普通方法，实现玩家被另一个玩家点赞的逻辑；playera_guid，表示玩家b被谁点赞。

hall_player可以实现为玩家player对象上的一个方法，在实际过程中，hall_player可以是一个简单的代理方法，真正的实现将转交给hall_player模块：

defhall_player(self,to_guid,**kwargs):

from_guid＝self.guid

returnhall_player.hall_player(self,to_guid,from_guid,**kwargs)

其中，kwargs为可选的配置参数。

由上可知，实现在player身上的hall_player成员方法，可以是将自己的addr信息加入，标明通信消息的发送源头，然后调用真正的hall_player实现。并且，任何实现在玩家player类上的业务方法，都可以使用hall_player的方式调用。

hall_player的内部实现封装了整个过程：可以将onlike方法名，onlike方法使用的参数，自动序列化成数据流，发送给对方player所在进程，然后再反向解析，找到playerb内存对象，在执行相应的业务方法。

需要说明的是，整个底层的实现过程对于上层业务开发者来说都是透明的，业务开发者只需要知道对方的player_guid和目标业务方法，即可顺畅的编写代码。并且业务逻辑方法是直接实现在player身上的原生方法，不需要为hall_player方法调用做任何额外的工作。因此，本发明实施例提供的方案不会增加实现player本身接口逻辑的负担，例如player身上实现了funca、funcb和funcc，使用hall_player通信后，这些接口不需要任何改变，不增加任何工作量，另一个其他进程的玩家就可以直观的通过hall_player(guid).funca(…)的方式进行调用。

可选地，将封装后的第一消息发送至目标游戏服，包括：获取第一配置参数，其中，第一配置参数为第一消息对应的配置参数；基于第一配置参数确定目标代理；通过目标代理发送封装后的第一消息。

在一种可选的实施例中，真正的hall_player方法实现代码如下：

由上可知，hall_player方法所做的是根据当前环境，返回不同的hall_player的代理对象(即上述的目标代理)。从而体现了使用hall_player方法，屏蔽了底层实现的差异性，上层接口的使用者，使用的都是统一的hall_player方式。

上述所有的hall_player对象都继承自hallplayerproxybase基类，基类实现要点如下：

从而实现了playera.hall_player(playerb_guid).onlike(playera_guid)调用的整个过程。

需要说明的是，__getattr__是python语言提供的一个特性方法，当对象的成员时，如果该成员没有明确定义，则会走执行该方法。__getattr__实现在proxy代理类中，例如，hall_player(guid).onlike(args)中，hall_player(guid)首先返回了一个proxy，则调用变成proxy.onlike(args)，因为onlike方法是目标playerb身上实现的方法，proxy并没有实现，因此会执行proxy的__getattr__方法，其中参数name就是目标方法‘onlike’这个方法名。proxy的__getattr__返回一个caller，也即实际是caller(args)，该方法会将name、args打包成rpc_msg，通过call_service_rpc发送处理。

另外，self.send_service是proxy实例化的传入的初始化参数，可以将其作为一个能发送rpc的对象。

可选地，基于第一配置参数确定目标代理，包括：判断目标进程是否为当前进程，第一且配置参数是否为目标参数；如果目标进程是当前进程，则确定目标代理为本地代理；如果第一配置参数是目标参数，则确定目标代理为安全代理；如果目标进程不是当前进程，且第一配置参数不是目标参数，则确定目标代理为跨进程代理。

具体地，上述的当前进程可以是当前玩家的当前游戏角色所在的进程。目标参数可以是安全参数，也即，配置中指明了需要“安全”模式进行通信，确保信息不回丢失。

local_hall_player：本地的hall_player代理(即上述的本地代理)，当发现接收方与发送方在同一个进程时，直接本地通信，而不用通过本地发送。同时具备一定优化作用。

safe_hall_player：当配置中指明了这种方式需要“安全”的保证消息不丢时，使用安全的hall_player代理(即上述的安全代理)，这种模式下，会把消息存储到数据库，然后再通知对端处理。因为进程之间的消息可能由于各种原因丢失，如断线，死机等等，这种方式保证消息必然会被处理。

other_hall_player：当消息需要直接发往其他进程时使用的代理(即上述的跨进程代理)。

需要说明的是，上述方案针对hall_player消息发送流程，整个流程中的发送端为playera，下面方案针对hall_player消息接收流程，整个流程中的发送端为playerb。

可选地，在目标代理为安全代理的情况下，通过目标代理发送封装后的第一消息，包括：将封装后的第一消息存储至数据库；发送第一通知消息至目标游戏服，其中，第一通知消息用于通知数据库中存储有封装后的第一消息。

上述的第一通知消息可以通知目标玩家，当前玩家发来了消息，并且存储在数据库中，例如，第一通知消息可以是“您有新的消息，请自己去拉取数据库处理”，但不仅限于此。

在一种可选的实施例中，安全代理的作用可以是先将封装后的第一消息存储到数据库，然后在通知目标玩家。在此基础上，即使第一通知消息在传输过程中丢失，目标玩家也可以通过定时检查数据库中是否有消息需要处理的方式，实现对封装后的第一消息进行处理的目的，因此，消息传输不依赖于网络通信的安全。

可选地，按照第二标识信息与目标游戏服进行通信交互包括：接收目标游戏服发送的第二消息；判断当前游戏角色是否在线；基于判断结果对第二消息执行相应的操作。

具体地，上述的第二消息可以是目标玩家与当前玩家进行通信的rpc消息。

在一种可选的实施例中，当消息通过rpc发送过来时，首先，playera所在进程的gameservice收到消息，playera并不会直接处理。此时，面临两种情况：playera的玩家在线；playera的玩家不在线。由于rpc消息是跨进程的、异步的，发送端对接收端玩家的在线状态没有任何保证，玩家a不在线的情况也很普遍。因此，需要针对不同情况，对rpc消息进行不同处理。

需要说明的是，对于玩家player的生命周期来说，player不具备进程生命周期(在进程启动时候，对象同时初始化，直至进程结束)，而是与玩家行为相关的，具体为玩家登陆游戏，游戏进程才会创建player对象，从db加载数据到内存，玩家下线，player就会被销毁。因此，hall_player消息的接收，不能实现在玩家player身上，而必须实现在一个具备进程级的生命周期的对象上，也就是每个进程都有的gameservice对象。具体为在进程启动后，就是初始化，并一直保留在内存，监听其他进程或客户端发送的game进程的请求。

可选地，基于判断结果对第二消息执行相应的操作，包括：如果当前游戏角色在线，则解析第二消息，并基于解析后的第二消息操作当前游戏角色；如果当前游戏角色离线，则基于第二配置参数处理第二消息，其中，第二配置参数为第二消息对应的配置参数。

在一种可选的实施例中，hall_player跨进程通信可以与离线消息处理系统天然的互相契合。如果playera玩家在线，则可以直接解包数据，通过playera_guid找到玩家a的内存对象，并直接业务逻辑处理即可。如果playera玩家不在线，则基于第二配置参数处理消息，生成离线消息。

消息的接收基于rpc的底层实现，对应的rpc方法为：

以消息conf发送时的配置参数kwargs为例进行说明，kwargs可以是在发送端控制词条hall_playermsg的定制化功能，使用key＝value方式配置。可选地，该第二配置参数可以包括如下之一：安全参数(safe)、丢弃参数(drop)、回复参数(ack)、查询缓存参数(try_cache)和预设参数(custom)。

可选地，在基于解析后的第二消息操作当前游戏角色之前，该方法包括：判断解析后的第二消息是否为第二通知消息，其中，第二通知消息用于通知数据库中存储有封装后的第三消息；如果解析后的第二消息不是第二通知消息，则基于解析后的第二消息操作当前游戏角色；如果第二消息是第二通知消息，则从数据库中获取封装后的第三消息，解析封装后的第三消息，并基于解析后的第三消息操作当前游戏角色。

上述的第三消息可以是目标玩家实际需要发送给当前玩家的消息，也即，是对当前游戏角色执行目标操作所产生的消息。

需要说明的是，如果目标玩家采用普通模式发送消息，则第二消息可以是封装后的实际消息；如果目标玩家希望采用安全模式发送消息，则第二消息可以是第二通知消息，通知当前玩家，目标玩家发来了消息，并且存储在数据库中，例如，第二通知消息也可以是“您有新的消息，请自己去拉取数据库处理”，但不仅限于此。

在此基础上，可以实现判断解析后的第二消息是否是目标玩家实际需要发送给当前玩家的消息，如果是，则直接基于解析后的第二消息操作当前游戏角色；如果否，也即，解析后的第二消息用于通知当前玩家，目标玩家发来了消息，则需要从数据库中读取封装后的第三消息，并通过解析得到实际需要发送给当前玩家的消息，进一步基于解析后的第三消息操作当前游戏角色。

需要说明的是，对于安全参数，由于接收到的仅仅是第二通知消息，实际需要发送的消息已经存储在数据库中，因此，无需进行任何处理。

可选地，在第二配置参数为丢弃参数的情况下，基于第二配置参数处理第二消息，包括：丢弃第二消息。

在一种可选的实施例中，当kwargs为drop时，如果当前玩家不在线，则直接丢弃。

可选地，在第二配置参数为回复参数的情况下，基于第二配置参数处理第二消息，包括：将第二消息存储至数据库，并按照预设方式发送第二通知消息至目标游戏服，其中，第二通知消息在目标游戏角色离线的情况下被丢弃或被存储至数据库。

在一种可选的实施例中，目标玩家在发送消息的同时，可以设置ack参数。如果当前玩家不在线，当kwargs为ask时，则可以直接将第二消息存储至数据库，并按照指定的方法通知目标玩家。例如，从第二消息中解析出ack消息，并采用hall_player消息的方式，发送ack消息给目标玩家。

以赠送好友礼物的场景为例进行说明，如果好友不在线，则好友所在进程会回复一条消息通知发送方，例如，告诉对方“你的好友不在线，上线后会自动收到您的礼物”，发送方所在进程收到ack消息，对该消息进行处理。

当ask消息返回时，如果目标玩家离线，则默认情况下直接丢弃掉该消息；如果目标玩家希望不丢弃该消息，则可以在发送消息的同时携带ack_no_drop参数，从而目标游戏服可以将该消息处理为离线消息。

需要说明的是，上述的通知消息默认为离线丢弃，也即，如果目标玩家不在，则直接丢弃该通信消息，并返回发送者离线的消息。

可选地，在第二配置参数为缓存参数的情况下，基于第二配置参数处理第二消息，包括：判断缓存中是否存在当前游戏角色；如果缓存中存在当前游戏角色，则基于保存参数处理第二消息；如果缓存中不存在当前游戏角色，则将第二消息存储至数据库。

在一种可选的实施例中，缓存只是玩家离线之后，对player对象的一种处理策略，会有算法机制更新缓存，比如最多缓存最近下线的1000个玩家，或者每个玩家对象只在离线后保留60分钟，这样玩家短期内再次上线就不用从数据库拉取数据而直接读取缓存了。因此，当kwargs为try_cache时，可以从cache中查找当前玩家的player，如果找到，当做在线信息处理，并配合参数save，也即，如果cache中找到，操作之后，调用player_avatar的save方法保存第二消息。如果未找到，则直接将第二消息存储至数据库。

可选地，在第二配置参数为预设参数的情况下，第二配置参数中携带有预设处理方法的标识信息，其中，基于第二配置参数处理第二消息，包括：基于标识信息，获取当前进程的预设处理方法；通过预设处理方法处理第二消息。

上述的标识信息可以是custom参数中携带的预处理方法的方法名，但不仅限于此。例如，custom的完整数据是{‘custom’:’funcofhalllogic}，其中funcofhalllogic是实现在hall_logic模块上的预设处理方法，而不是player_logic(执行主体不是player，而是gameservice)，hall_logic是gameservice的逻辑功能扩展代码。

在一种可选的实施例中，当kwargs为custom时，如果对方不在线，则仍然需要立即处理，具体处理方式如下：在当前进程运行指定的hall_logic上的方法，当玩家不在线并且该消息指定了custom，则调用gameservice.funcofhalllogic()方法。

例如b给a发送hall_player消息赠送一个贵重礼物，但是a不在线，此时仍然需要发送全部通告，广播给所有客户端这个赠送消息。则可以通过制定custom的方式实现“广播通告”这个逻辑，这个逻辑不需要a在线。

需要说明的是，对于大多数的默认情况，离线消息会存储到db，并且这个转存过程中不再需要额外的序列化，直接把收到的msg存储即可，这体现了hall_player与离线消息的无缝结合，因为hall_player具备处理任何玩家身上的业务方法的能力，离线消息自然也具备这个能力。

可选地，在当前游戏角色重新上线之后，该方法还包括：获取未处理的离线消息；基于离线消息获取数据库存储的封装后的第三消息；解析封装后的第三消息；基于解析后的第三消息操作当前游戏角色。

在一种可选的实施例中，当玩家再次上线时，会在加载player对象完成之后，再从离线消息的数据库表中拉取到离线消息。拉取之后，执行这条消息：

defofflinemsgrunafterload(self,save_msg):

self.runhallplayermsg(msg,reason＝'after_load')

需要说明的是，此处真正执行的方式，与在线玩家收到hall_player消息时使用的接口是一致的，从而实现了对hall_player消息的在线和离线处理，基本上可以应付所有的跨进程业务的需求。

通过上述方案，实现了一种跨进程的，相对完善、高效的玩家间通信方法，可以让玩家之间如同在同一个进程中一样，以直接调用逻辑接口的方式，直观的进行通信，并能在玩家不在线时的转化为离线消息，待上线后自动处理该消息，同时保证消息不丢失的可靠模式和可选的优化策略。因此，具有如下优点：适配多进程的服务器架构，玩家跨进程通信；适配超大dau的应用场景，通信的效果效率不受dau人数限制；透明化通信，玩家在使用通信接口时，与同进程的玩家通信保持一致；高效通信，玩家间通知仅受实际通信的成本影响(跨进程，网络通信)，不会给db带来额外压力；即时性，玩家之间能够即时通信，其过程就是一次跨进程的网络通信，同进程的情况下自动适配的本地内存通信；对于对方玩家不在线的情况，自动处理离线消息；提供丰富可选的安全策略，兼顾可靠性与效率优化；可以处理玩家身上任意消息，实现脚本语言的“任意方法既可作为消息”。

实施例2

根据本发明实施例，还提供了一种跨进程的游戏角色间的通信方法。

图2是根据本发明实施例的另一种跨进程的游戏角色间的通信方法的流程图，如图2所示，该方法包括如下步骤：

步骤s202，触发当前进程获取到第一标识信息，其中，第一标识信息为目标进程中的目标游戏角色的标识信息；

步骤s204，基于第一标识信息与目标游戏服进行通信交互，其中，第一标识信息中携带有目标游戏角色当前使用的目标游戏服的第二标识信息。

在一种可选的方案中，当前玩家需要与目标玩家进行业务交互时，该玩家可以对游戏中目标游戏角色进行操作，触发当前进程获取到目标游戏角色的player_guid，实现了仅仅输入目标游戏角色的player_guid，即可实现跨进程的玩家间的通信的目的。

需要说明的是，本实施例中步骤s204的具体实现方式和优选的实施例与上述实施例1中步骤s104至步骤s106相同，在此不做赘述。

实施例3

根据本发明实施例，提供了一种跨进程的游戏角色间的通信装置，该装置可以执行上述实施例1中提供的跨进程的游戏角色间的通信方法，具有实现方式和优选实施例在此不做赘述。

图3是根据本发明实施例的一种跨进程的游戏角色间的通信装置的示意图，如图3所示，该装置包括：

第一获取模块32，用于获取第一标识信息，其中，第一标识信息为目标进程中的目标游戏角色的标识信息；

确定模块34，用于基于第一标识信息确定第二标识信息，其中，第二标识信息为目标游戏角色当前使用的目标游戏服的标识信息；

通信模块36，用于按照第二标识信息与目标游戏服进行通信交互。

可选地，通信模块包括：获取单元，用于获取待发送的第一消息；封装单元，用于对第一标识信息和第一消息进行封装；发送单元，用于将封装后的第一消息发送至目标游戏服。

可选地，发送单元包括：获取子单元，用于获取第一配置参数，其中，第一配置参数为第一消息对应的配置参数；确定子单元，用于基于第一配置参数确定目标代理；发送子单元，用于通过目标代理发送封装后的第一消息。

可选地，确定子单元还用于判断目标进程是否为当前进程，且第一配置参数是否为目标参数，其中，如果目标进程是当前进程，则确定目标代理为本地代理；如果第一配置参数是目标参数，则确定目标代理为安全代理；如果目标进程不是当前进程，且第一配置参数不是目标参数，则确定目标代理为跨进程代理。

可选地，在目标代理为安全代理的情况下，发送子单元还用于将封装后的第一消息存储至数据库，并发送第一通知消息至目标游戏服，其中，第一通知消息用于通知数据库中存储有封装后的第一消息。

可选地，通信模块包括：接收单元，用于接收目标游戏服发送的第二消息；判断单元，用于判断当前游戏角色是否在线；执行单元，用于基于判断结果对第二消息执行相应的操作。

可选地，执行单元包括：解析子单元，用于如果当前游戏角色在线，则解析第二消息，并基于解析后的第二消息操作当前游戏角色；处理子单元，用于如果当前游戏角色离线，则基于第二配置参数处理第二消息，其中，第二配置参数为第二消息对应的配置参数。

可选地，执行单元还包括：判断子单元，用于判断解析后的第二消息是否为第二通知消息，其中，第二通知消息用于通知数据库中存储有封装后的第三消息；操作子单元，用于如果解析后的第二消息不是第二通知消息，则基于解析后的第二消息操作当前游戏角色；解析子单元还用于如果第二消息是第二通知消息，则从数据库中获取封装后的第三消息，解析封装后的第三消息，并基于解析后的第三消息操作当前游戏角色。

可选地，处理子单元还用于在第二配置参数为丢弃参数的情况下，丢弃第二消息。

可选地，处理子单元还用于在第二配置参数为回复参数的情况下，按照预设方式发送第二通知消息至目标游戏服，接收目标游戏服返回的应答消息，并基于应答消息对第二消息进行处理。

可选地，处理子单元还用于在应答消息为目标游戏角色在线的情况下，将第二消息存储至数据库；在应答消息为目标游戏角色离线的情况下，丢弃第二消息。

可选地，处理子单元还用于在第二配置参数为缓存参数的情况下，判断缓存中是否存在当前游戏角色，其中，如果缓存中存在当前游戏角色，则基于保存参数处理第二消息；如果缓存中不存在当前游戏角色，则将第二消息存储至数据库。

可选地，处理子单元还用于在第二配置参数为预设参数的情况下，基于第二配置参数中携带的预设处理方法的标识信息，获取当前进程的预设处理方法，并通过预设处理方法处理第二消息。

可选地，该装置还包括：接收模块，用于在当前游戏角色重新上线之后，获取未处理的离线消息；第二获取模块，用于基于离线消息获取数据库存储的第二消息；解析模块，用于解析封装后的第三消息；操作模块，用于基于解析后的第三消息操作当前游戏角色。

实施例4

根据本发明实施例，提供了一种跨进程的游戏角色间的通信装置，该装置可以执行上述实施例2中提供的跨进程的游戏角色间的通信方法，具有实现方式和优选实施例在此不做赘述。

图4是根据本发明实施例的另一种跨进程的游戏角色间的通信装置的示意图，如图4所示，该装置包括：

触发模块42，用于触发当前进程获取到第一标识信息，其中，第一标识信息为目标进程中的目标游戏角色的标识信息；

通信模块44，用于基于第一标识信息与目标游戏服进行通信交互，其中，第一标识信息中携带有目标游戏角色当前使用的目标游戏服的第二标识信息。

需要说明的是，本实施例中通信模块44的具体实现方式和优选的实施例与上述实施例3中确定模块34和通信模块36等两个模块相同，在此不做赘述。

实施例5

根据本发明实施例，提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述实施例1和2中的跨进程的游戏角色间的通信方法。

实施例6

根据本发明实施例，提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述实施例1和2中的跨进程的游戏角色间的通信方法。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。