《disruptor笔记》系列链接
- 快速入门
- Disruptor类分析
- 环形队列的基础操作(不用Disruptor类)
- 事件消费知识点小结
- 事件消费实战
- 常见场景
- 等待策略
- 知识点补充(终篇)
关于独立消费和共同消费
- 本篇是《disruptor笔记》的第四篇，前面章节写了不少代码，搞得读者和作者都辛苦，本篇稍微放松一下，熟悉一个重要概念：disruptor事件的消费模式，包括独立消费和共同消费两种；
- 举个例子，假设在电商场景中，每产生一个订单都要发邮件和短信通知买家，如果产生了十个订单，就有以下两种情况要考虑： 第一种：要发十封邮件和十条短信，此时，邮件系统和短信系统是各自独立的，他们各自消费这十个订单的事件，也就是说十个事件被消费二十次，所以邮件系统和短信系统各自独立消费，彼此没有关系，如下图，一个原点代表一个事件：
第二种：假设邮件系统处理能力差，为了提升处理能力，部署了两台邮件服务器，因此是这两台邮件服务器共同处理十个订单事件，合起来一共发送了十封邮件，如下图，一号邮件服务器和二号邮件服务器是共同消费，某个订单事件只会在一个邮件服务器被消费：
独立消费的核心知识点
- 使用的API是handleEventsWith
- 业务处理逻辑放入EventHandler的实现类中
- 内部实现用BatchEventProcessor类，一个消费者对应一个BatchEventProcessor实例，任务是获取事件再调用EventHandler的onEvent方法处理
- 一个消费者对应一个SequenceBarrier实例，用于等待可消费事件
- 一个消费者对应一个Sequence实例（BatchEventProcessor的成员变量），用于记录消费进度
- 每个BatchEventProcessor实例都会被放入集合（consumerRepository.consumerInfos）
- Disruptor的start方法中，会将BatchEventProcessor放入线程池执行，也就是说每个消费者都在独立线程中执行
共同消费的核心知识点
- 使用的API是handleEventsWithWorkerPool
- 业务处理逻辑放入WorkHandler的实现类中
- 内部实现用WorkerPool和WorkProcessor类合作完成的，WorkerPool实例只有一个，每个消费者对应一个WorkProcessor实例
- SequenceBarrier实例只有一个，用于等待可消费事件
- 每个消费者都有自己的Sequence实例，另外还有一个公共的Sequence实例（WorkerPool的成员变量），用于记录消费进度
- WorkerPool实例会包裹成WorkerPoolInfo实例再放入集合（consumerRepository.consumerInfos）
- Disruptor的start方法中，会调用WorkerPool.start方法，这里面会将每个WorkProcessor放入线程池执行，也就是说每个消费者都在独立线程中执行
精简的小结
- 上述核心知识点还是有点多，咱们用对比来精简一下，以下是精华中的精华，真不能再省了，请重点关注：
- 独立消费的每个消费者都有属于自己独有的SequenceBarrier实例，共同消费者是所有人共用同一个SequenceBarrier实例
- 独立消费的每个消费者都有属于自己独有的Sequence实例，对于共同消费者，虽然他们也有属于自己的Sequence实例，但这个Sequence实例的值是从一个公共Sequence实例（WorkerPool的成员变量workSequence）得来的
- 独立消费和共同消费都有自己的取数据再消费的代码，放在一起对比看就一目了然了，如下图，共同消费时，每个消费者的Sequence值其实来自公共Sequence实例，多线程之间用CAS竞争来抢占事件用于消费：
用图说话
- 最后放上自制图一张，希望有一图胜千言的效果吧：
- 至此，理论分析结束，接下来的文章会乘热打铁，基于上述知识点进行实战，编码实现三个场景：
- 100个订单，短信和邮件系统独立消费
- 100个订单，邮件系统的两个邮件服务器共同消费；
- 100个订单，短信系统独立消费，与此同时，两个邮件服务器共同消费；
