可觀察到像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) ），它本身現在可能導致緩沖區膨脹。