Disruptor日記實現

Question

在Martin Fowler關於LMAX干擾器架構的文章中 ，他說：

記者的工作是將所有事件以持久形式存儲，以便在發生任何錯誤時可以將其重播。 LMAX為此不使用數據庫，而僅使用文件系統。 他們將事件流式傳輸到磁盤上。

我很好奇在實踐中基於文件系統的事件日志的實現情況。 下面的答案說它被寫入了一個“原始文件”，但是我對一個人可能為生產系統實現的實際細節感興趣。 從字面上看，它是包含連續添加到的結構化日志的原始文本文件嗎？ 還是某種二進制格式？ 系統的這一部分是否有任何重要的設計決策？

Answer 1

建議的新聞工作者需要包含兩條信息：接收到的事件本身和某種標識符，以跟蹤您在日志中的位置，以便您可以選擇在重放期間從該記錄開始。

存儲格式最終由您決定，但是需要考慮以下因素：

• 重播可能不僅需要從系統崩潰中觸發，還需要從您自己的代碼中的錯誤中觸發。 輸入消息字節流的操縱次數越少越好。 字節流的任何操作都會帶來錯誤的機會，並使重放邏輯與“將字節放回輸入緩沖區”大不相同。 對我來說，這可能是最大的決定。

• 重播應快速且不包含業務邏輯。 允許您的存儲設備順序存儲而不需要來回跳動的文件格式（例如具有索引的數據庫）將可以提高性能。 環形緩沖區輸入和存儲層之間的層越多，速度就越慢。

• 磁盤上預先分配的存儲空間（甚至可以使用RAW分區）將使您可以從頭到尾寫入字節，而無需更新目錄元數據和文件系統的自由空間跟蹤區域。 這應該簡化並提高性能。 只要此預分配足以將所有數據保留在檢查點之間，就可以了。 隨着時間的流逝，隨着存儲設備的改進，這不再是一個問題。

Answer 2

新聞發布者只是主應用程序環形緩沖區的另一個使用者。 消息從線路上讀取，添加標頭（接收到的時間戳等），然后饋入環形緩沖區。

有三個消費者：

1. 應用程序處理程序（調用業務邏輯）
2. 復制發件人（將消息復制到輔助發件人）
3. 日記處理程序

應用程序處理程序將在日記程序完成時得到門控，並在輔助服務器上進行確認，以確保在處理應用程序消息之前，接收到的消息位於輔助服務器的環形緩沖區和本地系統頁面緩存中。

新聞工作者非常愚蠢-消息以有線格式附加到固定長度的日志文件中。 預先預先分配了文件，並且使用了各種文件系統掛載選項來最大程度地減少寫延遲。 最后，我們發現XFS是最好的文件系統選項，但是只有在沒有正在寫入的日志文件的並發讀取器的情況下才可以。 否則，XFS代碼中可能會有討厭的鎖定效果。

如果您對我們如何得出這些結論感興趣，我將所有這些都寫得非常詳盡。

https://epickrram.blogspot.co.uk/2015/05/improving-journalling-latency.html

https://epickrram.blogspot.co.uk/2015/07/seek-write-vs-pwrite.html

https://epickrram.blogspot.co.uk/2015/12/journalling-revisited.html