Disruptor－架构思维的转变

本人新书出版，对技术感兴趣的朋友请关注：

https://mp.weixin.qq.com/s/uq2cw2Lgf-s4nPHJ4WH4aw

在前一篇中，我们分析了Disruptor为什么那么快，分析了围绕RingBuffer的无锁技术。但我认为，相对于无锁技术，Disruptor对于架构思维的转变，才是其最大亮点。

Pub Event

说到RingBuffer做的队列，通常都说的是“一读一写“，或者“多读一写“。而Disruptor天生是为“广播“设计，也就是1个Producer，多个Consumer消费同1条消息。

有了“广播“，就能很好的支持不同逻辑模块的并行计算，从而提高性能。下面会专门分析一个案例，来讨论这个并行计算。

Consumer依赖关系维护

假设有如下一个场景：1个生成者P1，3个消费者C1, C2, C3。其中C3要依赖C1, C2执行完毕。如果基于传统的消息队列来设计，就会是如下的菱形结构：

之间用4个队列来连接，从P1流经到C3，要经过这4个队列。

而如果用Disruptor的话，将只需要一个RingBuffer，3个consumer都消费这同1个RingBuffer，如下图所示：

在这里，有几个关键点：
（1）C1, C2, C3消费的是同一个RingBuffer，因为进度不一样，它们各自有自己的指针，称之为Sequence。这里假设为S1, S2, S3

（2）C3是要依赖C1, C2的，也就是它要等C1, C2消费完之后，它才能消费。因此S3取的是Min(S1, S2)。

（3）假设P1的指针是S0，P1只需要和S3比较就行了，而不需要和S1, S2比较。因为S3是消费最慢的，只要P1没有跟上S3，那么队列就不会被覆盖。

依赖关系的表达

具体到Disruptor中，如何表达C3依赖C1, C2呢？代码举例如下，很简单：

//handler1, 2, 3, 4同时消费一个RingBuffer，2, 3, 4并行，同时依赖1
disruptor.handleEventsWith(handler1).then(handler2, handler3, handler4);

//handler1,2,3,4同时消费一个RingBuffer，2依赖1，3依赖2，4依赖3
disruptor.handleEventsWith(handler1).then(handler2).then(handler3).then(handler4);

Event Resourcing

在Marin Flower介绍LMAX的价格的时候，http://martinfowler.com/articles/lmax.html

提出了一种思想：Event Resourcing
http://martinfowler.com/eaaDev/EventSourcing.html

下面以LMAX的架构为例，来讲解这种思想：

如上图所示，Receiver接收请求（这里的Receiver你可以理解为一个网络服务器），BLP处理请求，Publisher把处理结果交给下游。

在这里，BLP是纯粹在内存中操作，那它挂了之后，状态怎么恢复呢？这里有3个关键点：
（1）在BLP处理每一个Event之前，该Event先被Journaler日志化
（2）BLP本身是个状态机。即使挂了，可以重放所有日志，恢复状态。另外，为了提高恢复速度，BLP的状态可以定期做Snapshot。
（3）为了提高HA，可以准备多个BLP并行，1个挂了，切换到其它的。所以有一个Replicator组件，用于复制日志。

在这里，Receiver、BLP、Journaler、Replicator通过一个RingBuffer进行交互，如下图所示：

在这里有1个Producer，4个Consumer，前3个可以并行，最后一个BLP依赖前3个。

Un-marshaller在这里做一些Event的解析工作。

这种架构还有一个巨大优点就是：可测性。你可以把日志拷贝到测试环境，“重放“整个过程来测试BLP。

总结

通过上面的分析，我们会发现Disruptor并不是我们通常意义上的一个简单的RingBuffer。

基于它LMAX设计了一个新的架构，这种架构不仅速度够快，而且具有持久性、HA、可测性等诸多优点。