а есть кто-нибудь с практическим опытом работы в LMAX Disruptor?
перечитываю статью фаулера третий раз а понимание некоторых вопросов не приходит, например:
1. имеет ли смысл иметь больше одного input disruptor?
2. как конкретно результат работы un-marshaller попадает к business logic processor?
Здравствуйте, evgeny.e, Вы писали:
EE>1. имеет ли смысл иметь больше одного input disruptor?
The disruptors I've described are used in a style with one producer and multiple consumers, but this isn't a limitation of the design of the disruptor. The disruptor can work with multiple producers too, in this case it still doesn't need locks.[13]
Здравствуйте, evgeny.e, Вы писали:
EE>2. как конкретно результат работы un-marshaller попадает к business logic processor?
Как я понимаю, кольцо хранит ссылку на сообщения. unmarshaller читает сообщение и преобразует его в вид понятный для бизнес-логики.
Бизнес-логика, когда будет читать этот слот, уже будет иметь ссылку на unmarshalled данные.
EE>>1. имеет ли смысл иметь больше одного input disruptor? B>
The disruptors I've described are used in a style with one producer and multiple consumers, but this isn't a limitation of the design of the disruptor. The disruptor can work with multiple producers too, in this case it still doesn't need locks.[13]
если я правильно понял, то несколько продьюсеров могут легко писать в один и тот же дизраптор (причем также потокобезопасно и без состязаний), т.е цитата не обязательно значит несколько дизрапторов
не знаю что у них там происходит на бирже lmax, но обычно есть ряд источников входных данных — внешние системы, пользователи етц, которые все генерируют разнообразные события, и если они все пишут в один гигантский дизраптор, то
1. как выглядит Event? по идее, это всегда должна быть обертка вокруг поля типа Object (да и эвент на самом деле не эвент вовсе а контейнер для эвента)
2. как выглядит EventHandler? по идее, это всегда должен быть рутер, который вызывает один или другой хэндлер в зависимости от типа объекта в контейнере
если же иметь много дизрапторов, то эвенты и эвентхэндлеры можно иметь сколь угодно специализированные (полиморфизм там невозможен, если я правильно понимаю, из-за newInstance() у EventFactory)
по поводу анмаршаллинга из соседнего сообщения — угу, в статье на самом деле есть следующее:
The unmarshaler turns the event data from the wire into a java object that can be used to invoke behavior on the Business Logic Processor. Therefore, unlike the other consumers, it needs to modify the data in the ring buffer so it can store this unmarshaled object.
т.е, если я правильно понимаю, Event (или эвент контейнер) на самом деле содержит 2 "поля" — данные до маршаллинга и данные после, и, соответственно, маршаллер читает данные до и пишет в поле для данных после, что немного ме, попробуй потом проследи, что потоки, читающие данные с дизраптера пишут только в нужные поля
если Event это обертка над полем типа Object как было предложено выше — то конечно можно просто менять объект с сырыми данными на объект с отмаршаллеными, но тогда journaller не сможет работать параллельно с маршаллером (а должен строго до), что вроде отличается от того что написано в статье
и последний (пока) непонятный момент — как конкретно они хранят эти гигантские данные в памяти вместо бд?
если мне нужно найти все ордера по клиенту — ок, создаю хэшмэп клиента на список ордеров, а если нужно найти все ордера по инструменту — рядом создаю еще один хэшмэп — инструмент на список ордеров — и тд, как-то так? или может быть комплекс сырых коллекций и кэшей сверху?
EE>и последний (пока) непонятный момент — как конкретно они хранят эти гигантские данные в памяти вместо бд?
Они сообщения тупо на диски льют. Вроде даже в RAW, без файловой системы (в этом не совсем уверен).
EE>если мне нужно найти все ордера по клиенту — ок, создаю хэшмэп клиента на список ордеров, а если нужно найти все ордера по инструменту — рядом создаю еще один хэшмэп — инструмент на список ордеров — и тд, как-то так? или может быть комплекс сырых коллекций и кэшей сверху?
Паралельно обрабатывающим серверам работают сервера отчётов, которые прогоняют все те же события. Обработчики другие, которые формируют все нужные отчёты. Если какой-то инфы в отчётах нету — есть возможность "прокрутить" все события с начала.
Событий от каждого клиента столько (планировалось столько) что любая БД там или ляжет или бесполезна.
это все так, но я имел ввиду оперативные данные а не persistence, для целей бизнес-логики данные не с диска же будут подниматься?
БД, правда, persistence и есть, но в "типовом" приложении часто она используется и для оперативных данных тоже, если нужны данные — то идет запрос к ДАО и затем в лучшем случае данные возьмутся из кэша, а возможно будет и запрос к БД, от чего отказались в данной архитектуре
опять же, оперативные данные же не только для отчетов нужны, но и для бизнес-логики тоже
так вот, интересно, как конкретно эти оперативные данные в памяти организованы и как осуществляется к ним доступ
з.ы. эх, надо было по-другому тему назвать, вопросы в основном не про дизраптор а про lmax architecture
EE>это все так, но я имел ввиду оперативные данные а не persistence, для целей бизнес-логики данные не с диска же будут подниматься? EE>БД, правда, persistence и есть, но в "типовом" приложении часто она используется и для оперативных данных тоже, если нужны данные — то идет запрос к ДАО и затем в лучшем случае данные возьмутся из кэша, а возможно будет и запрос к БД, от чего отказались в данной архитектуре EE>опять же, оперативные данные же не только для отчетов нужны, но и для бизнес-логики тоже
Все данные в памяти либо в виде потока событий. У LMAX нет БД. Betfair держит наверное самую нагруженную БД в мире, и второй такой не хочет.
EE>так вот, интересно, как конкретно эти оперативные данные в памяти организованы и как осуществляется к ним доступ
В виде потока сообщений дисруптора.
EE>з.ы. эх, надо было по-другому тему назвать, вопросы в основном не про дизраптор а про lmax architecture
Есть видео и куча инфы про них, я когда-то много смотрел/читал из-за того что в той же области работаю. Гугли по "lmax architecture video", среди первых 5-6 ссылок есть и часовая лекция от их главного разработчика (не Фаулера).
поток сообщений отличная штука (и она как раз персистится), но объясните мне каким образом ее можно использовать для оперативных данных? я не понимаю
ну вот пришло 1000 сообщений — ордеров на покупку, они все прошли через дизраптор, обработались бизнес-логикой, сохранились на диск
дальше пришел 1001-й ордер, на продажу, как конкретно бизнес логике понять есть ли соответствующий ордер на покупку? заново 1000 собщений прокрутить где-то? что-то я сомневаюсь что оно так работает, проще и понятнее хранить 1000 в коллекции
что и называется у фаулера "the current state of Business Logic Processor", и косвенно на это указывает этот абзац:
One was to write custom implementations of the java collections that were designed to be cache-friendly and careful with garbage[8]. An example of this is using primitive java longs as hashmap keys with a specially written array backed Map implementation (LongToObjectHashMap). In general they've found that choice of data structures often makes a big difference, Most programmers just grab whatever List they used last time rather than thinking which implementation is the right one for this context.[9]
_>Есть видео и куча инфы про них, я когда-то много смотрел/читал из-за того что в той же области работаю. Гугли по "lmax architecture video", среди первых 5-6 ссылок есть и часовая лекция от их главного разработчика (не Фаулера).
_>Ещё может быть интересен разбор секретов дисруптора от Ruslan Cheremin
видео смотрел уже, а за ссылку спасибо, интересная
Здравствуйте, evgeny.e, Вы писали:
EE>поток сообщений отличная штука (и она как раз персистится), но объясните мне каким образом ее можно использовать для оперативных данных? я не понимаю EE>ну вот пришло 1000 сообщений — ордеров на покупку, они все прошли через дизраптор, обработались бизнес-логикой, сохранились на диск EE>дальше пришел 1001-й ордер, на продажу, как конкретно бизнес логике понять есть ли соответствующий ордер на покупку? заново 1000 собщений прокрутить где-то? что-то я сомневаюсь что оно так работает, проще и понятнее хранить 1000 в коллекции
Каждый раз прокручивать не надо, надо просто хранить состояние, например, order book, а там далеко не все ордера, только те, что активны. Перед тем как обработаться и обновить order book, сообщение пишется на диск в журнал. Журнал используется в случае, если состояние надо поднять после, например, падения приложения, в этом случае надо просто проиграть все сообщения из журнала.
Здравствуйте, evgeny.e, Вы писали:
_>>В виде потока сообщений дисруптора.
EE>поток сообщений отличная штука (и она как раз персистится), но объясните мне каким образом ее можно использовать для оперативных данных? я не понимаю
EE>ну вот пришло 1000 сообщений — ордеров на покупку, они все прошли через дизраптор, обработались бизнес-логикой, сохранились на диск
EE>дальше пришел 1001-й ордер, на продажу, как конкретно бизнес логике понять есть ли соответствующий ордер на покупку? заново 1000 собщений прокрутить где-то? что-то я сомневаюсь что оно так работает, проще и понятнее хранить 1000 в коллекции
Так и будут хранить, ессно. Причем хранят раздельно по сторонам (продажа, покупка), так как сторона не меняется. Плюс один сервер обрабатывает не все на свете, а только какую-то группу инструментов (хоть один) и играть это на одном выделенном сервере. Так что практически всегда можно разбить так, что памяти хватит без проблем.
Плюс в каждый момент в памяти лежат только активные ордера. Это видно хотя бы потому, что если ты попробуешь что-то послать на исполненный или заканцелленный ордер, большинство бирж обычно отвечают не "ордер уже исполнен/убит", а просто "нет такого ордера". Т.е. с глаз долой — из сердца вон.
