前言
消息队列，通常有两种场景，一种是发布者订阅模式，一种是生产者消费者模式。发布者订阅模式，即发布者生产消息放入队列，多个监听的消费者都会收到同一份消息，也就是每个消费者收到的消息是一样的。生产者消费者模式，生产者生产消息放入队列，多个消费者同时监听队列，谁先抢到消息就会从队列中取走消息，最终每个消息只会有一个消费者拥有。
在大数据时代，传统的生产者消费者队列模式中的Topic数目可能从少量的几个变为海量topic。例如要实现一个全网爬虫抓取任务调度系统，每个大型的门户，SNS都会成为一个topic。在topic内部也会有海量的子网页需要抓取。在实现这样的一个任务分发调度系统时可能会遇到以下一些问题：
- 海量的topic，意味着我们可能会有海量的队列。针对爬虫场景，根据网页类型，一类网站对应到一个任务队列，不同的任务队列会有自己的生产者和消费者。
- 生产者和消费者会有多个，在业务峰值期间，产生较大并发访问，消息总量也是海量。针对爬虫任务消息总量可能就是全网的网页地址数量。
- 任务可能会有优先级，为了实现优先级高的任务优先调度，我们可能会在一个topic下再细分子队列。
- 消息消费不能丢失，如果是作为任务的调度消息，我们的消息丢失失零容忍的。
- 消费者模式中如果消费者因为种种原因处理失败或者超时，需要支持消息被重新调度。
- 在保证消息一定会被处理的前提下，我们也要避免少量消息因为各种原因处理堆积，而影响整个系统的吞吐。因为消息读区往往是轻量级，消息的处理是资源密集型。我们不希望因为消息读区堆积导致处理资源闲置。
解决方案
基于TableStore（表格存储）的跨分区高并发，主键自增列这个特性又很好的适配到我们的队列特性。支持海量，不同分区键下使用各自的自增主键，可以很好的实现海量队列。具体我们给出如下方案：
需要设计以下表：
- 任务消息表
- 消息消费checkpoint表
- 全量消息表
在介绍表设计之前，先做一些名词解释。
- 每个任务消息，我们假设已有一个唯一的id。
- 任务优先级，我们假设优先级范围是固定并且已经知道，如果任务优先级过多，可以分层，例如优先级1～100的映射到层级1。这里如果我们的任务没有优先级，那可以根据任务数据量级做一个简单的分桶，然后轮训抓取每个分桶中的任务。
- 两个游标，对应到每个topic的每个优先层级，我们需要记录2个游标位移点。一个是抓取扫描游标，一个是完成游标。扫描游标的定义是指当前任务当前优先层级下，被扫描到的最大位移位置。完成位移点表示改任务当前优先层级下，最大的抓取完成位移点，之前的任务都已经完成抓取。
注：本文内容来自互联网，旨在为开发者提供分享、交流的平台。如有涉及文章版权等事宜，请你联系站长进行处理。