disruptor笔记之四：事件消费知识点小结

《disruptor笔记》系列链接

1. 快速入门
2. Disruptor类分析
3. 环形队列的基础操作(不用Disruptor类)
4. 事件消费知识点小结
5. 事件消费实战
6. 常见场景
7. 等待策略
8. 知识点补充(终篇)

关于独立消费和共同消费

• 本篇是《disruptor笔记》的第四篇，前面章节写了不少代码，搞得读者和作者都辛苦，本篇稍微放松一下，熟悉一个重要概念：disruptor事件的消费模式，包括独立消费和共同消费两种；
• 举个例子，假设在电商场景中，每产生一个订单都要发邮件和短信通知买家，如果产生了十个订单，就有以下两种情况要考虑： 第一种：要发十封邮件和十条短信，此时，邮件系统和短信系统是各自独立的，他们各自消费这十个订单的事件，也就是说十个事件被消费二十次，所以邮件系统和短信系统各自独立消费，彼此没有关系，如下图，一个原点代表一个事件：

第二种：假设邮件系统处理能力差，为了提升处理能力，部署了两台邮件服务器，因此是这两台邮件服务器共同处理十个订单事件，合起来一共发送了十封邮件，如下图，一号邮件服务器和二号邮件服务器是共同消费，某个订单事件只会在一个邮件服务器被消费：

独立消费的核心知识点

1. 使用的API是handleEventsWith
2. 业务处理逻辑放入EventHandler的实现类中
3. 内部实现用BatchEventProcessor类，一个消费者对应一个BatchEventProcessor实例，任务是获取事件再调用EventHandler的onEvent方法处理
4. 一个消费者对应一个SequenceBarrier实例，用于等待可消费事件
5. 一个消费者对应一个Sequence实例（BatchEventProcessor的成员变量），用于记录消费进度
6. 每个BatchEventProcessor实例都会被放入集合（consumerRepository.consumerInfos）
7. Disruptor的start方法中，会将BatchEventProcessor放入线程池执行，也就是说每个消费者都在独立线程中执行

共同消费的核心知识点

1. 使用的API是handleEventsWithWorkerPool
2. 业务处理逻辑放入WorkHandler的实现类中
3. 内部实现用WorkerPool和WorkProcessor类合作完成的，WorkerPool实例只有一个，每个消费者对应一个WorkProcessor实例
4. SequenceBarrier实例只有一个，用于等待可消费事件
5. 每个消费者都有自己的Sequence实例，另外还有一个公共的Sequence实例（WorkerPool的成员变量），用于记录消费进度
6. WorkerPool实例会包裹成WorkerPoolInfo实例再放入集合（consumerRepository.consumerInfos）
7. Disruptor的start方法中，会调用WorkerPool.start方法，这里面会将每个WorkProcessor放入线程池执行，也就是说每个消费者都在独立线程中执行

精简的小结

• 上述核心知识点还是有点多，咱们用对比来精简一下，以下是精华中的精华，真不能再省了，请重点关注：
• 独立消费的每个消费者都有属于自己独有的SequenceBarrier实例，共同消费者是所有人共用同一个SequenceBarrier实例
• 独立消费的每个消费者都有属于自己独有的Sequence实例，对于共同消费者，虽然他们也有属于自己的Sequence实例，但这个Sequence实例的值是从一个公共Sequence实例（WorkerPool的成员变量workSequence）得来的
• 独立消费和共同消费都有自己的取数据再消费的代码，放在一起对比看就一目了然了，如下图，共同消费时，每个消费者的Sequence值其实来自公共Sequence实例，多线程之间用CAS竞争来抢占事件用于消费：

用图说话

• 最后放上自制图一张，希望有一图胜千言的效果吧：

• 至此，理论分析结束，接下来的文章会乘热打铁，基于上述知识点进行实战，编码实现三个场景：
• 100个订单，短信和邮件系统独立消费
• 100个订单，邮件系统的两个邮件服务器共同消费；
• 100个订单，短信系统独立消费，与此同时，两个邮件服务器共同消费；