消息处理方法、装置、电子设备及存储介质与流程

1.本技术涉及计算机技术领域，尤其涉及一种消息处理方法、装置、电子设备及存储介质。


背景技术：

2.随着互联网技术的发展，消息源产生的消息的数量呈指数增长，消息处理端需要对消息源产生的大量消息进行处理。目前，消息处理端在获取到消息源产生的大量消息时，通常将这些消息分别存储到多个消息队列中，然后在对这些消息进行处理时，从多个消息队列中一批一批拉取消息进行处理。
3.对于拉取的一批消息，采用多个线程同时进行处理，需要等待这一批消息处理完后，再处理下一批消息。但是，消息源产生的一些同类型的消息可能是有序的，例如同一账户的消息或者同一设备的消息等，采用多个线程同时进行处理时不能保证按照有序消息的顺序进行处理，并且，如果某一线程出现卡死会导致其他线程进行等待，并发性差。


技术实现要素：

4.本技术实施例提供一种消息处理方法、装置、电子设备及存储介质，用于保证消息处理的顺序性和并发性。
5.第一方面，本技术实施例提供一种消息处理方法，包括：
6.从至少一个消息队列中持续性获取消息源产生的各个消息，每获取一次，将获取到的各个消息分别保存至至少一个目标队列中；其中，所述各个消息中具有相同标识的消息保存至同一目标队列中，且一个目标队列中的具有相同标识的各个消息，是按照所述具有相同标识的各个消息在相应的消息队列中的排列顺序保存的；
7.针对所述至少一个目标队列中的各个目标队列，分别采用一个处理线程按照消息保存的先后顺序对相应的目标队列中的各个消息进行处理，获得各个消息对应的消息处理记录；
8.基于获得的各个消息处理记录，获得消息处理结果。
9.第二方面，本技术实施例提供一种消息处理装置，包括：
10.保存模块，用于从至少一个消息队列中持续性获取消息源产生的各个消息，每获取一次，将获取到的各个消息分别保存至至少一个目标队列中；其中，所述各个消息中具有相同标识的消息保存至同一目标队列中，且一个目标队列中的具有相同标识的各个消息，是按照所述具有相同标识的各个消息在相应的消息队列中的排列顺序保存的；
11.处理模块，用于针对所述至少一个目标队列中的各个目标队列，分别采用一个处理线程按照消息保存的先后顺序对相应的目标队列中的各个消息进行处理，获得各个消息对应的消息处理记录；
12.获取模块，用于基于获得的各个消息处理记录，获得消息处理结果。
13.在一种可能的实施例中，从至少一个消息队列中获取的各个消息分别携带有消息
队列标识，所述装置还包括：
14.确定模块，用于对于当前已处理的各个消息对应的消息处理记录，按照已处理的各个消息携带的消息队列标识，确定来自相应的消息队列的各个消息的消息处理记录；
15.排序模块，用于将相应的消息队列中的各个消息的消息处理记录，按照各个消息在该消息队列中的顺序进行排列，得到相应的消息队列对应的排列后的消息处理记录。
16.在一种可能的实施例中，所述消息处理记录包括对应的消息在相应的消息队列中的偏移量，且从同一个消息队列中获取的各个消息的偏移量是连续增加的，所述装置还包括：
17.确定模块，用于对于相应的消息队列，根据该消息队列对应的排列后的消息处理记录中的偏移量，确定偏移量序列；
18.记录模块，用于确定所述偏移量序列中的第一个连续的偏移量子序列中的最大偏移量，并记录相应的消息队列中已处理到最大偏移量对应的消息。
19.在一种可能的实施例中，所述装置还包括：
20.删除模块，用于将所述第一个连续的偏移量子序列中，除所述最大偏移量之外的偏移量对应的消息处理记录删除。
21.在一种可能的实施例中，所述装置还包括：
22.报警模块，用于若在设定时间内，所述偏移量序列中的最大偏移量发生变化，且所述第一个连续的偏移量子序列中的最大偏移量未发生变化，则进行报警；或者，
23.所述偏移量序列中的最大偏移量增加了设定数值，且所述第一个连续的偏移量子序列中的最大偏移量未发生变化，则进行报警；或者，
24.所述第一个连续的偏移量子序列中的最大偏移量未发生变化，且所述偏移量序列中的最大偏移量与所述第一个连续的偏移量子序列中的最大偏移量的差值达到设定阈值，则进行报警。
25.在一种可能的实施例中，所述保存模块还用于：
26.分别针对所述各个消息的标识进行哈希运算，得到相应的哈希值；
27.将所述各个消息，分别保存至相应的哈希值关联的目标队列中。
28.第三方面，本技术实施例提供一种计算机设备，其包括处理器和存储器，其中，所述存储器存储有程序代码，当所述程序代码被所述处理器执行时，使得所述处理器执行第一方面所述方法的步骤。
29.第四方面，本技术实施例提供一种计算机存储介质，所述计算机存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行第一方面所述方法的步骤。
30.由于本技术实施例采用上述技术方案，至少具有如下技术效果：
31.从多个消息队列中持续性获取消息源产生的各个消息，每获取一次消息，将获取到的各个消息分别保存至多个目标队列中，并且各个消息中具有相同标识的消息按照其在相应的消息队列中的排列顺序保存到同一目标队列中，其中，具有相同标识的消息可以是同一类型的消息，这样，当具有相同标识的消息是有序的消息时，可以使有序的消息保持其顺序性。对于每个目标队列，采用一个处理线程按照消息保存的先后顺序对该目标队列中的各个消息进行处理，从而可以对有序的消息按照顺序进行处理，以保证其处理顺序性。
32.另外，由于多个目标队列分别采用一个处理线程进行处理，多个处理线程并发处理消息，其中的一个处理线程不需要等待其他处理线程处理完，而是可以持续性处理消息。因此，相对于相关技术中批量拉取消息后，等待这一批消息处理完后再处理下一批消息的方式，本技术实施例的并发性更好。因此，本技术实施例可以保证有序消息的处理顺序性，并且并发性好。
33.本技术的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本技术而了解。本技术的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
34.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
35.图1为本技术实施例提供的相关技术中的消息处理流程图；
36.图2是本技术实施例提供的一种区块链系统的结构示意图；
37.图3是本技术实施例提供的一种区块结构的示意图；
38.图4为本技术实施例提供的一种消息处理方法的应用场景示意图；
39.图5为本技术实施例提供的一种消息处理方法的流程图；
40.图6为本技术实施例提供的一种基于kafka的消息处理系统的消息处理方法的流程图；
41.图7为本技术实施例提供的一种基于kafka的消息处理系统的消息处理过程示意图；
42.图8为本技术实施例提供的基于kafka的消息处理系统中的offset处理模块的处理过程示意图；
43.图9a为本技术实施例提供的相关技术中宕机重新启动后的消息处理过程示意图；
44.图9b为本技术实施例提供的另一种宕机重新启动后的消息处理过程示意图；
45.图10为本技术实施例提供的消息处理装置的结构示意图；
46.图11为本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
47.为了使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术作进一步地详细描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本技术保护的范围。
48.为了便于本领域技术人员更好地理解本技术的技术方案，下面对本技术涉及的名词进行介绍。
49.1、云技术(cloud technology)：是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算
商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。本技术实施例中涉及的服务器可以均通过云技术实现。
50.2、消息源：是指产生消息的设备，例如终端设备，其在处理业务时可以产生与业务相关的消息。
51.3、消息队列：是指在消息的传输过程中保存消息的容器。本技术实施例中的消息队列可以部署在服务器中，用于缓存消息。
52.4、标识：是指消息的标识，用于区分不同类型的消息，例如某一消息的标识可以是产生该消息的终端设备的设备标识，也可以是登录终端设备的账户的标识，还可以是消息对应的业务标识，具体可以根据需要进行设置。因此，不同类型的消息可以是不同账户的消息、不同设备的消息或者不同业务的消息等，本技术对此不作限定。
53.5、线程：是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。
54.6、宕机：是指计算机因为某些原因不能再提供服务，属于计算机出现计算能力消失的一种情况。
55.7、kafka：是由apache软件基金会开发的一个开源流处理平台，由scala和java编写。kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费端在网站中的所有动作流数据。kafka的目的是通过hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。
56.8、偏移量：kafka消息日志中用于标注已读取的消息的位置。本技术实施例中可以理解为从至少一个消息队列中获取的各个消息的位置。
57.下文中所用的词语“示例性”的意思为“用作例子、实施例或说明性”。作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。
58.文中的术语“第一”、“第二”仅用于描述目的，而不能理解为明示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本技术实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
59.下面对相关技术进行介绍：
60.下面以服务器对终端设备产生的大量消息进行处理的过程为例，对相关技术中的消息处理过程进行示例介绍：
61.对于终端设备产生的大量消息，服务器首先将这些消息进行缓存，然后采用图1所示的处理过程进行处理，通过拉取数据线程从缓存中一批一批拉取消息，对于拉取的一批消息，采用线程1、线程2
……
线程n等多个线程进行处理，等待所有线程处理完这一批消息后，再拉取下一批消息进行同样的处理。但是，终端设备产生的一些同类型的消息可能是有序的，采用多个线程同时进行处理时不能保证按照有序消息的顺序进行处理，并且，如果某
一线程出现卡死会导致其他线程进行等待，并发性差。
62.有鉴于此，本技术实施例提供一种消息处理方法，下面对该方法的设计思想进行介绍。
63.在本技术实施例中，消息处理端在获取到消息源产生的大量消息后，可以将这些消息缓存到多个消息队列中，具体地，具有相同标识的消息按照获取的先后顺序存储在同一消息队列中，其中，具有相同标识的消息可以是同一类型的消息，在处理消息时，可以从多个消息队列中一批一批获取消息，每获取一次消息，将获取到的各个消息进行二次拆分，即分别保存到多个目标队列中，并且各个消息中具有相同标识的消息，按照其在相应的消息队列中的排列顺序保存到同一目标队列中，这样，当具有相同标识的消息是有序的消息时，可以使有序的消息保持其顺序性。
64.对于每个目标队列，采用一个处理线程按照消息保存的先后顺序对该目标队列中的各个消息进行处理，从而可以对有序的消息按照顺序进行处理，以保证其处理顺序性。另外，由于多个目标队列分别采用一个处理线程进行处理，多个处理线程并发处理消息，其中的一个处理线程不需要等待其他处理线程，而是可以持续性处理消息，并发性好。因此，本技术实施例可以保证有序消息的处理顺序性，并且并发性好。
65.在一些实施例中，上述的各个消息队列可以理解为区块链系统中的各个区块。参见图2，图2是本技术实施例提供的区块链系统400的一个可选的结构示意图，由多个节点401(接入网络中的任意形式的计算设备，如服务器、用户终端)和客户端402形成，节点之间形成组成的点对点(p2p，peer to peer)网络，p2p协议是一个运行在传输控制协议(tcp，transmission control protocol)协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端都可以加入而成为节点，节点包括硬件层、中间层、操作系统层和应用层。
66.参见图2示出的区块链系统中各节点的功能，涉及的功能包括：
67.1)路由，节点具有的基本功能，用于支持节点之间的通信。
68.节点除具有路由功能外，还可以具有以下功能：
69.2)应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。
70.例如，应用实现的业务包括：
71.2.1)钱包，用于提供进行电子货币的交易的功能，包括发起交易(即，将当前交易的交易记录发送给区块链系统中的其他节点，其他节点验证成功后，作为承认交易有效的响应，将交易的记录数据存入区块链的临时区块中；当然，钱包还支持查询电子货币地址中剩余的电子货币；
72.2.2)共享账本，用于提供账目数据的存储、查询和修改等操作的功能，将对账目数据的操作的记录数据发送到区块链系统中的其他节点，其他节点验证有效后，作为承认账目数据有效的响应，将记录数据存入临时区块中，还可以向发起操作的节点发送确认。
73.2.3)智能合约，计算机化的协议，可以执行某个合约的条款，通过部署在共享账本上的用于在满足一定条件时而执行的代码实现，根据实际的业务需求代码用于完成自动化的交易，例如查询买家所购买商品的物流状态，在买家签收货物后将买家的电子货币转移
到商户的地址；当然，智能合约不仅限于执行用于交易的合约，还可以执行对接收的信息进行处理的合约。
74.3)区块链，包括一系列按照产生的先后时间顺序相互接续的区块(block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。
75.参见图3，图3是本技术实施例提供的区块结构(block structure)一个可选的示意图，每个区块中包括本区块存储交易记录的哈希值(本区块的哈希值)、以及前一区块的哈希值，各区块通过哈希值连接形成区块链。另外，区块中还可以包括有区块生成时的时间戳等信息。区块链(blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了相关的信息，用于验证其信息的有效性(防伪)和生成下一个区块。
76.基于上述设计思想，下面对本技术实施例的消息处理方法的应用场景进行介绍。
77.下面结合图1所示的一种消息处理方法的场景示意图，对本技术实施例的应用场景可能涉及的设备进行示例介绍。
78.参照图4，该应用场景包括终端设备100、缓存服务器200和处理服务器300。终端设备100和缓存服务器200之间可以通过通信网络进行通信，缓存服务器200和处理服务器300之间也可以通过通信网络进行通信。可选的，通信网络可以是有线网络或无线网络。终端设备100以及缓存服务器200之间、缓存服务器200和处理服务器300之间可以通过有线或无线通信方式进行直接或间接地连接，本技术在此不做限制。
79.终端设备200例如可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、车载终端设备等，但并不限于此。终端设备110可以通过客户端执行各种业务，客户端可以是网页版的客户端、预装在终端设备200中的应用程序、或者嵌入在第三方应用程序中的子应用程序等。终端设备200在通过客户端执行任何一种业务时，可以产生业务相关的消息。
80.缓存服务器200和处理服务器300都可以是一台服务器或由若干台服务器组成的服务器集群，可以为虚拟服务器或实体服务器，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(content delivery network，cdn)、以及大数据和人工智能平台等基础云计算服务的云服务器。
81.在具体实施时，缓存服务器200可以获取终端设备100产生的消息，将获取的消息存储至多个消息队列中，具体地，具有相同标识的消息可以按照获取的先后顺序存储在同一消息队列中。上述消息可以是终端设备100发送至缓存服务器200的，也可以是缓存服务器200从终端设备100中获取的，本技术对此不作限定。进一步的，处理服务器300可以作为消息处理端，从缓存服务器200中的多个消息队列中一批一批获取消息进行处理，其中，涉及的消息处理过程将在下文中进行介绍。
82.应当说明的是，图4是对消息处理方法的应用场景进行示例介绍，实际本技术实施例中的方法可以适用的应用场景并不限于此。例如，上述多个消息队列中也可以部署在处理服务器300中，也就是说，消息处理端可以只包括处理服务器300，本技术实施例对此不作限定。
83.在一种可能的实施场景中，缓存服务器200和处理服务器300可以组成基于kafka的消息处理系统。其中，kafka是一种高吞吐量的分布式发布订阅消息系统，基于kafka的消
息处理系统可以包括消息生产端、由多个服务器组成的kafka集群、消费端。消息生产端和kafka集群可以理解为上述缓存服务器200，消费端可以理解为上述处理服务器300。消息生产端可以获取消息源产生的消息，向kafka集群中的一个或多个服务器推送消息，具体地，可以将具有相同标识的消息推送至同一服务器，其中的每个服务器可以部署一个队列分片(即上述消息队列)，每个服务器将获取的消息按照获取的先后顺序进行缓存，消费端可以从kafka集群中的一个或多个服务器中拉取订阅的消息，进而对拉取的消息进行消费，可以理解为从至少一个消息队列中持续性获取消息源产生的各个消息，对获取的消息进行处理。
84.在实际应用中，本技术实施例的消息处理方法可以应用于投票、支付、点赞等对顺序性及并发量要求比较高的场景。
85.例如在直播场景下，大量观众可以通过终端设备(即观众端)对主播进行投票，可以产生大量的投票数据(即消息)，每个观众端可以将投票数据发送至缓存服务器，同一观众在投票后，可能取消投票，然后还可能重新进行投票，此时，同一观众的多个投票数据是有序的。另外，在直播场景下，大量观众也可以通过各自的观众端对主播进行点赞，这与上述投票过程类似，在此不再赘述。因此，该场景对于消息的顺序性及并发量要求比较高。
86.又例如在支付场景下，用户可以通过终端设备进行交易，在进行支付时，可以产生账单数据。大量用户通过终端设备(即用户端)进行交易，可以产生大量的账单数据(即消息)，每个用户的用户端可以将账单数据发送至缓存服务器。同一用户在交易后，可能取消交易，然后还可能重新进行交易，此时，同一用户的多个账单数据是有序的。因此，该场景对于消息的顺序性及并发量要求比较高。
87.应当说明的是，上述实施场景只是示例性的，实际本技术实施例中的消息处理方法可以适用的实施场景并不限于此。
88.基于上述的应用场景，下面对本技术实施例的消息处理方法进行介绍。
89.图5示出了本技术实施例提供的一种消息处理方法的流程图，该消息处理方法可以由处理设备执行，例如可以是图4中的处理服务器300，参照图5所示，方法可以包括如下步骤：
90.步骤s501，从至少一个消息队列中持续性获取消息源产生的各个消息，每获取一次，将获取到的各个消息分别保存至至少一个目标队列中；其中，各个消息中具有相同标识的消息保存至同一目标队列中，且一个目标队列中的具有相同标识的各个消息，是按照具有相同标识的各个消息在相应的消息队列中的排列顺序保存的。
91.其中，至少一个消息队列可以位于缓存服务器中，例如图2中的缓存服务器。消息源可以是产生消息的终端设备，终端设备可以将产生的消息发送给缓存服务器，另外，缓存服务器也可以主动从终端设备中获取消息。需要说明的是，至少一个消息队列也可以位于处理服务器中，本技术实施例对此不作限定。
92.具体地，针对消息源产生的相同类型的消息，可以设置相同的标识，相同类型的消息例如可以是同一账户的消息，也可以是同一终端设备的消息，还可以是同一业务的消息等等，因此，上述标识可以是账户标识、设备标识或者业务标识等，具体可以根据实际应用场景进行设置。具有相同标识的消息在一些场景下可以是有序的消息。
93.在一个示例中，用户通过终端设备的客户端进行交易时，在提交账单后，可以产生
与账单相关的消息，不同的用户可以产生不同的消息，不同的消息可以具有不同的标识，例如该标识可以是登录客户端的账户标识，也可以是设备标识或者账单标识等。当一个用户提交账单后，又取消账单，然后又提交账单时，可以产生具有相同标识的三个消息，并且这三个消息是有序的。
94.在另一个示例中，在直播场景中，观众可以通过观众的客户端(简称观众端)对主播进行投票，此时，观众端作为消息源，可以在观众投票时产生消息，不同的观众端可以产生不同的消息，不同的消息可以具有不同的标识，该标识例如可以是登录观众端的账户标识，也可以是观众端的设备标识等。当一个观众投票后，又取消投票时，可以产生具有相同标识的两个消息，并且这两个消息是有序的。
95.在具体实施时，缓存服务器获取消息源产生的各个消息后，在将各个消息分配至不同的消息队列时，可以将具有相同标识的消息分配至同一消息队列中，并且，每个消息队列可以具有一个消息队列标识，该消息队列标识用于区分不同的消息队列，例如，消息队列1、消息队列2、消息队列3。当具有相同标识的消息是有序消息时，在消息队列中保持有序消息的顺序性，以便后续对有序消息按照其顺序进行处理。另外，缓存服务器还可以为每个消息设定一个唯一的id，也就是说，多个消息可能具有相同的标识，例如同类型的消息可以具有相同的标识，但是每个消息对应一个id，通过这个id可以区分各个消息。
96.进一步地，处理服务器可以从至少一个消息队列中一批一批获取消息，具体地，可以定期从至少一个消息队列中获取消息，例如获取第一批消息后，在预设时间t后获取第二批消息，获取第二批消息后，在预设时间t后获取第三批消息，以此类推。其中的t可以根据需要进行设置，本技术实施例对此不作限定。具体地，可以根据需要设置每一批获取的消息的数量，各个批次获取的消息的数量可以相同，也可以不同。
97.在具体实施时，同一批消息可以来自同一消息队列，也可以来自不同的消息队列。示例性的，多个消息队列包括消息队列1、消息队列2和消息队列3，在获取某一批消息时，可以从消息队列1、消息队列2和消息队列3中的任意一个消息队列中获取设定数量的消息；也可以从消息队列1、消息队列2和消息队列3中分别获取一定数量的消息，总共获取设定数量的消息；当然也可以从消息队列1、消息队列2和消息队列3中的任意两个消息队列中分别获取一定数量的消息，总共获取设定数量的消息。并且，获取的一批消息中的各个消息中携带有消息队列标识，根据消息队列标识可以确定获取的各个消息分别所属的消息队列。
98.处理服务器在获取到某一批消息后，可以将这批消息按照获取的先后顺序依次分配至不同的目标队列中，对于其中具有相同标识的消息，将其保存至同一目标队列中，一个目标队列中可以包括多个标识的消息，并且，一个目标队列在保存具有相同标识的消息时，按照其在相应的消息队列中的顺序进行保存。
99.示例性的，在某一批消息中，包括具有标识1的消息1、消息2、消息3，具有标识2的消息4、消息5、消息6，在将该批消息进行保存时，可以将消息1、消息2、消息3保存至同一目标队列中，将消息4、消息5、消息6保存至同一目标队列中，标识1的消息和标识2的消息可以保存至同一目标队列中，也可以保存至不同的目标队列中。并且，消息1、消息2、消息3的保存顺序与这三个消息在相应的消息队列中的顺序一致，消息4、消息5、消息6的保存顺序与这三个消息在相应的消息队列中的顺序一致。
100.在一些实施例中，为了将获取到的各个消息中具有相同标识的消息保存至同一目
标队列中，步骤s501中获取到的各个消息分别保存至至少一个目标队列中具体可以通过如下步骤实现：
101.步骤a、分别针对各个消息的标识进行哈希运算，得到相应的哈希值；
102.步骤b、将各个消息，分别保存至相应的哈希值关联的目标队列中。
103.具体地，不同的标识可以通过不同的key进行表示，例如对于包含key1的消息，可以对key1进行哈希运算，得到相应的哈希值。可以预先设置各个目标队列分别与相应的哈希值相关联，例如，目标队列1关联的哈希值为h1，目标队列2关联的哈希值为h2，目标队列3关联的哈希值为h3。当上述key1对应的哈希值为h1时，将包含key1的消息都保存至目标队列1中。从而可以将具有相同标识的消息保存到同一目标队列中。
104.步骤s502，针对至少一个目标队列中的各个目标队列，分别采用一个处理线程按照消息保存的先后顺序对相应的目标队列中的各个消息进行处理，获得各个消息对应的消息处理记录。
105.示例性的，多个目标队列包括目标队列1、目标队列2和目标队列3，这三个目标队列分别采用处理线程1、处理线程2和处理线程3进行消息处理。具体地，处理线程1对目标队列1中的各个消息按照消息保存的先后顺序进行处理，处理线程2对目标队列2中的各个消息按照消息保存的先后顺序进行处理，处理线程3对目标队列3中的各个消息按照消息保存的先后顺序进行处理，然后可以得到这三个处理线程的消息处理记录。
106.以处理线程1为例，例如目标队列1中按顺序保存有消息1、消息2、消息3,、消息4、消息5、消息6，处理线程依次对消息1、消息2、消息3、消息4、消息5、消息6进行处理，得到这六个消息对应的消息处理记录。
107.步骤s503，基于获得的各个消息处理记录，获得消息处理结果。
108.由上述可知，每个消息具有一个id，每个消息的消息处理记录中可以携带消息的id，这样，可以根据消息处理记录中携带的消息的id确定哪些消息已经处理。
109.示例性的，在上述直播场景中，对于观众通过观众端对主播进行投票所产生的各个消息，通过上述步骤s501和步骤s502进行处理后，得到的各个消息处理记录可以是已处理的各个消息对应的投票记录，进而根据获得的投票记录统计投票结果，即得到消息处理结果。
110.本技术实施例中，从多个消息队列中一批一批获取消息，每获取一次消息，将获取到的各个消息分别保存到多个目标队列中，并且各个消息中具有相同标识的消息，按照其在相应的消息队列中的排列顺序保存到同一目标队列中，这样，当具有相同标识的消息是有序的消息时，可以使有序的消息保持其顺序性。对于每个目标队列，采用一个处理线程按照消息保存的先后顺序对该目标队列中的各个消息进行处理，从而可以对有序的消息按照顺序进行处理，以保证其处理顺序性。
111.另外，由于多个目标队列分别采用一个处理线程进行处理，多个处理线程并发处理消息，其中的一个处理线程不需要等待其他处理线程，而是可以持续性处理消息，相对于相关技术中批量拉取消息后，等待这一批消息处理完后再处理下一批消息的方式，本技术实施例的并发性更好。因此，本技术实施例可以保证有序消息的处理顺序性，并且并发性好。
112.在一些实施例中，由于多个处理线程并行对获取到的各个消息进行处理，得到的
已处理消息的消息处理记录，可能是来自不同的消息队列中的各个消息的消息处理记录，在上述步骤s502之后，还可以执行如下步骤：
113.步骤1)、对于当前已处理的各个消息对应的消息处理记录，按照已处理的各个消息携带的消息队列标识，确定来自相应的消息队列的各个消息的消息处理记录。
114.步骤2)、将相应的消息队列中的各个消息的消息处理记录，按照各个消息在该消息队列中的顺序进行排列，得到相应的消息队列对应的排列后的消息处理记录。
115.进一步地，上述消息处理记录中可以包括对应的消息的偏移量，该偏移量可以表示一个消息在相应的消息队列中的位置，例如在消息队列1中的第一个消息的偏移量可以是1，第二个消息的偏移量可以是2，以此类推。如果获取的一批消息来自不同的消息队列，则每个消息的偏移量是在相应的消息队列中的偏移量。
116.在相关技术中，处理服务器采用多个线程处理消息过程中，会针对每个消息队列，分别记录该消息队列当前处理到的消息的偏移量，通常记录已处理的最大偏移量，以便处理服务器由于某些原因宕机重新启动后，继续获取该消息队列中所记录的最大偏移量之后的消息。但是，这样有可能会丢失消息，例如，相应的消息队列中已处理的消息的偏移量分别为：1、2、3、5、6，此时，如果记录处理到了第六个消息，则认为第六个消息之前的消息都已经处理过，在处理服务器宕机重新启动后，会继续获取相应的消息队列中排在第六个消息后面的消息，而由于第四个消息还未处理，从而导致第四个消息丢失。为了防止丢失消息，本技术实施例的消息处理方法还可以包括如下步骤：
117.步骤1、对于相应的消息队列，根据该消息队列对应的排列后的消息处理记录中的偏移量，确定偏移量序列；
118.步骤2、确定偏移量序列中的第一个连续的偏移量子序列中的最大偏移量，并记录相应的消息队列中已处理到最大偏移量对应的消息。
119.例如，消息队列1对应的排列后的消息处理记录包括第一个消息的消息处理记录、第二个消息的消息处理记录、第三个消息的消息处理记录、第五个消息的消息处理记录、第六个消息的消息处理记录，分别对应的偏移量为1、2、3、5、6，即得到的偏移量序列为1、2、3、5、6。
120.示例性的，在上述偏移量序列1、2、3、5、6中，第一个连续的偏移量子序列为1、2、3，而其中最大偏移量为3。也就是说，如果处理服务器宕机重新启动后，记录显示处理到了第三个消息，此时，认为第三个消息之后的消息还未处理，会继续获取消息队列1中第三个消息之后的消息，并通过相应的处理线程继续处理第三个消息之后的消息，以防止丢失消息4。
121.本技术实施例的消息处理方法，不仅可以保证消息处理的顺序性和并发性，还可以防止处理服务器宕机重启后导致消息丢失。
122.进一步地，上述实施例中得到的相应的消息队列对应的排列后的消息处理记录可以放入缓存中，在记录相应的消息队列中已处理到最大偏移量对应的消息之后，为了释放缓存空间，本技术实施例的消息处理方法还可以包括如下步骤：
123.将第一个连续的偏移量子序列中，除最大偏移量之外的偏移量对应的消息处理记录删除。
124.例如，上述第一个连续的偏移量子序列1、2、3，其中除最大偏移量3之外的偏移量
为1、2，因此，将缓存中第一个消息的消息处理记录和第二个消息的消息处理记录删除。这是因为，第一个消息和第二个消息已经处理完，而且已经记录当前处理到了第三个消息，不需要再记录一个消息的消息处理记录和第二个消息的消息处理记录。这样，可以释放缓存空间。
125.并且，在记录当前处理到了第三个消息时，如果处理服务器宕机重新启动，此时，处理服务器会获取相应的消息队列中的第三个消息之后的消息时，如果处理到第五个消息和第六个消息时，由于之前已经得到了第五个消息的消息处理记录和第六个消息的消息处理记录，因此，不会再处理第五个消息和第六个消息，避免消息的重复处理。
126.进一步地，在记录相应的消息队列中已处理到最大偏移量对应的消息之后，本技术实施例的消息处理方法还可以包括如下步骤：
127.a)、若在设定时间内，偏移量序列中的最大偏移量发生变化，且第一个连续的偏移量子序列中的最大偏移量未发生变化，则进行报警；或者，
128.b)、偏移量序列中的最大偏移量增加了设定数值，且第一个连续的偏移量子序列中的最大偏移量未发生变化，则进行报警；或者，
129.c)、第一个连续的偏移量子序列中的最大偏移量未发生变化，且偏移量序列中的最大偏移量与第一个连续的偏移量子序列中的最大偏移量的差值达到设定阈值，则进行报警。
130.例如，上述针对相应的消息队列，得到的偏移量序列为1、2、3、5、6，在记录第三个消息对应的消息处理记录后，如果在设定时间内，偏移量序列中的最大偏移量发生变化，例如由6变为10，说明消息队列中的消息正在被处理，但是还未获得第四个消息对应的偏移量，也就是说，第一个连续的偏移量子序列中的最大偏移量还是3，则可能是处理线程发生了故障等，需要进行报警。或者，偏移量序列中的最大偏移量增加了设定数值，例如增加了50，由6变为56，而第一个连续的偏移量子序列中的最大偏移量还是3，则也可能是处理线程发生了故障等，需要进行报警。或者，第一个连续的偏移量子序列中的最大偏移量还是3，且偏移量序列中的最大偏移量与3的差值达到了设定阈值，例如设定阈值为50，则偏移量序列中的最大偏移量变为53，也可能是处理线程发生了故障等，需要进行报警，以便及时发现存在的故障。
131.具体地，设定时间、设定数值和设定阈值均可以根据需要进行设置，本技术实施例对此不作限定。
132.在实际应用中，本技术实施例的消息处理方法可以应用于基于kafka的消息处理系统。下面对基于kafka的消息处理系统的消息处理方法进行介绍。
133.基于kafka的消息处理系统包括消息生产端(可以是服务器)、由多个broker服务器组成的kafka集群和消费端，其中消费端可以是上述的处理服务器。消息生产端可以从消息源获取大量消息，将获取到的消息按照一定的key(即消息的标识)和算法(例如哈希算法)被分区存储在不同的broker服务器上，具有相同key的消息存储同一broker服务器中。具体地，一个broker服务器上可以部署一个队列分片，即上述实施例中的消息队列，用于存储消息。消费端可以从多个队列分片中读取消息进行消费。针对队列分片中的消息，kafka消息日志中采用偏移量(offset)来标注已读取的消息的位置，也就是说，offset即记录在队列分片中已消费的消息的偏移量，消费端通过偏移量offset，来判断下次读取的消息在
队列分片中的起始位置。
134.图6示出了基于kafka的消息处理系统的消息处理方法的详细流程图。参照图6所示，该消息处理方法包括如下步骤：
135.步骤s601，消息生产端将从消息源获取的大量消息分别存储至多个队列分片中。
136.例如图7所示，消息生产端将从消息源获取的大量消息分别存储至队列分片1、队列分片2
……
队列分片n，其中n为大于1的整数。具体地，当大量消息中包括具有相同标识的消息时，将具有相同标识的消息存储至同一队列分片中，以便后续保证具有相同标识的消息的顺序。
137.步骤s602，消费端通过拉取线程从多个队列分片中持续性拉取各个消息，对于每次拉取的各个消息，分别保存至多个本地队列中；其中，各个消息中具有相同标识的消息保存至同一本地队列中，且一个本地队列中的具有相同标识的消息，是按照具有相同标识的消息在相应的队列分片中的排列顺序保存的。
138.具体地，消费端可以通过拉取线程从多个队列分片中一批一批拉取消息，拉取线程在拉取一批消息时，可以从其中一个队列分片中拉取，也可以从其中多个队列分片中拉取。下面以从其中一个队列分片中拉取消息为例进行说明。消费端对于拉取的各个消息，分别保存至如图5所示的本地队列1、本地队列2
……
本地队列m中，其中m为大于1的整数，m的取值与n的取值可以相同，也可以不同。
139.在实际应用中，具有相同标识的消息可以是同一类型的消息，这样，当同一类型的消息是有序的消息时，可以使有序的消息在本地队列中保持其顺序性。
140.为了提高吞吐量，消费端可以采用多个处理线程进行消息处理。采用多个处理线程处理时，通常由一个主线程读取一批消息并执行分组操作，然后，由多个处理线程处理相应的分组消息，各个处理线程处理完相应的分组消息后，可以分别上报已处理消息的偏移量offset，该offset是指消息在相应的队列分片中的位置。
141.具体地，消费端可以将拉取到的各个消息按照一定的key(即消息的标识)和算法(例如哈希算法等)分别保存至不同的本地队列中，这样，可以使具有相同标识的消息保存至同一本地队列中。
142.步骤s603，消费端针对各个本地队列，分别采用一个处理线程按照消息保存的先后顺序对相应的本地队列中的各个消息进行处理，获得各个消息对应的消息处理记录，该消息处理记录中包括消息的偏移量。
143.例如图7所示，本地队列1、本地队列2
……
本地队列m中的消息分别采用处理线程1、处理线程2
……
处理线程m进行处理，其中的一个处理线程不需要等待其他处理线程处理完，而是可以持续性处理消息，并发性好。对于每个本地队列，采用一个处理线程按照消息保存的先后顺序对该本地队列中的各个消息进行处理，从而可以对有序的消息按照顺序进行处理，以保证其处理顺序性。
144.步骤s604，消费端通过各个处理线程将已处理的消息的offset提交至offset管理模块，通过offset管理模块对获取到的offset提进行排序，得到偏移量序列。
145.需要说明的是，上述实施例是以获取的一批消息来自一个队列分片为例，当获取的一批消息来自多个队列分片时，offset管理模块还可以对获取到的偏移量按照不同的队列分片进行划分，具体可以按照携带的队列分片标识进行划分，然后对各个队列分片分别
进行offset的排序，得到各个队列分片对应的偏移量序列。
146.步骤s605，消费端通过offset管理模块将偏移量序列中第一个连续的偏移量子序列中的最大偏移量提交至记录模块进行记录。
147.在上述消息处理方法中，由于每个本地队列采用一个处理线程按照消息保存的先后顺序对该本地队列中的各个消息进行处理，从而可以对有序的消息按照顺序进行处理，以保证其处理顺序性。另外，由于多个本地队列分别采用一个处理线程进行处理，多个处理线程并发处理消息，其中的一个处理线程不需要等待其他处理线程，而是可以持续性处理消息，并发性好。因此，上述消息处理方法可以保证有序消息的处理顺序性，并且并发性好。
148.进一步地，如图8所示，各个处理线程在处理完消息后，可以将相应的消息的offset提交至offset管理模块，offset管理模块可以对获取到的offset进行排序，例如1、2、4，也就是说，offset为1、2、4的消息已经处理完，offset为3的消息还未处理。此时offset管理模块可以将offset2提交至记录模块进行记录，以防止宕机重新启动后丢失offset为3的消息。
149.下面以图9a和图9b为例，说明一下本技术实施例在宕机重新启动后是如何防止消息丢失的。
150.如图9a所示，进程1可以表示宕机前的进程，进程2可以表示宕机重启后的进程，进程1已处理的消息的offset为1、2、4，在处理完相应的消息时将其offset提交至kafka，在相关技术中，kafka会将已处理的消息中的最大offset提交至进程2，此时，进程2获取到offset4后，得知offset4之前的offset对应的消息已经处理，会继续处理offset4之后的offset对应的消息，这样，会导致offset3对应的消息丢失。
151.如图9b所示，在图9a的基础上增加了offset管理模块，进程1将已处理消息的offset提交至offset管理模块，offset管理模块每得到一个offset，可以对该offset进行存储，然后对存储的多个offset进行归并(即排序)，例如，按照提交顺序获得的offset序列为2、1、4，将这几个offset归并后得到的offset序列为1、2、4，此时，由于offset3对应的消息还未处理，offset管理模块可以向进程2提交offset2，此时，进程2获取到offset2后，得知offset2之前的offset对应的消息已经处理，会继续处理offset2之后的offset对应的消息，这样，可以防止offset3对应的消息丢失。
152.并且，当进程2处理到offset4对应的消息时，由于之前已经处理了offset4对应的消息并提交了offset4，因此，不会再次处理offset4对应的消息，避免消息的重复处理。
153.进一步地，offset管理模块还可以将存储的offset中的过期数据进行清除，例如上述的offset序列1、2、4，在offset管理模块向进程2提交offset2后，可以将offset1进行清除。这是因为，进程2已经得知offset1对应的消息已经处理完，会继续处理offset2之后的offset对应的消息，不需要再存储offset1。这样，可以释放offset管理模块的存储空间。
154.另外，offset管理模块还可以进行故障报警，例如在向进程2提交offset2后，如果在设定时间内，上述offset序列中的最大offset发生了变化，例如由4变为10，而此时还未获得offset3，即offset3对应的消息还未处理，则可能是处理线程发生了故障等。或者，上述offset序列中的最大offset增加了设定数值，例如增加了50，由4变为54，而此时还未获得offset3，也可能是处理线程发生了故障等，需要进行报警，以便及时发现存在的故障。具体地，设定时间可以根据需要进行设置，本技术实施例对此不作限定。
155.与上述方法实施例基于同一发明构思，本技术实施例还提供一种消息处理装置，参照图10所示，该消息处理装置包括保存模块101、处理模块101和获取模块103；其中，
156.保存模块101，用于从至少一个消息队列中持续性获取消息源产生的各个消息，每获取一次，将获取到的各个消息分别保存至至少一个目标队列中；其中，各个消息中具有相同标识的消息保存至同一目标队列中，且一个目标队列中的具有相同标识的各个消息，是按照具有相同标识的各个消息在相应的消息队列中的排列顺序保存的；
157.处理模块102，用于针对至少一个目标队列中的各个目标队列，分别采用一个处理线程按照消息保存的先后顺序对相应的目标队列中的各个消息进行处理，获得各个消息对应的消息处理记录；
158.获取模块103，用于基于获得的各个消息处理记录，获得消息处理结果。
159.具体地，保存模块从多个消息队列中一批一批获取消息，每获取一次消息，将获取到的各个消息分别保存到多个目标队列中，并且各个消息中具有相同标识的消息，按照其在相应的消息队列中的排列顺序保存到同一目标队列中，这样，当具有相同标识的消息是有序的消息时，可以使有序的消息保持其顺序性。处理模块对于每个目标队列，采用一个处理线程按照消息保存的先后顺序对该目标队列中的各个消息进行处理，从而可以对有序的消息按照顺序进行处理，以保证其处理顺序性。另外，由于多个目标队列分别采用一个处理线程进行处理，多个处理线程并发处理消息，其中的一个处理线程不需要等待其他处理线程，而是可以持续性处理消息，并发性好。
160.在一种可能的实施例中，从至少一个消息队列中获取的各个消息分别携带有消息队列标识，装置还包括：
161.确定模块，用于对于当前已处理的各个消息对应的消息处理记录，按照已处理的各个消息携带的消息队列标识，确定来自相应的消息队列的各个消息的消息处理记录；
162.排序模块，用于将相应的消息队列中的各个消息的消息处理记录，按照各个消息在该消息队列中的顺序进行排列，得到相应的消息队列对应的排列后的消息处理记录。
163.在一种可能的实施例中，消息处理记录包括对应的消息的偏移量，且从同一个消息队列中获取的各个消息的偏移量是连续增加的，装置还包括：
164.确定模块，用于对于相应的消息队列，根据该消息队列对应的排列后的消息处理记录中的偏移量，确定偏移量序列；
165.记录模块，用于确定偏移量序列中的第一个连续的偏移量子序列中的最大偏移量，并记录相应的消息队列中已处理到最大偏移量对应的消息。
166.在一种可能的实施例中，装置还可以包括：
167.删除模块，用于将第一个连续的偏移量子序列中，除最大偏移量之外的偏移量对应的消息处理记录删除。
168.在一种可能的实施例中，装置还可以包括：
169.报警模块，用于若在设定时间内，偏移量序列中的最大偏移量发生变化，且第一个连续的偏移量子序列中的最大偏移量未发生变化，则进行报警；或者，
170.偏移量序列中的最大偏移量增加了设定数值，且第一个连续的偏移量子序列中的最大偏移量未发生变化，则进行报警；或者，
171.第一个连续的偏移量子序列中的最大偏移量未发生变化，且偏移量序列中的最大
偏移量与第一个连续的偏移量子序列中的最大偏移量的差值达到设定阈值，则进行报警。
172.在一种可能的实施例中，保存模块101具体可以用于：
173.分别针对各个消息的标识进行哈希运算，得到相应的哈希值；
174.将各个消息，分别保存至相应的哈希值关联的目标队列中。
175.具体地，不同的标识可以通过不同的key进行表示，例如对于包含key1的消息，可以对key1进行哈希运算，得到相应的哈希值。可以预先设置各个目标队列分别与相应的哈希值相关联，例如，目标队列1关联的哈希值为h1，目标队列2关联的哈希值为h2，目标队列3关联的哈希值为h3。当上述key1对应的哈希值为h1时，将包含key1的消息都保存至目标队列1中。从而可以将具有相同标识的消息保存到同一目标队列中。
176.与上述方法实施例和装置实施例基于同一发明构思，本技术实施例还提供了一种电子设备。该电子设备可以是服务器，如图4所示的处理服务器300。在该实施例中，电子设备的结构可以如图11所示，包括存储器301，通讯模块303以及一个或多个处理器302。
177.存储器301，用于存储处理器302执行的计算机程序。存储器301可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及运行即时通讯功能所需的程序等；存储数据区可存储各种即时通讯信息和操作指令集等。
178.处理器302，可以包括一个或多个中央处理单元(central processing unit，cpu)或者为数字处理单元等等。处理器302，用于调用存储器301中存储的计算机程序时实现上述消息处理方法。
179.通讯模块303用于与终端设备进行通信，获取语音数据。
180.本技术实施例中不限定上述存储器301、通讯模块303和处理器302之间的具体连接介质。本公开实施例在图11中以存储器301和处理器302之间通过总线304连接，总线304在图11中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线304可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
181.本技术实施例还提供了一种计算机存储介质，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例中的消息处理方法。
182.在一些可能的实施方式中，本技术提供的确定多媒体内容的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本技术各种示例性实施方式的消息处理方法的步骤，例如，所述计算机设备可以执行如图5所示的步骤s501～s503中的消息处理的流程。
183.所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
184.可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
185.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
186.上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
187.另外，在本技术各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
188.显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。