[发明专利]一种基于消费队列的消费方法、终端及计算机可读存储介质

说明书

技术领域

本发明涉及通信技术领域，尤其涉及一种基于消费队列的消费方法、终端及计算机可读存储介质。

背景技术

消息(Message)是在两台计算机间传送的数据，消息可以非常简单，只包含少量文本字符串，也可以更复杂，包含较大的对象数据。消费队列机制为应用程序开发人员提供了一种应用程序间快速可靠的通信方式，即通过消息的传递来实现信息的交互。

消费队列系统(又名消息中间件)被广泛的用于各个互联网公司。作为消息的一种缓冲机制，它可以有效的减轻公司后台服务器的压力。

一个典型的消费队列系统由三部分组成：

1.生产者端：负责向消费队列发送消息的终端。

2.消费者端：从消费队列中获得消息的终端。

3.消费队列：用于存储消息的中间件。通常来说，消费队列系统的中间件包括多个消费队列，这些消费队列用于存储生产者端发送过来的消息。消费队列通常设置在至少一台服务器上，在实际操作中通常为多台服务器。

由于这种系统是由三部分组成，所以可以有多个生产者端向同一个中间件发送消息，也有可能会有多个消费者端从中间件中拉取消息，进行消费。

举例来说，对于电商而言，用户作为生产者端，其产生的订单会被首先发送至消费队列，然后其他程序作为消费者端，会从该消费队列中拉取消息进行消费，即对订单进行处理。采用消费队列的好处是：不管前台产生订单的速度如何迅猛，通过中间消费队列的缓存，可以保证后台程序的正常运行，从而避免了网络波峰可能对后台服务器造成的压力。

不仅如此，消费队列还被广泛用在及时通讯等应用中。比如当两台终端通讯时，首先由终端一发送了一条消息给自己的好友，该消息会被缓存在消费队列中，继而被推送至对应好友的终端的软件中。这种设计的好处是，当好友不在线(即没有打开对应的软件时)，消费队列可以被当作一种数据的存储工具。由于不需要提供查询、删除等操作，所以使用消费队列作为存储工具，比传统的数据库要高效很多。

以下为消费队列系统的具体工作方式：

生产者端一般采用轮询的方式向各个消费队列轮流发送消息，例如中间件中一共有3个消费队列，那么生产者端会采用“消费队列1-消费队列2-消费队列3-消费队列1-消费队列2-消费队列3”这种顺序，分别向各个消费队列发送消息。

对于消费者端，目前，对于绝大数消费队列系统，消费者端都可以自己决定每次从中间件拉取多少条消息，而所拉取的消息是从一个消费队列获取还是从多个消费队列获取一般由系统本身决定。目前而言，大多数开源系统采用轮询的方式，轮流的从各个消费队列获取消费者端需要的消息。例如，当有三个消费队列的时候，消费者端如果先后发送了获取1条消息，10条消息，100条消息的命令，那么系统会相应的从消费队列1获取1条消息给消费者端，从消费队列2获取10条消息给消费者端，从消费队列3获取100条消息给消费者端。

但是，目前的消费方案不能保证每个消息都被消费这消费掉，即存在不被消费掉的消息。目前的绝大数消费队列系统在以下几个场景中会出现消费不掉的现象：

场景一，当生产者端没有严格按照轮询的方式向各个消费队列发送消息，但是消费者端依然采用轮询的方式来消费，此时就会造成某个消费队列中的消息积压。例如，假设有3个消费队列，而生产者端轮询的向3个消费队列发送消息，但是并不是每次都发送1条，而是给消费队列1发送10条消息，给消费队列2发送100条消息，给消费队列3发送1000条消息。那么如果消费者端仍然按照轮询均匀的消费，那么消费队列3的消息会严重积压，导致消费队列3消费不掉的现象出现。

场景二，生产者端并非均匀消费。例如，消费者端可以按照每次1条消息，10条消息，100条消息的顺序从各个消费队列拉取消息，那么消费队列3的消息会被消费得很快，而消费队列1的消息会消费的很慢，尽管这两个消费队列的消息生产时间也许是一致的，同样造成消费队列1消费不掉的现象出现。

场景三，服务器集群的某个节点宕机。消费队列往往支持分布式部署，多个消费队列可能分布在不同的节点上，当一个节点宕机之后，该节点上存储的消费队列不能继续接收消息，但是其他在线的节点仍然在接收消息，或者消费端仍在从其他在线节点消费消息。当该节点从故障中恢复过来之后，其存储的消息数量要小于其他节点上消费队列的消息数量。这也会导致消费对象消费不掉的现象。

基于以上情况，如何保证每个消费在任何情况下都能被消费者端正确的消费掉是本领域亟待解决的问题，目前各个开源系统都没有完美的解决这一问题。

发明内容