一种消息分发方法、装置、服务端及存储介质与流程

1.本技术涉及网络通信技术的领域，尤其是涉及一种消息分发方法、装置、服务端及存储介质。


背景技术：

2.传统的消息分发是在服务端接收到客户端的任务消息后，将任务消息存储至一个总消息队列中，工作线程将任务消息从总消息队列中取出并判断出任务消息所属的类型，根据任务消息的类型，将对应的任务消息进行消息分发处理。
3.但是，通过一个总消息队列对任务消息进行存储和调取，意味包含有所有不同类型的任务消息都将基于该总消息队列的存储调取规则进行消息的分发，若在任务消息数量过多时，总消息队列内存储空间会被占满，导致队列爆栈，并且还可能造成任务消息分发的延迟，影响消息分发的效率。


技术实现要素：

4.为了提高消息分发效率，本技术提供一种消息分发方法、装置、服务端及存储介质。
5.第一方面，本技术提供一种消息分发方法，采用如下的技术方案：一种消息分发方法，包括：当接收到生产端发送的任务消息时，确定所述任务消息对应的消息类型；基于所述消息类型，将所述任务消息存储至对应的队列；当接收到消费端发送的消息调取指令时，基于所述消息调取指令，确定待调取的任务消息对应的消息类型，以及所述消息类型对应的队列；从所述消息类型对应的队列中调取任务消息。
6.通过采用上述技术方案，对接收到生产端发送的任务消息进行类型确认，确定出对应的消息类型，以对接收到的任务消息进行类别划分，随后，基于消息类型确定出任务消息所要存储的队列，并将任务消息存储到该队列中，以实现对接收到的任务消息进行分类存储；相对于将所有的消息均存储在一个总队列中，可以降低队列爆栈的情况效率，进一步地，在调取队列中存储的任务消息时，通过从对应消息类型的队列中调取对应的任务消息，也可以降低任务消息分发所消耗的时间，进而可以提高消息分发的效率。
7.在一种可能的实现方式中，所述确定所述任务消息对应的消息类型，包括：根据所述任务消息中携带的key以及key与消息类型之间的对应关系，确定所述任务消息对应的消息类型；或者，根据所述任务消息确定所述任务消息对应的key，并基于所述任务消息对应的key以及所述key与消息类型之间的对应关系，确定所述任务消息对应的消息类型。
8.通过采用上述技术方案，在确定任务消息对应的消息类型进而确定任务消息对应的优先等级时，在一种可能的实现方式中，可以根据任务消息中携带的key，确定任务消息
对应的消息类型，在另一种可能的实现方式中，还可以在获取到任务消息时，根据任务消息确定消息对应的key，之后再确定任务消息对应的消息类型，从而可以为确定消息类型提供了两种可能的实现方式。
9.在一种可能的实现方式中，所述队列包含写队列和读队列，所述写队列为具备写入权限的消息队列，所述读队列为具备读权限的消息队列；所述基于所述消息类型，将所述任务消息存储至对应的队列，包括：根据所述消息类型，将所述任务消息存储至对应的写队列；其中，从所述消息类型对应的队列中调取消息，包括：从所述消息类型对应的读队列中调取消息。
10.通过采用上述技术方案，一个消息类型至少对应的一个写队列和一个读队列，其中，写队列中用于写入对应消息类型的任务消息，读队列用于读取对应消息类型的任务消息，也就是说，同一消息类型的任务消息也可以通过至少一个写队列和至少一个读队列暂存，可以进一步地降低爆栈的可能性，并且同一消息类型中的写队列和读队列分别负责该类型消息的写入和读取，也可以进一步地降低消息分发的延迟，提升消息分发的效率。
11.在一种可能的实现方式中，所述基于所述消息调取指令确定待调取的任务消息对应的消息类型，以及所述消息类型对应队列，之后还包括：判断所述读队列内存储任务消息的数量是否不大于第一预设数量，若是，则判断对应的写队列内的任务消息的数量是否超出第二预设数量，所述对应的写队列与所述读队列存在对应关系；若是，则将所述对应写队列中存储的第二预设数量的任务消息转移至所述读队列；若否，则将所述写队列中存储的所有任务消息转移至所述读队列内。
12.通过采用上述技术方案，当读队列中存储的消息数量较少甚至为0时，将写队列中存储的任务消息转移至该读队列中，以使得可以从读队列中快速读取任务消息，从而可以降低从读队列中读取任务消息延迟；再者，当写队列中超出第二预设数量，仅将第二预设数量的任务消息转移至读队列，可以进一步地降低转移过程中可能导致的读队列爆栈的概率。
13.在一种可能的实现方式中，所述方法还包括：若任一写队列中存储的任务消息数量不小于第三预设数量，则确定所述任一写队列对应的读队列中存储的任务消息的数量；判断所述对应的读队列中存储的任务消息数量是否不小于第四预设数量；若否，则从所述任一写队列中获取待转移的任务消息，并将所述待转移的任务消息转移至对应的读队列中。
14.通过采用上述技术方案，当写队列中存储的任务消息数量较多，且其对应的读队列中存储的任务消息较少时或者有多余的存储空间时，将写队列中的部分任务消息转移至读队列中，可以降低一直写入导致写队列爆栈的可能性，进而可以提高消息分发的概率。
15.在一种可能的实现方式中，所述判断所述对应的读队列中存储的任务消息数量是否不小于第四预设数量，之后还包括：若所述对应的读队列中存储的任务消息数量不小于第四预设数量，且接收到待写
入的任务消息时，确定所述待写入的任务消息的重要等级；若所述重要等级不属于预设等级，则将所述待写入的任务消息抛弃；若所述重要等级属于预设等级时，则将所述待写入的任务消息对应的写队列内的缓存空间增大。
16.通过采用上述技术方案，当读队列以及其对应的写对应中存储的任务消息数量均较多时，且此时接收到的任务消息重要等级较低时，通过抛弃该任务消息，可以在降低写队列爆栈可能性的同时避免对游戏运行等造成影响；再者若此时接收到的任务消息重要等级较高时，增大写队列的缓存空间，也可以在降低写队列爆栈可能性的同时降低对游戏运行等造成的影响，进一步地还可以提升用户体验。
17.在一种可能的实现方式中，所述方法还包括：当任一写队列中存储的任务消息数量大于第五预设数量时，将所述任一写队列的权限由写入变更为读取。
18.通过采用上述技术方案，当写队列中存储的任务消息数量较多时，通过将该写队列的权限变更读取，可以避免后续一直写入消息造成该读队列爆栈的情况发生，而且通过将写队列的权限直接变更为读取，相对于将任务消息从写队列转移至读队列，可以进一步地提高队列消息交换的效率。
19.在一种可能的实现方式中，所述确定所述任务消息对应的消息类型，之后还包括：确定所述消息类型对应的处理等级，所述处理等级为表征消息处理的实时性要求的等级；若所述处理等级属于预设的实时等级，则回调所述任务消息。
20.通过采用上述技术方案，当接收到的任务消息的处理等级所对应的实时性要求较高时，直接进行回调处理，可以提高实时性要求高的消息的处理效率，避免消息延迟，进一步地可以提升用户体验。
21.第二方面，本技术提供一种消息分发装置，采用如下的技术方案：一种消息分发装置，包括：消息类型确定模块、消息存储模块、第一确定模块以及消息调取模块，其中，消息类型确定模块，用于当接收到生产端发送的任务消息时，确定所述任务消息对应的消息类型；消息存储模块，用于基于所述消息类型，将所述任务消息存储至对应的队列；第一确定模块，用于当接收到消费端发送的消息调取指令时，基于所述消息调取指令，确定待调取的任务消息对应的消息类型，以及所述消息类型对应的队列；消息调取模块，用于从所述消息类型对应的队列中调取任务消息。
22.通过采用上述技术方案，消息类型确定模块对接收到生产端发送的任务消息进行类型确认，确定出对应的消息类型，以对接收到的任务消息进行类别划分，随后，消息存储模块基于消息类型确定出任务消息所要存储的队列，并将任务消息存储到该队列中，以实现对接收到的任务消息进行分类存储；相对于将所有的消息均存储在一个总队列中，可以降低队列爆栈的情况效率，进一步地，消息调取模块在调取队列中存储的任务消息时，通过从第一确定模块确定的对应消息类型的队列中调取对应的任务消息，也可以降低任务消息分发所消耗的时间，进而可以提高消息分发的效率。
23.在一种可能的实现方式中，所述消息类型确定模块在确定所述任务消息对应的消息类型时，具体用于：根据所述任务消息中携带的key以及key与消息类型之间的对应关系，确定所述任务消息对应的消息类型；或者，根据所述任务消息确定所述任务消息对应的key，并基于所述任务消息对应的key以及所述key与消息类型之间的对应关系，确定所述任务消息对应的消息类型。
24.在一种可能的实现方式中，所述队列包含写队列和读队列，所述写队列为具备写入权限的消息队列，所述读队列为具备读权限的消息队列；所述消息存储模块在基于所述消息类型，将所述任务消息存储至对应的队列，具体用于：根据所述消息类型，将所述任务消息存储至对应的写队列；其中，消息调取模块在从所述消息类型对应队列中调取消息时，具体用于：从所述消息类型对应的读队列中调取消息。
25.在一种可能的实现方式中，所述装置还包括：第一判断模块、第二判断模块、第一消息转移模块以及第二消息转移模块，其中，第一判断模块，用于判断所述读队列内存储任务消息的数量是否不大于第一预设数量；第二判断模块，用于当所述读队列内存储任务消息的数量不大于第一预设数量时，判断对应的写队列内的任务消息的数量是否超出第二预设数量，所述对应的写队列与所述读队列存在对应关系；第一消息转移模块，用于当对应的写队列内的任务消息的数量超出第二预设数量时，将所述对应写队列中存储的第二预设数量的任务消息转移至所述读队列；第二消息转移模块，用于当对应的写队列内的任务消息的数量未超出第二预设数量时，将所述写队列中存储的所有任务消息转移至所述读队列内。
26.在一种可能的实现方式中，所述消息分发装置，还包括：第二确定模块、第三判断模块以及第三消息转移模块，其中，第二确定模块，用于若任一写队列中存储的任务消息数量不小于第三预设数量，则确定所述任一写队列对应的读队列中存储的任务消息的数量；第三判断模块，用于判断所述对应的读队列中存储的任务消息数量是否不小于第四预设数量；所述第三消息转移模块，用于当所述对应的读队列中存储的任务消息数量未不小于第四预设数量时，从所述任一写队列中获取待转移的任务消息，并将所述待转移的任务消息转移至对应的读队列中。
27.在一种可能的实现方式中，所述装置还包括：消息等级确定模块、消息抛弃模块以及缓存空间增大模块，其中，消息等级确定模块，用于当所述对应的读队列中存储的任务消息数量不小于第四预设数量，且接收到待写入的任务消息时，确定所述待写入的任务消息的重要等级；消息抛弃模块，用于当所述重要等级不属于预设等级时，将所述待写入的任务消息抛弃；缓存空间增大模块，用于当所述重要等级属于预设等级时，将所述待写入的任务
消息对应的写队列内的缓存空间增大。
28.在一种可能的实现方式中，所述消息分发装置，还包括：权限变更模块，其中，权限变更模块，用于当任一写队列中存储的任务消息数量大于第五预设数量时，将所述任一写队列的权限由写入变更为读取。
29.在一种可能的实现方式中，所述装置还包括：消息等级处理模块以及消息回调模块，其中，消息等级处理模块，用于确定所述消息类型对应的处理等级，所述处理等级为表征消息处理的实时性要求的等级；消息回调模块，用于当所述处理等级属于预设的实时等级时，回调所述任务消息。
30.第三方面，本技术提供一种服务端，采用如下的技术方案：一种服务端，该服务端包括：至少一个处理器；存储器；至少一个应用程序，其中至少一个应用程序被存储在存储器中并被配置为由至少一个处理器执行，所述至少一个应用程序配置用于：执行上述消息分发的方法。
31.第四方面，本技术提供一种计算机可读存储介质，采用如下的技术方案：一种计算机可读存储介质，包括：存储有能够被处理器加载并执行上述消息分发方法的计算机程序。
32.综上所述，本技术包括以下有益技术效果：1、确定接收到生产端发送的任务消息对应的消息类型，后基于消息类型确定出任务消息所要存储的队列，并将任务消息存储到该队列中，进而减小了队列爆栈的几率。
33.2、在调取队列中存储的任务消息时，从对应消息类型的队列中调取对应的任务消息，从而减低任务消息分发所消耗的时间，继而提高了消息分发的效率。
附图说明
34.图1是本技术实施例提供了一种消息分发方法的流程示意图；图2是本技术实施例提供了一种消息分发装置的结构示意图；图3是本技术实施例提供在消息分发方法的示例图；图4是本技术实施例提供了一种服务端的装置结构示意图。
具体实施方式
35.以下结合附图1-4对本技术作进一步详细说明。
36.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
37.为了方便理解本技术提出的技术方案，首先在此介绍本技术描述中会引入的要素。应理解的是，以下介绍仅方便理解这些要素，以期理解本技术实施例的内容，并非一定涵盖所有可能的情况。
38.key：又称键值，位于注册表结构链末端，包含当前应用程序执行时使用的实际配置信息和数据。每个消息对应有一个唯一确定的key。key可以是消息对应的消息名称，还可以是其他用户自定义的键值。
39.本技术实施例提供了一种消息分发方法，由服务端执行，其中，该服务端可以为服务器也可以为终端设备，其中，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此，该终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本技术实施例在此不做限制。
40.参照图1，该方法可以包括：步骤s101、步骤s102、步骤s103以及步骤s104，其中，步骤s101、当接收到生产端发送的任务消息时，确定任务消息对应的消息类型。
41.对于本技术实施例，生产端属于客户端，用于生成参与到任务分发过程的任务消息。
42.对于本技术实施例，任务消息可以包含音频数据、视频数据、输入设备的数据等；其中，音频数据、视频数据以及输入设备的数据等数据内容存在不同，且数据格式也存在差异，基于数据之间的区别，服务端可以基于接收到的任务消息确定出任务消息对应的消息类型。例如，在通过手机、电脑以及平板等具备显示功能的终端设备为使用者提供游戏游玩服务的云游戏应用场景中，使用者借助上述终端设备自带的功能键或外连接的操控设备将音频数据、视频数据以及输入设备的数据等录入至客户端，其中输入设备的数据可以为鼠标或键盘等外设的控制数据，随后该客户端作为生产端将携带有包含的音频数据、视频数据、输入设备的数据等的任务消息发送至服务端，服务端确定出该任务消息对应的消息类型。
43.进一步地，除了按照上述分类方式将任务消息划分为音频类型、视频类型以及控制类型，还可以具有其他分类方式，例如，游戏控制类消息以及非游戏控制类消息等，还可能包含心跳类型消息和非心跳类型消息等，任何可能的任务消息类型的划分方式均在本技术实施例的保护范围之内，本技术实施例中不再一一描述。
44.步骤s102、基于消息类型，将任务消息存储至对应的队列。
45.对于本技术实施例，使用者体验云游戏服务过程中，通过生产端发送任务消息的数量以及频率较大，有序的任务消息处理方式可以能够快速的完成任务消息的分发，继而，服务端分配用于任务消息存储的队列，对接收到的生产端发送的任务消息进行暂存，并基于队列先入先出的存储规则，从而实现有序的对任务消息进行处理。
46.具体地，服务端根据任务消息确定出对应的消息类型后，基于消息类型的不同，服务端分配多个队列，其中，每个消息类型至少对应一个队列，随后，服务端将任务消息分别至对应的队列中进行存储，也就是说，当服务端接收到任务消息并确定出该任务消息所对应的消息类型时，基于消息类型与队列的对应关系，确定出该消息类型所对应的队列，并在确定出的队列中存储该消息。
47.步骤s103、当接收到消费端发送的消息调取指令时，基于消息调取指令确定待调取的任务消息对应的消息类型，以及消息类型对应的队列。
48.对于本技术实施例，消费端预快速的得到服务端反馈的任务消息，消费端生成消息调取指令，以发送至对应的服务端，当服务端接收到消息调取指令后，基于消息调取指令
确定出对应的消息类型，基于消息类型进而确定出对应的队列；例如，当服务端接收到消费端发送的需要调取云游戏的游戏界面的消息调取指令时，服务端接收到该消息调取指令并确定出该待调取的消息类型为视频类消息，通过消息类型进一步确定出需要调取任务消息的队列，例如队列1。
49.值得说明的，消费端也属于客户端，消费端用于发送消息调取指令并接收从相应队列中调取的任务消息。在本技术实施例中，生产端和消费端可以为同一个客户端，也可以为不同的客户端，在本技术实施例中不做限定。
50.步骤s104、从消息类型对应的队列中调取任务消息。
51.对于本技术实施例，在确定出消息调取指令对应的队列后，服务端从该队列中调取对应的任务消息，并在将该任务消息反馈至消费端。例如，服务端从对应的队列1中调取到对应云游戏的游戏界面的任务消息后，将该任务消息发送至消费端以使消费端进行游戏画面切换和显示，从而完成针对该任务消息的消息分发过程。
52.本技术实施例提供了一种消息分发方法，对接收到生产端发送的任务消息进行类型确认，确定出对应的消息类型，以对接收到的任务消息进行类别划分，随后，基于消息类型确定出任务消息所要存储的队列，并将任务消息存储到该队列中，以实现对接收到的任务消息进行分类存储；相对于将所有的消息均存储在一个总队列中，可以降低队列爆栈的情况效率，进一步地，在调取队列中存储的任务消息时，通过从对应消息类型的队列中调取对应的任务消息，也可以降低任务消息分发所消耗的时间，进而可以提高消息分发的效率。
53.本技术实施例的一种可能的实现方式，步骤s101中确定任务消息对应的消息类型的方式，具体可以包括方式一或者方式二，其中，方式一：根据任务消息中携带的key以及key与消息类型之间的对应关系，确定任务消息对应的消息类型。
54.具体地，生产端将任务消息发送至服务端前，由生产端确定出该任务消息对应的key，例如，生产端生成包含有输入操作的数据的任务消息时，可以以handlemsg作为该任务消息对应的key；随后，生产端将携带有key与任务消息进行整合，一并发送至服务端；服务端接收到该任务消息时，服务端可直接从该任务消息中得到对应key，确定出该key与消息类型之间的对应关系，进而确定出该任务消息对应的消息类型。
55.进一步地，在根据任务消息中携带的key以及key与消息类型之间的对应关系，确定任务消息对应的消息类型，之前还可以包括：服务端创建key与消息类型之间的对应关系。在本技术实施例中，基于方式一来分析，服务端在key与消息类型之间的对应关系之后，可以将key与消息类型之间的对应关系发送至对应的生产端；当然，key与消息类型之间的对应关系还可以由生产端创建，并发送至该服务端。
56.进一步说明地，每个key对应一个消息类型；其中，一个消息类型可以对应一个key，也可对应至少两个key，本技术实施例不做具体限定。方式二：根据任务消息确定任务消息对应的key，并基于任务消息对应的key以及key与消息类型之间的对应关系，确定任务消息对应的消息类型。
57.具体地，服务端接收到生产端发送的任务消息后，将预先根据该任务消息确定对应的key。
58.其中，确定任务消息对应的key的方式可以是自定义的，也是全局唯一的，例如，可以将任务消息的id作为任务消息的key，也可以通过shortid生成器为任务消息定义一个短
id，并将该短id作为任务消息的key；还可以是利用键值编码的方式，将任务消息所包含的信息的字符串作为键值等方式。在确定任务消息对应的key时，可以利用哈希注册的方式进行确定，其中，哈希（hash）是一种将任意长度的输入通过散列算法变换成固定长度输出的函数，输出的值为散列值，实质上是将任意长度的任务消息压缩到某一固定长度的消息摘要的函数，即将任务消息进行压缩，压缩后得到固定长度的任务消息摘要，这个任务消息摘要即可作为对应的key，key与任务消息对应。在得到任务消息时，对任务消息采取散列算法求值，得到具体的散列值，这个散列值即可作为key。
59.进一步地，基于任务消息对应的key以及key与消息类型之间的对应关系，确定任务消息对应的消息类型，之前还可以包括：创建key与消息类型之间的对应关系，具体详见上述实施例。
60.进一步地，在通过上述实施例得到任务消息对应的消息类型后，将该任务消息存储至该消息类型所对应的队列。在本技术实施例中，队列可以包含写队列和读队列，写队列为具备写入权限的消息队列，读队列为具备读权限的消息队列。也就是说，一个消息类型至少对应一个读队列以及一个写队列，也即，一个消息类型所对应的读队列以及写队列也存在对应关系。
61.基于此，基于消息类型，将任务消息存储至对应的队列，具体可以包括：根据消息类型，将任务消息存储至对应的写队列。也就是说，在接收到生产端发送的任务消息，以及确定出该任务消息对应的消息类型后，将该任务消息发送至该消息类型所对应的写队列中。
62.具体地，从消息类型对应的队列中调取消息，具体可以包括：从消息类型对应的读队列中调取消息。也就是说，服务端确定出消息调取指令所需调取的消息对应的消息类型后，从该消息类型所对应的读队列中调取该任务消息。
63.进一步地，由上述实施例可知，当服务端接收到任务消息时，将任务消息写入对应的写队列，以及当服务端接收到调取指令时，从对应的读队列中读取任务消息。基于此，该方法还可以包括：当满足一定条件时，可以将写队列中存储的任务消息转移至对应的读队列；如下述实施例中几种可能的实现方式所示，将读队列中存储的任务消息和/或对应写队列中存储的任务消息与各自阈值进行比对，基于比对结果以触发任务消息进行转移；除此之外，还可以包括：当满足预设间隔时，将写队列中存储的任务消息转移至读队列，将写队列中存储的任务消息转移至读队列。其中，各个类型的任务消息所对应消息转移的条件可以相同，也可以不同，在此不做限定。
64.具体地，当满足一定条件时，可以将写队列中当前存储的全部任务消息转移至读队列，还可以基于预先设定，将写队列中存储的任务消息转移至读队列，具体由读队列转移至写队列中的任务消息的数量可以详见下述实施例，在此不再赘述。
65.进一步地，本技术实施例的一种可能的实现方式，基于消息调取指令确定待调取的任务消息对应的消息类型，以及消息类型对应队列，之后还可以包括：判断读队列内存储任务消息的数量是否不大于第一预设数量，若是，则判断对应的写队列内的任务消息的数量是否超出第二预设数量，对应的写队列与读队列存在对应关系；若是，则将对应写队列中存储的第二预设数量的任务消息转移至读队列；若否，则将写队列中存储的所有任务消息转移至读队列内。
66.具体地，在本技术实施例中，各个消息类型的读队列分别对应的第一预设数量可以全部相同，也可以全部不同，也可以部分相同；各个消息类型的写队列分别对应的第二预设数量可以全部相同，也可以全部不同，也可以部分相同，在本技术实施例中不做限定。
67.例如，基于消息调取指令确定出待调取的任务消息所对应的读对列1，读对列1所对应的第一预设数量为0，其对应的写队列1，写队列1所对应的第二预设数量为20；也就是说，判断读队列1中存储的任务消息的数量是否为0，若读队列1中存储的任务消息的数量为0，则判断写队列1中存储的任务消息的数量是否达到20，若写队列1中存储的任务消息的数量达到20，则将写队列1中的20个任务消息转移至读队列1，若写队列1中存储的任务消息的数量未达到20，则将写队列1中存储的全部任务消息转移至读队列1。
68.进一步说明的，若读队列（例如读队列1）内存储任务消息的数量大于第一预设数量，此时，服务端则判定当前该读队列内存储有一定量可被读取的任务消息，此时可以不执行任何操作；当然还可以依据该读队列内存储的任务消息的具体数量和写队列内当前存储的任务消息的具体数量确定，例如，当读队列1中存储的任务消息的具体数量明显小于写队列1内当前存储的任务消息的具体数量，此时，也可以考虑将写队列1中的部分任务消息转移至读队列1。
69.例如，读队列1内存储的任务消息的具体数量为10，写队列1中存储的任务消息为100，此时可以将写队列1中的部分任务消息转移至读队列1。
70.进一步地，在上述实施例中，将读队列中存储的任务消息转移至写队列中时可以一次全部转移，可以分批转移，例如，每一次转移10个任务消息，具体的转移方式在本技术实施例中不做限定。
71.本技术实施例中，服务端设定一定存储空间的写队列和读队列的存储空间，存在因生产端短时间内发送大量的任务消息至服务端进行存储，此时，任一写队列需要存储的任务消息过多，且无法及时将该任一写队列中的任务消息转移至对应的读队列，导致该任一写队列内存储被占满且消息分发出现延迟，此时，为了减少因该任一写队列存储被占满而导致消息分发出现延迟，进而出现消息分发速率降低的情况发生，该方法还可以包括：若任一写队列中存储的任务消息数量不小于第三预设数量，则确定任一写队列对应的读队列中存储的任务消息的数量；判断对应的读队列中存储的任务消息数量是否不小于第四预设数量；若否，则从任一写队列中获取待转移的任务消息，并将待转移的任务消息转移至对应的读队列中。
72.具体地，每个写队列设定有第三预设数量，也就是说，当任一写队列内存储的任务消息数量不小于第三预设数量时，则表征写队列内存储空间不足，甚至已满；每个读队列设定有第四预设数量，此时，当任一读队列内存储的任务消息数量小于第四预设数量时，则表征该读队列中当前存在空闲，也即服务端可将写队列内的一部分的任务消息转移至读队列中，进而服务端可以继续接收生产端发送的任务消息存储至该写队列中。在本技术实施例中，针对相同的消息类型，写队列所对应的第三预设数量以及读队列所对应的第四预设数量可以相同，也可以不同。
73.例如，服务端设定写队列1和读队列1的存储空间为2048，第三预设数量为2048，第四预设数量为2028；若存在任一写队列内的存储空间被占满时，即存储数量达到2048时，此时，服务端则判断对应该任一写队列对应的读队列内存储的任务消息数量是否达到2028，
若未达到，服务端则判定该读队列内的存储空间满足由写队列向读队列进行任务消息转移的条件，随即，服务端则将该任一队列内的20个任务消息转移至对应的读队列中，而继续接收生产端发送的任务消息能够存储至该任一写队列中。
74.需要进一步说明的是，服务端内分配的多个写队列和多个读队列中，存在任一写队列内存储空间被占满，对应的读队列空间也被占满情况，此时，则无法将该任一写队列中存储的任务消息转移至读队列中。
75.基于此，在判断对应的读队列中存储的任务消息数量是否不小于第四预设数量，之后还可以包括：若对应的读队列中存储的任务消息数量不小于第四预设数量，且接收到待写入的任务消息，则确定待写入的任务消息的重要等级；若重要等级不属于预设等级，则将待写入的任务消息抛弃；若重要等级属于预设等级时，则将待写入的任务消息对应的写队列内的缓存空间增大。
76.具体地，若在任一写队列和对应的读队列内存储空间被占满时，服务端再次接收到生产端发送的且需要写入该写队列中任务消息时，确定待写入该写队列中的任务消息所对应的重要等级，则需要为该任务消息增设存储空间，然而服务端本身存储空间有限，空间则基于利用最大化原则进行分配，因此，是否需要为该任务消息增设空间，则需要对该任务消息的重要程度进行判断。
77.具体地，若读队列中存储的任务消息数量不小于第四预设数量时，则证明当前该读队列内存储空间已满或不足以接收对应写队列转移的任务消息，此时再次接收到生产端发送的任务消息时，服务端则对该任务消息进行重要等级判断，其中，服务端可以根据任务消息对应任务类型确定任务消息的重要等级，也可以根据任务消息中携带的属性信息（用户信息、客户端信息以及设备信息等至少一项）确定任务消息的重要等级，还可以根据任务消息中携带的数据确定任务消息的重要等级，包含有设备输入的数据的任务消息需要及时进行处理和反馈，因此将该任务消息可定义为高重要等级，并将该高重要等级定义在需要进行消息存储的等级范围内，而包含有心跳数据的任务消息可定义为低重要等级，其他任何可以确定任务消息重要等级的方式均在本技术实施例的保护范围之内。
78.进一步地，在通过上述实施例确定出任务消息的重要等级后，若接收到的任务消息重要等级较低，则服务端在接收到该任务消息后可以直接抛弃，而不在队列中存储，若接收到的任务消息重要等级较高，服务端则将该任务消息对应所要进行存储的写队列的存储空间增大一倍，以便于将该任务消息存储至写队列内。例如，若重要等级较高的任务消息待进行存储的写队列为写队列1，则将写队列1的存储空间由2048扩大至4096，并将该任务消息写入该写队列1中。
79.在上述实施例中涉及当写队列中存储的任务消息较多时，可以将写队列中存储的任务消息转移至读队列中，但是为了进一步地读写队列交换数据的效率，该方法还可以包括：当任一写队列中存储的任务消息数量大于第五预设数量时，将任一写队列的权限由写入变更为读取。
80.具体地，在本技术实施例中，服务端每次将任务消息存储至写队列中后即检测该写队列中存储的任务量，也可以每隔预设时间检测写队列中存储的任务量，还可以满足其他触发条件时检测该写队列中存储的任务量。在本技术实施例中，各个任务类型分别对应的触发条件可以相同也可以不同，在本技术实施例中不做限定。
81.具体地，在检测到任一写队列中存储的任务消息数量大于第五预设数量时，服务端可以将该任一写队列的权限由写入变更为读取，也就是说，之前具备写入权限的写队列由具备写入权限变更为具备读取权限，服务端可以从该队列中读取（调取）任务消息，例如，写队列1从具备写入权限变更为读取权限，服务端可以从变更权限后的写队列1中读取任务消息。
82.进一步地，当将该任一写队列的权限由写入变更为读取时，其所对应的读队列也可以由读取变更为写入，当然也可以不变更。
83.进一步地，当任一写队列中存储的任务消息较多时，例如大于第五预设数量时，为了降低权限变更开销，可以将该任一写队列的权限由写入变更为读写权限，也即服务端既可以将接收到的任务消息进行写入，也可以从该队列中读取任务消息。例如，当写队列1中存储的任务消息较多时，将写队列1的权限由写入变更为读写权限，也即服务端可以将接收到的任务消息写入该写队列1中，还可以从写队列1中读取任务消息。
84.进一步地，需要说明的是，无论是将写队列由写权限变更为读权限，还是将写队列由写权限变更为读写权限，其所对应的读队列可以进行权限变更，也可以不进行权限变更，在本技术实施例中不做限定。
85.进一步地，当其所对应的读队列进行权限变更时，可以将该读队列的权限从读权限变更写权限，也可以将该读队列的权限从读权限变更为读写权限，在本技术实施例中不做限定。
86.进一步地，在本技术实施例中，当任一写队列中存储的任务消息较多时，将该写队列的权限由读权限变更为写权限，也即可以直接从该队列中读取任务消息，可以缓解因写队列存储的任务消息数量过多而造成写队列拥堵，进而造成消息分发的延迟，影响到消息分发的效率。
87.进一步地，针对一般的任务消息，当服务端接收到该任务消息时按照上述实施例的方式可以先存储至写队列中，然后将写队列中存储的任务消息转移至读队列，以使得后续服务端可以从该读队列中读取任务消息，但是当服务端接收到的任务消息的实时性要求较高时，在确定任务消息对应的消息类型，之后还可以包括：确定消息类型对应的处理等级，处理等级为表征消息处理的实时性要求的等级；若处理等级属于预设的实时等级，则回调任务消息。也就是说，服务端确定出接收到的任务消息对应的实时性要求较高时，可以直接调入回调函数直接进行回调处理。
88.例如，服务端当前接收到的任务消息为使用者在游戏体验过程中对角色的控制消息，将该任务消息对应的实时等级定义为高实时等级，任务消息为使用者登录游戏界面时的控制消息时，可将该任务消息对应的实时等级定义为低实时等级。也即当服务端接收到的任务消息为针对角色的控制消息时，可以调用回调函数直接进行回调处理；当服务端接收到的任务消息为登录控制消息时，按照上述实施例所示的方式先写入对应的写队列中，在转移至对应的读队列中以供后续读取。
89.在上述实施例中介绍了消息分发的具体流程，下述实施例以云游戏场景为示例，介绍该消息分发的过程，具体如图2所示：当云游服务端接收到云游客户端发送的任务消息（例如，登录控制消息），判断该任务消息的消息类型，如属于任务类型1，则将该任务消息写入写队列1中，如此时检测到任务消息调取指令（读取指令）可以将待任务消息转移至读队
列1中，若此时并未检测到任务消息，则当写队列1中存储的任务消息是否达到20个，若达到20个，则将写队列1中存储的任务消息转移至读队列1中，若未达到20个，可以按照上述方式继续写入，其中，若服务器需要从读队列1中调取任务消息时，通过消息处理函数1进行调取；进一步地，若上述接收到的任务消息的消息类型属于任务类型2，则将该任务消息写入写队列2中，如此时检测到任务消息调取指令（读取指令）可以将待任务消息转移至读队列2中，若此时并未检测到任务消息，则当写队列2中存储的任务消息是否达到20个，若达到20个，则将写队列1中存储的任务消息转移至读队列2中，若未达到20个，可以按照上述方式继续写入，其中，若服务器需要从读队列2中调取任务消息时，通过消息处理函数2进行调取。
90.值得说明的，本技术实施例以云游戏游玩服务作为应用场景进行说明，但是并不作为对本技术实施例应用场景的限定。
91.上述实施例从方法流程的角度介绍一种消息分发的方法，下述实施例从虚拟模块或者虚拟单元的角度介绍了一种消息分发的装置，具体详见下述实施例。
92.参照图3，消息分发装置30具体可以包括：包括消息类型确定模块31、消息存储模块32、第一确定模块33以及消息调取模块34，其中，消息类型确定模块31，用于当接收到生产端发送的任务消息时，确定任务消息对应的消息类型；消息存储模块32，用于基于消息类型，将任务消息存储至对应的队列；第一确定模块33，用于当接收到消费端发送的消息调取指令时，基于消息调取指令，确定待调取的任务消息对应的消息类型，以及消息类型对应的队列；消息调取模块34，用于从消息类型对应的队列中调取任务消息。
93.本技术实施例的一种可能的实现方式，消息类型确定模块31在确定任务消息对应的消息类型时，具体用于：根据任务消息中携带的key以及key与消息类型之间的对应关系，确定任务消息对应的消息类型；或者，根据任务消息确定任务消息对应的key，并基于任务消息对应的key以及key与消息类型之间的对应关系，确定任务消息对应的消息类型。
94.本技术实施例的一种可能的实现方式，队列包含写队列和读队列，写队列为具备写入权限的消息队列，读队列为具备读权限的消息队列；消息存储模块32在基于消息类型，将任务消息存储至对应的队列，具体用于：根据消息类型，将任务消息存储至对应的写队列；其中，消息调取模块34在从消息类型对应队列中调取消息时，具体用于：从消息类型对应的读队列中调取消息。
95.在一种可能的实现方式中，装置30还包括：第一判断模块、第二判断模块、第一消息转移模块以及第二消息转移模块，其中，第一判断模块，用于判断读队列内存储任务消息的数量是否不大于第一预设数量；第二判断模块，用于当读队列内存储任务消息的数量不大于第一预设数量时，判断对应的写队列内的任务消息的数量是否超出第二预设数量，对应的写队列与读队列存在对应关系；
第一消息转移模块，用于当对应的写队列内的任务消息的数量超出第二预设数量时，将对应写队列中存储的第二预设数量的任务消息转移至读队列；第二消息转移模块，用于当对应的写队列内的任务消息的数量未超出第二预设数量时，将写队列中存储的所有任务消息转移至读队列内。
96.本技术实施例另一种可能的实现方式，消息分发装置30，还包括：第二确定模块、第三判断模块以及第三消息转移模块，其中，第二确定模块，用于若任一写队列中存储的任务消息数量不小于第三预设数量，则确定任一写队列对应的读队列中存储的任务消息的数量；第三判断模块，用于判断对应的读队列中存储的任务消息数量是否不小于第四预设数量；第三消息转移模块，用于当对应的读队列中存储的任务消息数量小于第四预设数量时，从任一写队列中获取待转移的任务消息，并将待转移的任务消息转移至对应的读队列中。
97.本技术实施例的另一种可能的实现方式中，装置30还包括：消息等级确定模块、消息抛弃模块以及缓存空间增大模块，其中，消息等级确定模块，用于当对应的读队列中存储的任务消息数量不小于第四预设数量，且接收到待写入的任务消息时，确定待写入的任务消息的重要等级；消息抛弃模块，用于当重要等级不属于预设等级时，将待写入的任务消息抛弃；缓存空间增大模块，用于当重要等级属于预设等级时，将待写入的任务消息对应的写队列内的缓存空间增大。
98.本技术实施例的另一种可能的实现方式中，消息分发装置30，还包括：权限变更模块，其中，权限变更模块，用于当任一写队列中存储的任务消息数量大于第五预设数量时，将任一写队列的权限由写入变更为读取。
99.本技术实施例的另一种可能的实现方式中，装置30还包括：消息等级处理模块以及消息回调模块，其中，消息等级处理模块，用于确定消息类型对应的处理等级，处理等级为表征消息处理的实时性要求的等级；消息回调模块，用于当处理等级属于预设的实时等级时，回调任务消息。
100.本技术实施例提供了一种消息分发的装置，在本技术实施例中通过消息类型确定模块对接收到生产端发送的任务消息进行类型确认，确定出对应的消息类型，以对接收到的任务消息进行类别划分，随后，消息存储模块基于消息类型确定出任务消息所要存储的队列，并将任务消息存储到该队列中，以实现对接收到的任务消息进行分类存储；相对于将所有的消息均存储在一个总队列中，可以降低队列爆栈的情况效率，进一步地，消息调取模块在调取队列中存储的任务消息时，通过从第一确定模块确定的对应消息类型的队列中调取对应的任务消息，也可以降低任务消息分发所消耗的时间，进而可以提高消息分发的效率。
101.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
102.本技术实施例还介绍了一种服务端，如图4所示，图4所示的服务端400包括：处理器401和存储器403。其中，处理器401和存储器403相连，如通过总线402相连。可选地，服务端400还可以包括收发器404。需要说明的是，实际应用中收发器404不限于一个，该服务端400的结构并不构成对本技术实施例的限定。
103.处理器401可以是cpu（central processing unit，中央处理器），通用处理器，dsp（digital signal processor，数据信号处理器），asic（application specific integrated circuit，专用集成电路），fpga（field programmable gate array，现场可编程门阵列）或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本技术公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器401也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。
104.总线402可包括一通路，在上述组件之间传送消息。总线402可以是pci（peripheral component interconnect，外设部件互连标准）总线或eisa（extended industry standard architecture，扩展工业标准结构）总线等。总线402可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
105.存储器403可以是rom（read only memory，只读存储器）或可存储静态消息和指令的其他类型的静态存储设备，ram（random access memory，随机存取存储器）或者可存储消息和指令的其他类型的动态存储设备，也可以是eeprom（electrically erasable programmable read only memory，电可擦可编程只读存储器）、cd-rom（compact disc read only memory，只读光盘）或其他光盘存储、光碟存储（包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等）、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。
106.存储器403用于存储执行本技术方案的应用程序代码，并由处理器401来控制执行。处理器401用于执行存储器403中存储的应用程序代码，以实现前述方法实施例所示的内容。
107.本技术实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当其在计算机上运行时，使得计算机可以执行前述方法实施例中相应内容。在本技术实施例中通过对接收到生产端发送的任务消息进行类型确认，确定出对应的消息类型，以对接收到的任务消息进行类别划分，随后，基于消息类型确定出任务消息所要存储的队列，并将任务消息存储到该队列中，以实现对接收到的任务消息进行分类存储；相对于将所有的消息均存储在一个总队列中，可以降低队列爆栈的情况效率，进一步地，在调取队列中存储的任务消息时，通过从对应消息类型的队列中调取对应的任务消息，也可以降低任务消息分发所消耗的时间，进而可以提高消息分发的效率。
108.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过
程，在此不再赘述。
109.在本技术所提供的实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
110.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
111.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
112.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
113.以上所述，以上实施例仅用以对本技术的技术方案进行了详细介绍，但以上实施例的说明只是用于帮助理解本技术的方法及其核心思想，不应理解为对本技术的限制。本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本技术的保护范围之内。