Каким образом разрушитель LMAX можно использовать на фондовом рынке?

Я провел некоторое исследование с отцом-разрушителем, и есть одна вещь, которую я не могу понять.

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

Я пытаюсь объяснить, как патерн разрушителя можно использовать в реальном сценарии фондового рынка.

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

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

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

У LMAX есть собственный механизм сопоставления заказов, поэтому я должен что-то упустить.

Спасибо


java stocks lmax
person user3014924    schedule 20.11.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

они утверждают, что могут выполнять до 6 миллионов заказов в секунду в этом единственном потоке.

person radai    schedule 20.11.2013
comment
Точно. Самая важная вещь в архитектуре LMAX (как они описали ее публично!) состоит в том, что есть один поток, выполняющий фактическое сопоставление порядка, который может взаимодействовать с входными и выходными потоками без блокировки. Это означает, что хотя работа выполняется одним потоком, он может выполняться с огромной скоростью. Этот подход не масштабируется с дополнительными ядрами, но это не имеет значения, потому что он достаточно быстр на одном ядре. - person Tom Anderson; 21.11.2013
comment
Спасибо за ваш ответ, Радай и Том Андерсон. Но тогда возникает вопрос: - person user3014924; 21.11.2013
comment
Спасибо за ваш ответ, Радай и Том Андерсон. Основываясь на ваших ответах, я начинаю думать, что Disruptor следует рассматривать как средство структурной обработки действий неконкурентным, но параллельным способом. Чем Disruptor не является, так это образцом для быстрого сопоставления заказов. Я прав? - person user3014924; 21.11.2013
comment
@ user3014924 правильно, это не шаблон для быстрого сопоставления заказов, а структурный. Он позволяет отделить скорость поступления заказов от их обработки — как буфер между поступающими заказами и их обработкой. По сути, это обычная очередь. Но типичные наборы очередей Java, к которым обращаются несколько потоков, в конечном итоге имеют значительные накладные расходы из-за эффектов когерентности кэша ЦП. Disruptor, наложив ограничение на одного производителя и достигнув эффективности, недоступной для стандартных коллекций. - person brettw; 21.11.2013