Внедрение в журнал Disruptor

Question

В статье Мартина Фаулера о архитектуре 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