可观察到像Lmax Disruptor这样的批处理

Question

熟悉lmax环形缓冲区（干扰器）的人都知道，该数据结构的最大优势之一是它可以批量处理传入的事件，当我们有一个使用者可以利用批量处理使系统自动适应负载时，您向它扔的事件越多越好。

我想知道我们能否通过Observable（针对批处理功能）实现相同的效果。 我已经尝试了Observable.buffer，但这是非常不同的，在预期的事件数未到达时，buffer将等待并且不发出批处理。 我们想要的是完全不同的。

给定子订阅者正在等待Observable<Collection<Event>>的批处理，当单个项目到达流时，它将发出单个元素批处理，该批处理由订户处理，而正在处理其他元素的到达并收集到下一个批处理中，订阅者执行完毕后，将获得下一个批次，该批次具有自上次处理开始以来到达的事件数量...

因此，结果是，如果我们的订户足够快地同时处理一个事件，它将处理一次事件，如果负载变大，它仍然具有相同的处理频率，但是每次处理的事件却更多（从而解决了背压问题）...缓冲区将粘住并等待批处理填满。

有什么建议么？ 还是我应该带环形缓冲器？

Answer 1

RxJava和Disruptor代表两种不同的编程方法。

我对Disruptor并没有经验，但是基于视频对话，它基本上是一个很大的缓冲区，生产者可以像消防水带一样发射数据，而消费者旋转/屈服/阻塞直到有可用数据为止。

另一方面，RxJava的目标是非阻塞事件传递。 我们也有环形缓冲区，特别是在observeOn中，它充当生产者和使用者之间的异步边界，但是这些缓冲区要小得多，并且通过应用协同例程方法可以避免缓冲区溢出和缓冲区膨胀。 协同例程归结为发送给您的回调的回调，因此您可以回调我们的回调以按照您的节奏向您发送一些数据。 这种请求的频率决定了步调。

有些数据源不支持此类合作社流，并且需要onBackpressureXXX运算符之一，如果下游请求的速度不够快，它们将缓冲/删除值。

如果您认为可以比一对一的方式更有效地处理数据，则可以使用具有重载功能的buffer运算符来指定缓冲区的持续时间：例如，您可以拥有价值10毫秒的数据，而与在此持续时间内到达多少值。

通过请求频率控制批次大小非常棘手，并且可能会产生不可预见的后果。 通常，问题是，如果您从批处理源request(n) ，则表明您可以处理n个元素，但是源现在必须创建n个大小为1的缓冲区（因为类型为Observable<List<T>> ） 。 相反，如果未调用任何请求，则运算符将缓冲数据，从而导致更长的缓冲区。 如果您真的能跟上步伐，这些行为会在处理中产生额外的开销，并且还必须将冷源转换为firehose（因为否则，您的本质就是buffer(1) ），它本身现在可能导致缓冲区膨胀。