Приглашаем на митап «Java и Linux – Борьба за микросекунды»



    Привет, Хабр!

    Я, Алексей Рагозин, и мой коллега – Сергей Сорокин приглашаем вас на открытое мероприятие по теме «Java и Linux – Борьба за микросекунды». Мероприятие пройдет во вторник 8 августа в 19.00 в офисе Технологического Центра Дойче Банка. Все подробности и регистрация по ссылке.

    Вот о чем мы планируем говорить.

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

    Многим знаком термин высокочастотная торговля (high frequency trading). В этом классе счет времени отклика идет на микросекунды, но и стоимость владения подобными системами очень велика. Специализированное сетевое оборудование, размещение серверов на хостинге торговой площадки, высокооптимизированный код, — все это экономически оправданно только для ограниченного числа торговых систем.

    Чаще встречаются ситуации, в которых нужен разумный баланс между стоимостью владения, скоростью разработки и временем отклика системы.

    На встрече 8 августа в Технологическом Центре Дойче Банка в Москве мы расскажем об особенностях разработки систем, которые должны обеспечивать низкое время отклика, используя обычные сервера и программную платформу Linux + Java. В частности, речь пойдет об архитектуре систем управления заявками.

    Система управления заявками — важная часть стека электронной торговли. Это компонент, в котором происходит фиксация бизнес-транзакции на основании обмена сообщениями между контрагентами: клиентом, брокером (инвестиционным банком) и рынком.

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

    В данном контексте малое время отклика — это сотни микросекунд (обычно до 1 миллисекунды)  на обработку события в прикладном процессе (не считая сетевого взаимодействия).

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

    Традиционная архитектура систем управления заявками существенно отличается от классического JEE. Ключевым моментом является исключение «медленной» базы данных с критического пути. Данные для обработки транзакций хранятся в оперативной памяти, а ACID характеристики обеспечивает надежная очередь передачи сообщений.

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

    Наконец, чтобы получить стабильное время отклика, недостаточно просто написать хороший код. Существуют факторы, неподвластные прикладному коду, — такие как конкуренция между процессами за вычислительные ресурсы, режимы энергосбережения процессора, локальность памяти и вычислительных ядер. Специальная настройка ОС Linux позволяет бороться с этими негативными факторами и существенно улучшать показатели времени отклика приложения.

    Подводя итог, на этой сессии мы расскажем об особенностях создания решений с низким временем отклика на неспециализированном железе, Java и Linux.

    До встречи!
    Поделиться публикацией
    Похожие публикации
    Комментарии 14
    • 0

      А потом приходит GC и банк влетает на деньги. Писать HFT на джаве — надо быть очень смелым. Обычно пишут на ней вспомогательные вещи AFAIK

      • 0
        Уверяю вас никакой gc в банк не приходит. За весь торговый день ни одного gc.
      • +6

        Господа! Мало того, что не указали город в заголовке, так и в тексте статьи тоже нет.

        • –1
          Вы никогда не слышали про дефолтное значение города, если он не указан? Ну и в тексте есть (возможно, добавили после вашего комментария)
          На встрече 8 августа в Технологическом Центре Дойче Банка в Москве
          • –2
            Много самомнения о дефолтном городе, я гражданин мира
            • 0
              Да, появился, но не в начале текста, а почти в середине!
              • 0
                Не для Java-митапов точно.
              • 0
                del
              • –4
                На картинке достаточно очевидна позиция дойчебанка с таким технологическим стеком

                Пруф (один из многих) https://finance.rambler.ru/news/2016-11-05/fitch-pomestilo-reyting-deutsche-bank-na/
                • 0
                  Если у вас на каждой стадии отельный поток обрабатывает все заявки не получается ли так чтотпоткаждой заявке потоку приходится лазить в память потому чио данные в кеше от предыдущей заявки не имеют ничего общего с данными которые нужны для обработки следующей? То есть получается что на каждой заявке вы лезете память вместо кеша? Разве это может быть быстро?
                  • 0
                    Как правило, после того как заявка прошла через ордер менеджер, на неё начинают приходить сделки с рынка. Так что, в приведённом примере, шанс найти заявку в кэше неплохой.
                    Но, в общем случае, оперативный объём данных к кэш не помещается и в память сходить придётся. Один поход в память это 50-100 наносекунд, что само по себе не много. Но что бы достать, допустим, заявку по ID, нужно прочитать целую цепочку объектов из памяти (контейнер транзакции, коллекцию индексов, поиск в хэше и т.п.). Кроме этого надо загрузить мэппинги виртуальный памяти для всех страниц памяти, которые мы читаем. Часть этих структур, хорошо кэшируется и, за счёт прогретых кэшей, мы экономим реальные микросекунды.
                    • 0
                      У вас единая платформа по всем рынкам мира или в разных решионах разная? Единая по всем классам бумаг или одна по кэш у другая по деривативам? у вас oms и доступ к рынку интегрирован в один пакет или это два разных приложения общающиеся по фиксу? Думаю что разные все-таки? Сколько рынков вы обслуживаете своей системой? Oms для hft вы вряд ли используете? Скорей клиент сам подключается к рынку используя только ваш id и вашу инфраструктуру а вы за ним следите постфактум по dropcopy? Или у вас в дойче есть свой проприетарный hft?
                  • 0
                    А черемин уже не занимается в дойче высокопроизводительными системами?

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое