disruptor笔记之四（事件消费知识点小结）云计算

欢迎访问我的GitHub
https://github.com/zq2599/blog_demos
内容：所有原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等；
《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竞争来抢占事件用于消费：

【disruptor笔记之四（事件消费知识点小结）】