Архитектура LMAX - рост данных

Question

Рассмотрим следующий сценарий из описания архитектуры LMAX от Мартина Фаулера:

Я буду использовать простой не-LMAX пример для иллюстрации. Представьте, что вы делаете заказ на желейные бобы по кредитной карте. <...>

В архитектуре LMAX эту операцию можно разделить на две части. Первая операция будет собирать информацию о заказе и завершаться выводом события (запрошенная проверка кредитной карты) в компанию-эмитент кредитной карты. Затем процессор бизнес-логики будет обрабатывать события для других клиентов, пока не получит событие, подтвержденное кредитной картой, в своем входном потоке событий. При обработке этого события он будет выполнять задачи подтверждения для этого заказа.

Таким образом, заказ хранится в памяти до получения результата обработки платежа.

Теперь давайте предположим, что вместо шага обработки кредитной карты у нас есть шаг, который занимает гораздо больше времени, например: нам нужно выполнить инвентаризацию, где кто-то должен физически проверить, есть ли у нас особый вкус желе, которое было заказано. Это может занять час.

Если это так, не приведет ли к росту объема данных, хранящихся в памяти, потому что потенциально большое количество заказов будет ожидать события обновления состояния запаса?

Возможно, в таком сценарии нам нужно удалить заказ из памяти и включить его как часть выходного события, а внешняя система (инвентарь) отвечает за создание другого входного события, которое включает в себя детали заказа.

Проблема, с которой я сталкиваюсь при таком подходе, заключается в том, что мы не можем включить инвентаризацию как часть процессора бизнес-логики.

Мысли о том, как мы решаем это?

Answer 1

Рабочие заказы в финансовой бирже могут оставаться в течение нескольких дней или даже месяцев как часть рабочего набора. Например, ожидание истечения срока действия фьючерсного контракта. Учетные записи клиентов также похожи. Под "рабочим набором" я подразумеваю сделки / заказы / продажи и т. Д., Которые в настоящее время активны. Как только сделка завершена, она становится частью исторических данных.

Системы памяти теперь настолько велики, т.е. сотни ГБ на одном сервере, что рабочий набор практически любого бизнеса легко помещается в память. Также доступный объем памяти увеличивается со скоростью, намного превышающей рост любого крупного бизнеса.

Сценарий, который вы описываете, на самом деле не является проблемой. Проблема может возникнуть, когда вам нужно хранить все исторические данные, для которых более подходящей является традиционная база данных или файловая система.

Простое упражнение состоит в том, чтобы вычислить объем памяти, необходимый для активных объектов или рабочего набора, а затем сравнить его с тем, что доступно на современных серверах. Можно сохранить в памяти сотни миллионов активных объектов.