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

Posted 2021-06-14 程序员欣宸

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码)：https://github.com/zq2599/blog_demos

关于独立消费和共同消费

• 本篇是《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放入线程池执行，也就是说每个消费者都在独立线程中执行

精简的小结

• 上述核心知识点还是有点多，咱们用对比来精简一下，以下是精华中的精华，真不能再省了，请重点关注：

1. 独立消费的每个消费者都有属于自己独有的SequenceBarrier实例，共同消费者是所有人共用同一个SequenceBarrier实例
2. 独立消费的每个消费者都有属于自己独有的Sequence实例，对于共同消费者，虽然他们也有属于自己的Sequence实例，但这个Sequence实例的值是从一个公共Sequence实例（WorkerPool的成员变量workSequence）得来的
3. 独立消费和共同消费都有自己的取数据再消费的代码，放在一起对比看就一目了然了，如下图，共同消费时，每个消费者的Sequence值其实来自公共Sequence实例，多线程之间用CAS竞争来抢占事件用于消费：
   

用图说话

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

• 至此，理论分析结束，接下来的文章会乘热打铁，基于上述知识点进行实战，编码实现三个场景：

1. 100个订单，短信和邮件系统独立消费
2. 100个订单，邮件系统的两个邮件服务器共同消费；
3. 100个订单，短信系统独立消费，与此同时，两个邮件服务器共同消费；

你不孤单，欣宸原创一路相伴

1. Java系列
2. Spring系列
3. Docker系列
4. kubernetes系列
5. 数据库+中间件系列
6. DevOps系列