Быстро, много и без задержек. Java (?)

Доклад о том, как построить приложение на Java, способное обрабатывать большое количество транзакций в секунду с минимальной задержкой (latency). Авторы построили электронную торговую площадку (родственную Betfair) на основе Java и делятся опытом.

Итак, как осуществить больше 100К+ сложных бизнес-транзакций за время, меньшее 1 миллисекунды.

За транзакцию принимается следующая последовательность:

1. вставка ордера в движок
2. матчинг (с одним или несколькими контр-ордерами)
3. генерация отчетов о сделках
4. их передача в сокет

Зависимость заточки кода под производительность от требуемого количества транзакций:

• 10K+ transactions per second - если не делать глупый вещей
• 100K+ TPS - если придерживаться стандартный библиотек (в смысле не использовать транжирные третьесторонние) и иметь хороший "чистый" код
• 1M+ TPS - пишем собственный кэш для больших объектов, имеем хорошие тесты для измерения производительности, контролируем сборщик мусора (нет лишнему мусору и тюнинг GC параметров), заточенная под скорость архитектура

Архитектура высокопроизводительного приложения (типа exchange :))

Receiver принимает сообщение от клиентов (протокол общение - FIX)

Replicator дублирует поток данных на запасной сервер

Journaller сливает все тот же поток на файловую систему

UnMarshaller парсит сообщения

Business Logic собственно matching engine нашего рынка

Marshaller генерирует execution reports

Publisher отправляет репорты в сеть

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

Слева и справа от бизнес-логики - это входные и выходные буферы соответственно. Просто большие циклические байтовые массивы. Replicator и Journaller используют входной буфер в режиме "только-для-чтения", а Receiver и UnMarshaller - читают и пишут. Receiver - то что получил из сети, а UnMarshaller - то, что распарсил. Видимо, внутренний протокол LMAX гарантирует, что во внутреннем представлении сообщение поместится в тот же место, в котором размещалась закодированная копия.

Business Logic читает из буфера самое старшее сообщение, обрабатывает его и пишет результат в выходной буфер. Где его затем подхватит Marshaller и запишет уже в виде сообщения внешнего протокола. Которое будет отправлено в сеть Publisher'ом.

Такая архитектура позволила добиться порядка 90 микросекундной обработки одной транзакции при 100К+ TPS.

P.S. Рекомендации от авторов

• fastutils для коллекций в целом и хэш-таблиц в частности
• 29West как транспорт
  

P.S.S. LMAX = London Multi-Asset Exchange. То же что и Tradefair