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并行，同时依赖1disruptor.handleEventsWith(handler1).then(handler2, handler3, handler4);//handler1,2,3,4同时消费一个RingBuffer，2依赖1，3依赖2，4依赖3disruptor.handleEventsWith(handler1).then(handler2).then(handler3).then(handler4);

Event Resourcing

在Marin Flower介绍LMAX的价格的时候，

提出了一种思想：Event Resourcing

下面以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、可测性等诸多优点。

--------------------- 本文来自 travi 的CSDN 博客，全文地址请点击：https://blog.csdn.net/chunlongyu/article/details/53313575?utm_source=copy

转载于:https://www.cnblogs.com/felixzh/p/9711276.html

你可能感兴趣的文章