CN110659124A - 一种消息处理方法和装置 - Google Patents

Abstract

本发明公开了一种消息处理方法和装置，涉及计算机技术领域。该方法的一具体实施方式包括：根据消息使用方所订阅的消息主题和分区，获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中；统计所述未读消息的数量，分配与所述未读消息的数量相对应的线程，其中，所述线程用于获取所述未读消息；通过所述线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息，以对所获取到的消息进行业务处理。该方法通过缓存未读消息的位置信息，并通过线程获取与所述缓存中的位置信息相应的未读消息，之后对未读消息进行业务处理，能够根据缓存中指定的位置信息获取未读消息，提高了消息处理实时性。

Description

一种消息处理方法和装置

技术领域

本发明涉及计算机领域，尤其涉及一种消息处理方法和装置。

背景技术

Kafka是一种高吞吐量的分布式消息发布订阅系统。现有的基于Kafka的消息处理系统包括一个或多个消息生成方(producer，在本文中也被称为生产者)、一个或多个服务器(Kafka实例，也被称为Broker)组成的Kafka集群以及消息使用方(consumer，在本文中也被称为消费者)，通常将消息生成方与消息使用方均称为客户端，将Kafka集群称为服务端。消息生成方负责生成并发布消息到Broker，消息使用方负责从Broker读取消息并执行相应的业务逻辑处理。每条发布到Kafka集群的消息都有一个类别，这个类别被称为主题(Topic)，每个主题包括一个或者多个分区(Partition)。

现有的消息处理方案的大致原理为：消息使用方按照消息产生的顺序依次读取Kafka集群内相应分区的消息，并进行处理。另外，对于因作为消息使用方的客户端发生宕机、断电、程序异常等而造成消息处理失败的情况，现有技术通常利用多机器同步机制来处理消息，以减少上述原因造成的消息处理失败的情况。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

(1)消息处理实时性差。在服务器积压了大量数据的情况下，消息使用方依然依次读取相应分区内的消息，将造成数据读取慢或者网络阻塞，使得最新数据将被滞后读取和处理，并且使得消息使用方运行繁忙，处理能力下降。

(2)如果消息体量大，未处理的消息数量将会多，则会占用大量的本地存储。

(3)部署维护成本高，且多台机器重复处理消息，浪费带宽。

发明内容

有鉴于此，本发明实施例提供一种消息处理方法和装置，本实施例通过缓存未读消息的位置信息，并通过线程获取与所述缓存中的位置信息相应的未读消息，之后对未读消息进行业务处理，能够根据缓存中指定的位置信息获取未读消息，提高了消息处理实时性。

为实现上述目的，根据本发明实施例的一个方面，提供了一种消息处理方法。

本发明实施例的一种消息处理方法，包括：根据消息使用方所订阅的消息主题和分区，获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中；统计所述未读消息的数量，分配与所述未读消息的数量相对应的线程，其中，所述线程用于获取所述未读消息；通过所述线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息，以对所获取到的消息进行业务处理。

可选地，所述位置信息为偏移量，所述获取未读消息在所述分区的位置信息，包括：获取所述未读消息在所述分区的偏移量，所述未读消息的数量是根据所述缓存中的消息的最大偏移量、以及所述分区中的未读消息的偏移量确定的。

可选地，所述将所述未读消息的位置信息存储到缓存中，包括：将所述未读消息的位置信息倒序存储到缓存中。

可选地，所述方法还包括：在将所述未读消息的位置信息存储到缓存中之后，所述未读消息在所述缓存中的状态被设置为未读；在获取到所述分区中的、与所述缓存中的位置信息相应的未读消息之后，所述消息在所述缓存中的状态被设置为待处理；在对所获取到的消息成功进行业务处理之后，所述消息在所述缓存中的状态被设置为已处理，在未能对所获取到的消息成功进行业务处理的情况下，所述消息在所述缓存中的状态被设置为异常。

可选地，所述方法还包括：对所述缓存中的消息的位置信息和状态进行备份存储。

可选地，所述方法还包括：将对所述消息进行业务处理后的结果，上报至业务处理结果存储服务器。

为实现上述目的，根据本发明实施例的另一方面，提供了一种消息处理装置。

本发明实施例的一种消息处理装置，包括：获取存储模块，用于根据消息使用方所订阅的消息主题和分区，获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中；统计分配模块，用于统计所述未读消息的数量，分配与所述未读消息的数量相对应的线程，其中，所述线程用于获取所述未读消息；业务处理模块，用于通过所述线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息，以对所获取到的消息进行业务处理。

可选地，所述位置信息为偏移量，所述获取存储模块，还用于：获取所述未读消息在所述分区的偏移量，所述未读消息的数量是根据所述缓存中的消息的最大偏移量、以及所述分区中的未读消息的偏移量确定的。

可选地，所述获取存储模块，还用于：将所述未读消息的位置信息倒序存储到缓存中。

可选地，所述装置还包括：消息状态迁移模块，用于在将所述未读消息的位置信息存储到缓存中之后，所述未读消息在所述缓存中的状态被设置为未读；在获取到所述分区中的、与所述缓存中的位置信息相应的未读消息之后，所述消息在所述缓存中的状态被设置为待处理；以及在对所获取到的消息成功进行业务处理之后，所述消息在所述缓存中的状态被设置为已处理，在未能对所获取到的消息成功进行业务处理的情况下，所述消息在所述缓存中的状态被设置为异常。

可选地，所述装置还包括：备份存储模块，用于对所述缓存中的消息的位置信息和状态进行备份存储。

可选地，所述装置还包括：结果上报模块，用于将对所述消息进行业务处理后的结果，上报至业务处理结果存储服务器。

为实现上述目的，根据本发明实施例的再一方面，提供了一种电子设备。

本发明实施例的一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例的一种消息处理方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读介质。

本发明实施例的一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例的一种消息处理方法。

上述发明中的一个实施例具有如下优点或有益效果：通过缓存未读消息的位置信息，并通过线程获取与所述缓存中的位置信息相应的未读消息，之后对未读消息进行业务处理，能够根据缓存中指定的位置信息获取未读消息，提高了消息处理实时性；根据缓存中的消息的最大偏移量以及分区中的未读消息的偏移量确定未读消息的数量，以方便后续进行线程分配；将未读消息的位置信息倒序存储到缓存中，以优先处理最新到来的消息，增加消息处理的实时性；通过更新未读消息在缓存中的状态，方便根据其状态进行后续处理；将位置信息和状态进行备份存储，而非消息本身，数据量小、备份传输容易、节约带宽，而且在客户端发生故障时，能够保证数据无丢失、无重复的重新开始处理。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的消息处理方法的主要步骤的示意图；

图2是根据本发明实施例的消息处理方法的主要流程示意图；

图3是根据本发明实施例的缓存中消息状态变化的迁移图；

图4是根据本发明实施例的消息处理装置的主要模块的示意图；

图5是根据本发明实施例的消息处理系统的主要模块的示意图；

图6是本发明实施例可以应用于其中的示例性系统架构图；

图7是适用于来实现本发明实施例的电子设备的计算机装置的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的消息处理方法的主要步骤的示意图。如图1所示，本发明实施例的消息处理方法，主要包括如下步骤：

步骤S101：根据消息使用方所订阅的消息主题和分区，获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中。作为消息使用方的客户端根据其订阅的消息主题和分区，从服务端中获取未读消息在所述分区的位置信息；之后根据所述未读消息在所述分区的位置信息，确定所述未读消息的数量。其中，所述客户端可以是Windows(微软公司研发的操作系统)客户端、Mac(苹果公司研发的操作系统)客户端等；所述服务器可以是Linux(是一款多用户、多任务、支持多线程和多处理器的操作系统)服务器、Unix(是一款多用户、多任务操作系统)服务器等；所述消息主题，可以被认为是消息类型，比如可以是崩溃类数据、库存类数据、订单类数据等；所述分区是物理上的概念，对应一个物理存储，例如以文件形式表示分区。每个主题中包括一个或者多个分区。所述位置信息，即每条消息在分区中的位置，也被称为偏移量(Offset)，可被理解为该消息自起始位置起的偏移位置。

步骤S102：统计所述未读消息的数量，分配与所述未读消息的数量相对应的线程，其中，所述线程用于获取所述未读消息。根据所述缓存中的消息的最大偏移量、以及所述分区中的未读消息的偏移量确定所述未读消息的数量。在作为消息使用方的客户端中，预先建立包括至少一个线程的线程池，并配置每个线程的处理能力；根据线程池中每个线程的处理能力以及所述未读消息的数量，从线程池中选择适当数量的线程来处理消息。用于处理消息的每个线程会可被认为是一个消息使用方，用于处理步骤S101中所获取的某一消息主题、某一分区的消息。

步骤S103：通过所述线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息，以对所获取到的消息进行业务处理。根据不同的业务需求，预先定义消息处理逻辑。作为消息使用方的各个线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息；然后根据预先定义的消息处理逻辑，对所述未读消息进行业务处理。

以分析iOS产生的崩溃数据为例，作为消息生成方的iOS客户端将崩溃数据上报到作为Kafka实例(Broker)的Linux服务端，作为消息使用方的Mac操作系统从该Linux服务端获取待处理的消息，并对所获取的消息进行分析，以获得崩溃原因。为了实时处理崩溃数据，在本发明的实施例中，可在Linux服务端部署一套Kafka系统，在Mac客户端部署一套Kafka系统。通过Kafka系统建立Linux服务端和Mac客户端的通信。另外，Mac客户端的Kafka系统可以通过Python语言来实现发送与接收消息。

图2是根据本发明实施例的消息处理方法的主要流程示意图。在图2的实施例中，使用Mac客户端来实现消息使用方，但应理解，本发明不限于此，例如可以使用Windows客户端、Linux客户端来实现消息使用方。如图2所示，本发明实施例的消息处理方法，主要包括如下步骤：

步骤S201：Kafka集群的Broker服务器接收来自消息生成方的消息，将所述消息写入到对应主题的分区中。为了能够接收并处理来自消息生成方的消息，需要预先在例如作为Broker的Linux服务器搭建Kafka集群，以及在例如作为消息使用方的Mac客户端搭建Kafka集群的消费者组件。

在另一方面，Zookeeper在分布式系统中被广泛用于：分布式状态管理、分布式协调管理、分布式配置管理、和分布式锁服务。在Kafka集群中增加和减少服务器都会在Zookeeper节点上触发相应的事件。kafka系统会捕获这些事件，进行新一轮的负载均衡，作为消费者的客户端也会捕获这些事件来进行新一轮的处理。具体搭建原理例如包括：下载Zookeeper软件开发工具包，解压后参照官方文档进行配置，之后启动Zookeeper集群；下载Kafka软件开发工具包，解压后参照官方文档进行集群配置，之后启动Kafka集群，新建一个主题来验证Kafka集群是否创建成功。Kafka集群搭建成功后，即可接收来自消息生成方的消息。本发明实施例中，消息生成方为iOS客户端，消息即为崩溃数据。

Kafka集群可以包括一个或者多个Broker服务器，一个Broker服务器可以支持一个或者多个主题，一个主题可以划分为一个或者多个分区。在一个实施例中，消息生成方在将消息发送到Broker服务器时，可以指定该消息的主题和键(Key)，根据该键和Partition机制来确定将该消息发送至该主题的哪个分区。在另一个实施例中，Kafka集群将多条消息顺序存储至各个分区，各分区中的数据可以是平均分布的，也可以按照预先指定的分配比例分布。其中，Partition机制有两种基本的策略，一种是基于Key的分区算法(例如，对Key求哈希值，根据哈希值确定分区)，另一种是基于轮询(Round Robin)的分区算法。

步骤S202：作为消息使用方的Mac客户端根据其所订阅的主题和分区，从所述Broker服务器中获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中。其中，所述位置信息即偏移量(Offset)。偏移量是分区中消息的属性，从0开始连续递增，用来标识消息在分区中的位置。该步骤的具体实现原理为：Mac客户端向Broker服务器发送位置信息的获取请求；Broker服务器接收到获取请求后，查找出其主题、分区分别与所述获取请求中的主题、分区相同的未读消息的偏移量，之后将所有或者部分未读消息的偏移量反馈至Mac客户端。其中，所述获取请求中包括消息使用方标识、所请求获取的消息的主题和分区标识；所述消息使用方标识比如可以是Consumer1、Consumer2；主题比如可以是Topic1、Topic2。Broker服务器可以分辨存储的消息是否已被读取，所述未读消息是指Broker服务器中存储的未被读取的消息。

具体地，假设Mac客户端所订阅的主题为Topic1，分区为Partition1，Partition1中存在多条未读消息，每条未读消息对应有一个偏移量。Broker服务器从多条未读消息中选择预配置条数的未读消息，或者选择所有未读消息。例如Broker服务器选择1000条未读消息，这4条未读消息对应的偏移量分别为1000、1001、…、1999，则Mac客户端将获取到位置信息为1000、1001、…、1999的未读消息。

在一个实施例中，Mac客户端可以周期性向Broker服务器查询未读消息在其所订阅的主题的分区中的位置信息；在另一个实施例中，Mac客户端可由于命令触发而未读消息在所述分区的位置信息。

在另一优选的实施例中，Mac客户端持续监听Broker服务器中的未读消息的条数，并将获取到的位置信息倒序存储到缓存中的消息列表中。根据上例，未读消息在Partition1的偏移量为1000-1999，未读消息的存储示意如表1所示：

表1未读消息的存储

偏移量/位置信息	消息标识	消息大小(字节)	消息体
				1000	Msg1000	6	0x69AE38C5
1001	Msg1001	6	0x7C6F4BC6
				…	…	…	…
1999	Msg1999	6	0x5B7A890C

则未读消息在缓存中的存储示意如表2所示：

表2未读消息在缓存中的存储

偏移量/位置信息	消息标识	状态
			1999	Msg1999	未读
1998	Msg1998	未读
			…	…	…
1000	Msg1000	未读

即，本发明通过倒序存储实现了最新消息可被优先处理的优点，增加了消息处理的实时性；而且缓存中存储的是偏移量而非消息本身，节省了存储空间、存储效率高。

可以理解的是，由于根据位置信息即可查找到分区中的消息，因而表1和表2中的消息标识是可选的。

图3为本发明实施例的消息在缓存中的状态迁移示意图。如图3所示，Mac客户端从Broker服务器中获取到未读消息的位置信息后，将未读消息的位置信息以及状态信息存储于缓存中。由于Mac客户端此时并未实际获取到未读消息，而只是统计待获取的消息，因而如表2所示，将未读消息标为“未读”状态。

在另一方面，由于缓存的存在，Mac客户端在向Broker服务器获取未读消息在所述分区的位置信息时，可以不上报其目前处理的消息的最大偏移量。相应地，在一个实施例中，Mac客户端将缓存中的消息的最大偏移量上报给Broker服务器，以获取对应分区中的最新消息的偏移量；在另一个实施例中，Broker服务器可以自行从缓存中查询消息的最大偏移量，然后根据相应分区中的未读消息的最大偏移量，将所有或部分未读消息的偏移量发送给Mac客户端。

步骤S203：所述Mac客户端根据所述未读消息在所述分区的位置信息，统计所述未读消息的数量。在一个实施例中，将获取到的未读消息的最大偏移量与最小偏移量的差值加1后，即可得到未读消息的数量。根据上例，获取到的未读消息的最大偏移量为1999，最小偏移量为1000，则未读消息的数量为1999-1000+1＝1000，且所述未读消息是其偏移量为1000-1999的1000个消息。

在另一优选的实施例中，可以在服务于Mac客户端的缓存中维护有一个位置偏移量。当Mac客户端初次从Broker服务器获取位置信息时，初始化该位置偏移量为0，之后将该位置偏移量更新为上一次获取到的所述未读消息在所述分区中的最大偏移量。即，将获取到的未读消息的位置信息的最大偏移量减去缓存的消息的最大偏移量，即可得到未读消息的数量。根据上例，获取到的所述未读消息在相应分区中的最大偏移量为1999，缓存中的消息的最大偏移量为999，则该步骤中未读消息的数量为获取到的未读消息的位置信息的最大偏移量与缓存的消息的最大偏移量的差值，即1999-999＝1000。

步骤S204：所述Mac客户端分配与未读消息的数量相对应的线程。在一个实施例中，预先建立包括至少一个线程的线程池，和/或配置每个线程能够处理消息的最大数量(即处理能力)。根据每个线程的处理能力以及未读消息的数量，从线程池中分配出适当数量的线程来处理消息。假设线程池中有10个线程，每个线程最多能处理400条消息，未读消息的个数为1000条，则可以分配3-10个线程来处理消息。分配的线程数量越多，处理效率越高，但是分配的线程数量优选小于或等于未读消息的数量。

在一个实施例中，可以将步骤S202中所获取的未读消息依次轮询分配给所创建的线程。在另一个实施例中，可以按照未读消息的位置信息对所创建的线程总数取模后的结果，将步骤S202中所获取的未读消息分配给创建的线程。所分配的线程可被认为是对应于Kafka集群的消息使用方，用于获取该Mac客户端所对应的主题的分区中的未读消息。

步骤S205：所述Mac客户端根据缓存中未读消息的位置信息，通过所述线程从Broker服务器中获取所述未读消息，之后对所述未读消息进行业务处理。在一个实施例中，优选首先获取偏移量较大的未读消息。各个线程对应的消息使用方根据与该Mac客户端相关的主题以及分区，来从Broker服务器中获取具有缓存中未读消息的位置信息的未读消息，这样使得多个消息使用方依然对应于一个分区，与现有技术中使用一个消息使用方相比，在相同的时间能够获取更多的消息，增加了消息传输的能力，同时也减少了对未读消息进行存储和读取的时间。

参照图3在所分配的线程从Broker服务中获取到未读消息后，在缓存中Mac客户端将该未读消息的状态变为“待处理”。则获取到未读消息后在缓存中的存储示意如表3所示：

表3获取到未读消息后在缓存中的存储

偏移量/位置信息	消息标识	状态
			1999	Msg1999	待处理
1998	Msg1998	待处理
			…	…	…
1000	Msg1000	待处理

在另一个实施例中，除了从Broker服务器获取未读消息，Mac客户端所启动的线程还可以根据缓存中被标注为“异常”的消息的偏移量，从Broker中获取具有该偏移量的消息。可以理解的是，从Broker服务器的角度，被标注为异常的消息是“已读取”的消息。

另外，Mac客户端根据不同的业务需求，预先定义消息处理逻辑。根据上例，在从Broker服务器获取到偏移量分别为1000-1999的未读消息后，按照预先定义的对所获取到的消息进行业务处理。比如，消息生产方所发送的数据为崩溃数据，消息处理逻辑为分析崩溃数据，以得到崩溃分析结果。

参照图3，对于从Broker服务中所获取到的消息，在所述Mac客户端对所获取到的消息进行成功处理后，在缓存中Mac客户端将该消息的状态从“待处理”变为“已处理”；或者在所述Mac客户端对所获取到的消息进行成功处理并将处理结果上报给Kafka集群(此时，Mac客户端可被认为是发送数据的消息生产方)或者其他处理结果存储服务器后，在缓存中Mac客户端将该消息的状态从“待处理”变为“已处理”。

另一方面，如果Mac客户端未能成功处理消息，则将对应的消息的状态从“待处理”变更为“异常”。在另一实施例中，Mac客户端可再次尝试处理消息，若经过若干次尝试后，依然未能成功处理消息，再将对应的消息的状态从“待处理”变更为“异常”。其中，可以自定义消息被重复处理的次数，例如为1-3次。

例如，如表4所示，偏移量为1999的消息被Mac客户端成功处理，并且处理结果也被成功上报至Kafka集群或者其他处理结果存储服务器，因而在缓存中该消息的状态被标注为“已处理”；偏移量为1998的消息未被Mac客户端成功处理，因而在缓存中该消息的状态被标注为“异常”；偏移量为1000的消息尚未被Mac客户端进行处理，因而在缓存中该消息的状态依然为“待处理”。

表4消息被处理后在缓存中的存储

偏移量/位置信息	消息标识	状态
			1999	Msg1999	已处理
1998	Msg1998	异常
			…	…	…
1000	Msg1000	待处理

在另一优选的实施例中，如果缓存中某个消息的状态被标注为“异常”，则将该消息的优先级降低，即当Broker服务器所管理的分区中有新到来的未读消息时，Mac客户端优先为新未读消息分配线程以获取新未读消息，之后再获取异常的“已读取”消息。

步骤S206：所述Mac客户端将业务处理结果上报至Broker服务器或其他处理结果存储服务器。其中，所述业务处理结果包括主题、分区和业务处理后的数据。实施例中，业务处理后的数据为崩溃分析结果。如步骤S205中所述，如果上报成功，则在缓存中该消息的状态被变更为“已处理”；如果上报失败，则在缓存中该消息的状态被变更为“异常”。在一个实施例中，可尝试进行重复上报，若多次尝试后依然上报失败，则在缓存中该消息的状态被变更为“异常”。其中，可以自定义处理结果被重复上报的次数，例如为1-3次。

可以理解的是，在缓存中可以使用一个消息列表来存储来自Broker中的消息，同时对消息标注其当前状态。在另一个实施例中，也可以而采用多个消息列表来存储来自Broker中的消息，例如，在步骤S202中，操作“未读”消息列表；在步骤S205中，操作“待处理”消息列表，即，若根据“未读”消息列表中的某一消息的偏移量，从Broker服务器中获取到该条消息，则将该条消息从“未读”消息列表中移出，并将其添加至“待处理”消息列表；同样在步骤S205中，操作“已处理”消息列表和“异常”消息列表，即若成功处理“待处理”消息列表中的某一消息，并成功上报对应的处理结果，则将该消息从“待处理”消息列表中移出，并将其添加至“已处理”消息列表，另一方面，若未能成功处理“待处理”消息列表中的某一消息，或者即便该消息被成功处理但未能成功上报对应的处理结果，则将该消息从“待处理”消息列表中移出，并将其添加至“异常”消息列表。

在一个实施例中，可以在Broker服务器和/或消息使用方不繁忙时，启动对状态为“异常”的消息的处理。在另一个实施例中，按比例处理新的未读消息和状态为“异常”的消息。

在一优选的实施例中，将缓存中存储的所述未读消息在所述分区的位置信息(即“未读”消息列表)、业务处理异常的未读消息对应的位置信息(即“异常”消息列表)进行备份存储，以达到容灾的目的。实际应用中，可以通过本地存储、发送到远程服务器上的方式进行备份存储。当所述Mac客户端发生故障(比如宕机、客户端被销毁)时，根据备份存储的位置信息获取对应的消息，在另一台运行环境良好的客户端中，重新开始对所述消息的业务处理。该方式能够保证数据无丢失的重新开始处理，而且不存在重复处理的问题。另外，由于备份的数据为偏移量，而非消息本身，数据量小，备份传输容易，节约带宽。

在另一优选的实施例中，收集每个未读消息对应的偏移量的获取情况和对每个未读消息的处理状态，并按照日期顺序存储。方便日后管理消息处理的状态以及查找定位问题。

通过本发明实施例的消息处理方法可以看出，通过缓存未读消息的位置信息，并通过线程获取与所述缓存中的位置信息相应的未读消息，之后对未读消息进行业务处理，能够根据缓存中指定的位置信息获取未读消息，提高了消息处理实时性；根据缓存中的消息的最大偏移量以及分区中的未读消息的偏移量确定未读消息的数量，以方便后续进行线程分配；将未读消息的位置信息倒序存储到缓存中，以优先处理最新到来的消息，增加消息处理的实时性；通过更新未读消息在缓存中的状态，方便根据其状态进行后续处理；将位置信息和状态进行备份存储，而非消息本身，数据量小、备份传输容易、节约带宽，而且在客户端发生故障时，能够保证数据无丢失、无重复的重新开始处理。

图4是根据本发明实施例的消息处理装置的主要模块的示意图。如图4所示，本发明实施例的消息处理装置400，主要包括：

获取存储模块401，用于根据消息使用方所订阅的消息主题和分区，获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中。作为消息使用方的客户端根据其订阅的消息主题和分区，从服务端中获取未读消息在所述分区的位置信息；之后根据所述未读消息在所述分区的位置信息，确定所述未读消息的数量。其中，所述客户端可以是Windows客户端、Mac客户端等；所述服务器可以是Linux服务器、Unix服务器等；所述消息主题，可以被认为是消息类型，比如可以是崩溃类数据、库存类数据、订单类数据等；所述分区是物理上的概念，对应一个物理存储，例如以文件形式表示分区。每个主题中包括一个或者多个分区。所述位置信息，即每条消息在分区中的位置，也被称为偏移量，可被理解为该消息自起始位置起的偏移位置。

统计分配模块402，用于统计所述未读消息的数量，分配与所述未读消息的数量相对应的线程，其中，所述线程用于获取所述未读消息。根据所述缓存中的消息的最大偏移量、以及所述分区中的未读消息的偏移量确定所述未读消息的数量。在作为消息使用方的客户端中，预先建立包括至少一个线程的线程池，并配置每个线程的处理能力；根据线程池中每个线程的处理能力以及所述未读消息的数量，从线程池中选择适当数量的线程来处理消息。用于处理消息的每个线程会可被认为是一个消息使用方，用于处理获取存储模块401中所获取的某一消息主题、某一分区的消息。

业务处理模块403，用于通过所述线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息，以对所获取到的消息进行业务处理。根据不同的业务需求，预先定义消息处理逻辑。作为消息使用方的各个线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息；然后根据预先定义的消息处理逻辑，对所述未读消息进行业务处理。

另外，本发明实施例的消息处理装置400还可以包括：消息状态迁移模块、备份存储模块、结果上报模块和日志模块(图4中未示出)。其中，消息状态迁移模块，用于在将所述未读消息的位置信息存储到缓存中之后，所述未读消息在所述缓存中的状态被设置为未读；在获取到所述分区中的、与所述缓存中的位置信息相应的未读消息之后，所述消息在所述缓存中的状态被设置为待处理；以及在对所获取到的消息成功进行业务处理之后，所述消息在所述缓存中的状态被设置为已处理，在未能对所获取到的消息成功进行业务处理的情况下，所述消息在所述缓存中的状态被设置为异常。所述备份存储模块，用于对所述缓存中的消息的位置信息和状态进行备份存储。所述结果上报模块，用于将对所述消息进行业务处理后的结果，上报至业务处理结果存储服务器(即Kafka集群)。所述日志模块，用于收集每个未读消息对应的偏移量的获取情况和对每个未读消息的处理状态，并按照日期顺序存储。

图5是根据本发明实施例的消息处理系统的主要模块的示意图。如图5所示，本发明实施例的消息处理系统主要包括：消息生成方、Kafka集群、消息使用方和缓存模块。其中，所述消息生成方用于生成消息，并将所述消息发送至Kafka集群；其中，所述消息中包括主题和键，所述键用来确定将所述消息发送至所述主题的哪个分区。所述Kafka集群用于接收来自消息生成方的消息，将所述消息写入到与所述消息的主题相同的分区；还用于接收来自消息使用方的位置信息的获取请求，并响应所述获取请求。所述消息使用方中包括获取存储模块、统计分配模块、业务处理模块和结果上报模块，各模块的具体功能以及实现如前所述。所述缓存模块用于存储未读消息的偏移量以及状态，该模块可以设置在数据使用方，实现对该数据使用方的未读消息的偏移量以及状态的存储；另外，该模块还可以设置在Kafka集群，实现对该多个数据使用方的未读消息的偏移量以及状态的分别存储。实施例中，所述消息生成方由一个或者多个iOS客户端构成，每个iOS客户端可以包括一个或者多个消息生成方；所述Kafka集群由一个或者多个Linux服务端构成；所述消息使用方由一个或者多个Mac客户端构成，每个Mac客户端可以包括一个或者多个消息使用方。

在一优选的实施例中，缓存模块通过锁机制来保证缓存数据的线程安全。当缓存数据发生变化时，立即通知备份存储模块。且缓存模块操作自身数据，没有使用数据库，效率高。本发明的实施例非常容易在机器上部署，运行环境只需要满足Kafka系统的运行需求就可以。当一台机器的处理效率不能满足需求的时候，可以通过增加机器来提高处理能力，服务器会将未读消息平均分给新加入的机器，客户端也很容易部署消息处理程序。

从以上描述可以看出，通过缓存未读消息的位置信息，并通过线程获取与所述缓存中的位置信息相应的未读消息，之后对未读消息进行业务处理，能够根据缓存中指定的位置信息获取未读消息，提高了消息处理实时性；根据缓存中的消息的最大偏移量以及分区中的未读消息的偏移量确定未读消息的数量，以方便后续进行线程分配；将未读消息的位置信息倒序存储到缓存中，以优先处理最新到来的消息，增加消息处理的实时性；通过更新未读消息在缓存中的状态，方便根据其状态进行后续处理；将位置信息和状态进行备份存储，而非消息本身，数据量小、备份传输容易、节约带宽，而且在客户端发生故障时，能够保证数据无丢失、无重复的重新开始处理。

图6示出了可以应用本发明实施例的消息处理方法或消息处理装置的示例性系统架构600。

如图6所示，系统架构600可以包括终端设备601、602、603，网络604、服务器605和客户端606。网络604用以在终端设备601、602、603和服务器605之间提供通信链路的介质。网络604可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备601、602、603通过网络604与服务器605交互，以接收或发送消息等。终端设备601、602、603上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备601、602、603可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器605可以是提供各种服务的服务器，例如对用户利用终端设备601、602、603所生成的崩溃数据提供支持的后台管理服务器。后台管理服务器可以对接收到的崩溃数据进行数据存储等处理，并在收到数据获取请求后将对应数据(例如崩溃数据对应的位置信息)反馈给客户端606。

客户端606可以是提供本地服务的设备，例如可以从服务器605获取数据(例如获取崩溃数据对应的位置信息)，并对数据进行处理得到处理结果(例如崩溃解析结果)，将处理结果反馈给服务器605。

需要说明的是，本申请实施例所提供的消息处理方法一般由客户端606执行，相应地，消息处理装置一般设置于客户端606中。

应该理解，图6中的终端设备、网络、服务器和客户端的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络、服务器和客户端。

根据本发明的实施例，本发明还提供了一种电子设备和一种计算机可读介质。

本发明的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例的一种消息处理方法。

本发明的计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例的一种消息处理方法。

下面参考图7，其示出了适用于来实现本发明实施例的电子设备的计算机系统700的结构示意图。图7示出的电子设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元(CPU)701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM 703中，还存储有计算机系统700操作所需的各种程序和数据。CPU 701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本发明公开的实施例，上文主要步骤图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行主要步骤图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(CPU)701执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括获取存储模块、统计分配模块和业务处理模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，获取存储模块还可以被描述为“根据消息使用方所订阅的消息主题和分区，获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：根据消息使用方所订阅的消息主题和分区，获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中；统计所述未读消息的数量，分配与所述未读消息的数量相对应的线程，其中，所述线程用于获取所述未读消息；通过所述线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息，以对所获取到的消息进行业务处理。

从以上描述可以看出，通过缓存未读消息的位置信息，并通过线程获取与所述缓存中的位置信息相应的未读消息，之后对未读消息进行业务处理，能够根据缓存中指定的位置信息获取未读消息，提高了消息处理实时性；根据缓存中的消息的最大偏移量以及分区中的未读消息的偏移量确定未读消息的数量，以方便后续进行线程分配；将未读消息的位置信息倒序存储到缓存中，以优先处理最新到来的消息，增加消息处理的实时性；通过更新未读消息在缓存中的状态，方便根据其状态进行后续处理；将位置信息和状态进行备份存储，而非消息本身，数据量小、备份传输容易、节约带宽，而且在客户端发生故障时，能够保证数据无丢失、无重复的重新开始处理。

上述产品可执行本发明实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明实施例所提供的方法。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (14)

1.一种消息处理方法，其特征在于，包括：

根据消息使用方所订阅的消息主题和分区，获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中；

统计所述未读消息的数量，分配与所述未读消息的数量相对应的线程，其中，所述线程用于获取所述未读消息；

通过所述线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息，以对所获取到的消息进行业务处理。

2.根据权利要求1所述的方法，其特征在于，所述位置信息为偏移量，所述获取未读消息在所述分区的位置信息，包括：获取所述未读消息在所述分区的偏移量，所述未读消息的数量是根据所述缓存中的消息的最大偏移量、以及所述分区中的未读消息的偏移量确定的。

3.根据权利要求1所述的方法，其特征在于，所述将所述未读消息的位置信息存储到缓存中，包括：将所述未读消息的位置信息倒序存储到缓存中。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在将所述未读消息的位置信息存储到缓存中之后，所述未读消息在所述缓存中的状态被设置为未读；

在获取到所述分区中的、与所述缓存中的位置信息相应的未读消息之后，所述消息在所述缓存中的状态被设置为待处理；

在对所获取到的消息成功进行业务处理之后，所述消息在所述缓存中的状态被设置为已处理，在未能对所获取到的消息成功进行业务处理的情况下，所述消息在所述缓存中的状态被设置为异常。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

对所述缓存中的消息的位置信息和状态进行备份存储。

6.根据权利要求1-4的任一项所述的方法，其特征在于，所述方法还包括：

将对所述消息进行业务处理后的结果，上报至业务处理结果存储服务器。

7.一种消息处理装置，其特征在于，包括：

获取存储模块，用于根据消息使用方所订阅的消息主题和分区，获取未读消息在所述分区的位置信息，将所述未读消息的位置信息存储到缓存中；

统计分配模块，用于统计所述未读消息的数量，分配与所述未读消息的数量相对应的线程，其中，所述线程用于获取所述未读消息；

业务处理模块，用于通过所述线程获取所述分区中的、与所述缓存中的位置信息相应的未读消息，以对所获取到的消息进行业务处理。

8.根据权利要求7所述的装置，其特征在于，所述位置信息为偏移量，所述获取存储模块，还用于：获取所述未读消息在所述分区的偏移量，所述未读消息的数量是根据所述缓存中的消息的最大偏移量、以及所述分区中的未读消息的偏移量确定的。

9.根据权利要求7所述的装置，其特征在于，所述获取存储模块，还用于：将所述未读消息的位置信息倒序存储到缓存中。

10.根据权利要求7所述的装置，其特征在于，所述装置还包括：消息状态迁移模块，用于

在将所述未读消息的位置信息存储到缓存中之后，所述未读消息在所述缓存中的状态被设置为未读；

在获取到所述分区中的、与所述缓存中的位置信息相应的未读消息之后，所述消息在所述缓存中的状态被设置为待处理；以及

在对所获取到的消息成功进行业务处理之后，所述消息在所述缓存中的状态被设置为已处理，在未能对所获取到的消息成功进行业务处理的情况下，所述消息在所述缓存中的状态被设置为异常。

11.根据权利要求10所述的装置，其特征在于，所述装置还包括：备份存储模块，用于对所述缓存中的消息的位置信息和状态进行备份存储。

12.根据权利要求7-10的任一项所述的装置，其特征在于，所述装置还包括：结果上报模块，用于将对所述消息进行业务处理后的结果，上报至业务处理结果存储服务器。

13.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-6中任一所述的方法。

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

Images