Да, по п. 4 у вас верные аргументы, но работа платформы устроена немного сложнее. Возможность использования УКЭП в 211-ФЗ доступна, но есть еще и 115-ФЗ. И именно 115-ФЗ регулирует идентификацию, с УКЭП она не связана. Так вот, 115-ФЗ сейчас позволяет стать клиентом платформы, только если пройти идентификацию с личным присутствием. Мы ждём, пока в него внесут изменения, чтобы запустить биометрию.
А пока мы предлагаем нашим пользователям пригласить представителя платформы для идентификации — это нужно сделать всего один раз. Он приедет в то время и место, которое назначит пользователь. Понимаем, это не всегда удобно, но пока только так.
И ещё: наши представители не проверяют паспорта на подлинность, они лишь передают их копии нам на проверку.
Не игнорируем, просто верхнеуровневые ответы уже есть в тексте. Если нужны подробности — пожалуйста.
1. Действительно, есть банки, которым регулятор уже разрешил использовать биометрию.
2. Есть и ЭЦП (точнее, УКЭП), есть финансовые организации, которые имеют право ее использовать. Но!
3. Деятельность финансовых платформ регулируется отдельным законом – Федеральный закон от 20.07.2020 N 211-ФЗ «О совершении финансовых сделок с использованием финансовой платформы».
4. П.6 ст. 4 (Правила финансовой платформы) обязывает оператора (то есть, нас) заключить с пользователем договор. Для этого мы должны получить от него либо личную подпись, либо ПЭП, ключ от которой мы должны передать при личной явке.
5. Сейчас готовится вторая версия закона, в которой речь идет и о биометрии, и о других способах подписания договора. Как только будет принято законодательство, на Финуслугах появятся все возможные способы регистрации. Сам механизм биометрии у нас уже реализован и ждет своего часа.
В этом вопросе мы полностью зависим от законодательства. Разрешат биометрию — сделаем биометрию, тем более что она была в первоначальном плане (писали об этом в материале).
8 млн – это внутренняя производительность алгоритма на ядре системы. А 50 тыс. – это поток, образуемый клиентской нагрузкой в реальной инфраструктуре – с полным набором компонентов/серверов, резервированием, репликацией, сетевыми устройствами.
Вообще говоря, наша in-memory DB достаточно сильно отличается от популярных на текущий момент, таких, как Aerospike, Tarantool и т.п., и по современным понятиям назвать её DB можно с натяжкой. Основная задача была в минимизации оверхеда. Полностью написана на С, описание таблиц — это C-структуры. По этим описаниям генерируются сериализаторы/десериализаторы, чтобы можно было сбрасывать структуры на диск или в сеть. Вся работа идет непосредственно со структурами в памяти. Репликация данных идет отдельно, и вообще ее может не быть. Для отображений и связей используются интрузивные списки (элементы prev/next лежат в самой записи), а голова — в другой таблице. Их тоже нужно объявлять в заголовке структуры. Также есть интрузивные деревья поиска для более сложных структур. Принцип работы с инрузивными типами очень похож на работу в ядре ОС Linux (https://notes.shichao.io/lkd/ch6/). Есть много вспомогательных функций, макросов, автогенераторов, но всё равно это больше программирование на С, чем работа с NoSQL-базой. Сделано это было, так как корни растут еще с начала 90-х, да и на PA-RISC родной компилятор С++ оставлял желать лучшего, а g++ под PA-RISC генерировал код раза в 3-4 медленнее, чем родной, поэтому до 2011 был только С. Сейчас, конечно, boost::intrusive более предпочтительный способ :)
Непосредственно перед стартом определятся максимальный размер каждой таблицы — и именно такой размер выделяется в оперативной памяти (с mlock). Это сделано для обеспечения не только минимальной задержки, но и стабильного джиттера, т.к. если в процессе работы будет увеличение размера, это приведет к небольшим паузам. Из-за особенности торгов мы каждый день перезапускаем систему и, соответственно, корректируем эти значения. Также в ходе старта происходит загрузка всех справочных данных на текущей день из SQL-базы. Можно выделить 4 класса таблиц: вспомогательные (хеши, индексы), статические данные (загружаются в отсортированном виде при старте из SQL-базы и более не меняются), динамические и динамические с реюзингом. Последний тип достаточно интересный, ~70-80 % RAM занимает таблица заявок, количество таких заявок может быть под 100 млн за день, и каждая строчка — это около ~450 байт. Хотя серверы с 1Тб+ RAM вполне доступны сейчас, но лет 6 назад этот объем был существенен, да и серверов с учетом всех гейтвеев более 100. Но самое главное — хранить их всех нет необходимости. Большая часть заявок в ходе торгового дня становится неактивна и нужна только для истории, сразу скажу, эта задача решается online-импортом в SQL-базу. Поэтому в ходе работы с этой таблицей ведется список LRU (least recently used), и когда все доступные записи таблицы использованы, начинается алгоритм реюзинга (отвязывание записей из LRU, входящих в отображения, и перевод в новый список доступных после реюзинга). Эта операция идет блочно по ~32 записи, т.е. мы освободили место под текущую транзакцию и сделали задел на будущее. Если меньше, то операции синхронизации (чтобы безопасно отвязать) на каждой транзакции будут давать замедление (производительность падает на 20 % в этом случае, по сравнению, когда реюзинга еще нет). Если делать больше то на транзакции, в которой происходит операция, будет всплеск задержки в обработки. Поэтому было найдено оптимальное значение (падение производительности ~1 %).
Все запросы пишутся тоже с нуля. Вообще говоря, в запросах сразу заложен нативный протокол Mustang и все запросы сразу формируют Mustang-пакеты без какого-либо внутреннего промежуточного представления. Собственно, по этой причине и нет сейчас «бинарного» протокола на фондовом и валютном рынке.
Данная база модифицируется всё время, пока функционирует Биржа, начиная с австралийской версии ASTS.
База на текущий момент не распределенная и все серверы имеют ее реплики на, в теории, неограниченное число серверов. Об этом расскажем в следующей части
Если говорить про терминалы к ASTS, то секрет из этого сделать сложно – достаточно посмотреть на набор файлов в дистрибутиве, чтобы увидеть, что он написан на… Delphi. С одной стороны, он прекрасно справляется с большими объёмами данных, но с другой, мы все понимаем, что Delphi уже несколько вышел из моды… Но конкретно эти терминалы заточены под весьма специфичный круг задач и достаточно узкую целевую аудиторию, которая, согласно опросам, всё ещё отдаёт предпочтение толстым клиентам. Для приложений аналогичного класса и с аналогичными пользовательскими требованиями потихоньку мигрируем на .net и C#. Из библиотек, и там, и там, активно используем то, что делает DevExpress.
Кстати, небольшой совет – при выборе библиотек для корпоративных решений не забыть исследовать их совместимость с системами автотестирования. У нас, например, было долгое хождение по граблям, пока не научили их распознавать некоторые 3rd-party гуёвые контролы.
В других решениях биржи, нацеленных на более широкую аудиторию, сейчас применяем хорошо всем известный стек ныне популярных технологий – Vue.js, Kubernetes, Kafka, Camunda,…
Данные для такой статистики мы не собираем. Но у нас работают примерно на тех же скоростях, что и у при работе с немцами… согласно полученной в кулуарах неофициальной информации :)
Есть стандартные протоколы – FIX для подачи заявок и FAST для маркет-даты. На срочном рынке для быстрой торговли есть также бинарный TWIME (про него на Хабре была отдельная подробная статья).
Также на всех рынках есть совсем свои: CGate на срочном рынке и ASTS Bridge на фондовом, валютном, денежном. Необходимость своего протокола вызвана, в частности, тем, что на рынках есть много специфичной для Московской Биржи функциональности, которой нет на других биржах и которая не предусмотрена стандартами. Например, клиринговые и позиционные данные и транзакции, переговорные режимы торгов, различные виды аукционов.
Переход на бинарный протокол обусловлен тем, что особенности его реализации позволяют сделать данный протокол максимально близким по структуре к внутреннему протоколу ТС Спектра ( в отличие от протокола FIX) и тем самым обеспечить максимальное быстродействие протокола внутри с отсутствием библиотек на стороне клиента. При этом работы по усовершенствованию связки FIX/FAST все равно ведутся.
Формально это всё-таки протокол, имеющий спецификации и версионность. Но протокол этот определяет не формат контента, а скорее транспортный уровень. Протокол сам по себе довольно широкий, потому многие биржи его заимствуют не полностью или берут только что-то прикладное. К тому же у каждой биржи своя специфика инструментов и торгов, поэтому вполне логично, что у каждой есть свои нюансы, несовместимые с другими. И опять же, наличие особенностей реализации и специфики есть и в других международных стандартах (ISO).
Наличие бинарного протокола именно в этом плане задачу не облегчит. Текст может и считаться архаикой, но например ITCH – это тоже вещь достаточно специфическая. А что рекомендуете вы?
Поддержка FIX’a, как показывает наша практика, позволяет частным клиентам максимально быстро разработать софт с нуля и выйти на рынок – за счёт его простоты, наличия библиотек и независимых ресурсов, где можно почитать туториалы или получить помощь сообщества. А у большинства крупных зарубежных банков/брокеров FIX считается стандартом де-факто и имеется солидный опыт в его использовании — если имеешь цель сделать фиксовый продукт с подключением ко многим биржам, наличие протокола делает задачу проще — вместо того, чтобы изучать совершенно разные протоколы каждой отдельной биржи, проще адаптировать свое FIX-решение к реалиям конкретной биржи.
Фикс гейт медленнее CGate на время конвертации фикс сообщения в формат Plaza-2, который является внутренним форматом торговой системы, это время составляет сейчас в районе 50-70 мкс на транзакцию. В то же время обработка сообщения в роутере на стороне клиента занимает, в общем случае, 10-30 мкс. В связи с этим улучшить время RTT заявки через фикс – можно, и мы над этим работаем, но обогнать CGate пока не представляется возможным.
Тут подразумевается, что принимающий интерфейс (коммутаторы в зоне колокации, в которые подключается сервер/сетевое оборудование участника) в сторону торговой системы и управляющий интерфейс (который смотрит в интернет и через который можно управлять сервером) это суть разные вещи. Формально комментирующий прав – на сервере в общем случае две сетевых карты, которые собраны в teaming и через которые идет весь трафик
В силу архитектурного устройства системы FIX на срочном рынке вряд ли когда-нибудь будет быстрее CGate, но мы надеемся, что в ближайший год его latency будет планомерно улучшаться.
Бинарный протокол, но об этом мы будем рассказывать подробнее позже, после выдачи данного протокола в публичный тест.
Добрый день! Именно поэтому публикация называется «обзором рынка», а не иначе. Спасибо за идею — постараемся подготовить материал о внутренней истории.
1. Под провайдером подразумевается вендор, т.е. основной поставщик услуг.
2. Информация была собрана из открытых источников, среди которых IDC, CNews Analytics, Tadviser и др.
3. Анализ рынка был произведен самостоятельно, на основании информации, собранной в открытых источниках и опросов компаний-пользователей данных услуг.
4. По поводу методологии — это достаточно обширная тема, дайте ваш контактный email — постараемся подробно описать.
А пока мы предлагаем нашим пользователям пригласить представителя платформы для идентификации — это нужно сделать всего один раз. Он приедет в то время и место, которое назначит пользователь. Понимаем, это не всегда удобно, но пока только так.
И ещё: наши представители не проверяют паспорта на подлинность, они лишь передают их копии нам на проверку.
Спасибо за дискуссию и интерес к Финуслугам!
1. Действительно, есть банки, которым регулятор уже разрешил использовать биометрию.
2. Есть и ЭЦП (точнее, УКЭП), есть финансовые организации, которые имеют право ее использовать. Но!
3. Деятельность финансовых платформ регулируется отдельным законом – Федеральный закон от 20.07.2020 N 211-ФЗ «О совершении финансовых сделок с использованием финансовой платформы».
4. П.6 ст. 4 (Правила финансовой платформы) обязывает оператора (то есть, нас) заключить с пользователем договор. Для этого мы должны получить от него либо личную подпись, либо ПЭП, ключ от которой мы должны передать при личной явке.
5. Сейчас готовится вторая версия закона, в которой речь идет и о биометрии, и о других способах подписания договора. Как только будет принято законодательство, на Финуслугах появятся все возможные способы регистрации. Сам механизм биометрии у нас уже реализован и ждет своего часа.
Непосредственно перед стартом определятся максимальный размер каждой таблицы — и именно такой размер выделяется в оперативной памяти (с mlock). Это сделано для обеспечения не только минимальной задержки, но и стабильного джиттера, т.к. если в процессе работы будет увеличение размера, это приведет к небольшим паузам. Из-за особенности торгов мы каждый день перезапускаем систему и, соответственно, корректируем эти значения. Также в ходе старта происходит загрузка всех справочных данных на текущей день из SQL-базы. Можно выделить 4 класса таблиц: вспомогательные (хеши, индексы), статические данные (загружаются в отсортированном виде при старте из SQL-базы и более не меняются), динамические и динамические с реюзингом. Последний тип достаточно интересный, ~70-80 % RAM занимает таблица заявок, количество таких заявок может быть под 100 млн за день, и каждая строчка — это около ~450 байт. Хотя серверы с 1Тб+ RAM вполне доступны сейчас, но лет 6 назад этот объем был существенен, да и серверов с учетом всех гейтвеев более 100. Но самое главное — хранить их всех нет необходимости. Большая часть заявок в ходе торгового дня становится неактивна и нужна только для истории, сразу скажу, эта задача решается online-импортом в SQL-базу. Поэтому в ходе работы с этой таблицей ведется список LRU (least recently used), и когда все доступные записи таблицы использованы, начинается алгоритм реюзинга (отвязывание записей из LRU, входящих в отображения, и перевод в новый список доступных после реюзинга). Эта операция идет блочно по ~32 записи, т.е. мы освободили место под текущую транзакцию и сделали задел на будущее. Если меньше, то операции синхронизации (чтобы безопасно отвязать) на каждой транзакции будут давать замедление (производительность падает на 20 % в этом случае, по сравнению, когда реюзинга еще нет). Если делать больше то на транзакции, в которой происходит операция, будет всплеск задержки в обработки. Поэтому было найдено оптимальное значение (падение производительности ~1 %).
Все запросы пишутся тоже с нуля. Вообще говоря, в запросах сразу заложен нативный протокол Mustang и все запросы сразу формируют Mustang-пакеты без какого-либо внутреннего промежуточного представления. Собственно, по этой причине и нет сейчас «бинарного» протокола на фондовом и валютном рынке.
Данная база модифицируется всё время, пока функционирует Биржа, начиная с австралийской версии ASTS.
База на текущий момент не распределенная и все серверы имеют ее реплики на, в теории, неограниченное число серверов. Об этом расскажем в следующей части
Кстати, небольшой совет – при выборе библиотек для корпоративных решений не забыть исследовать их совместимость с системами автотестирования. У нас, например, было долгое хождение по граблям, пока не научили их распознавать некоторые 3rd-party гуёвые контролы.
В других решениях биржи, нацеленных на более широкую аудиторию, сейчас применяем хорошо всем известный стек ныне популярных технологий – Vue.js, Kubernetes, Kafka, Camunda,…
Есть стандартные протоколы – FIX для подачи заявок и FAST для маркет-даты. На срочном рынке для быстрой торговли есть также бинарный TWIME (про него на Хабре была отдельная подробная статья).
Также на всех рынках есть совсем свои: CGate на срочном рынке и ASTS Bridge на фондовом, валютном, денежном. Необходимость своего протокола вызвана, в частности, тем, что на рынках есть много специфичной для Московской Биржи функциональности, которой нет на других биржах и которая не предусмотрена стандартами. Например, клиринговые и позиционные данные и транзакции, переговорные режимы торгов, различные виды аукционов.
Наличие бинарного протокола именно в этом плане задачу не облегчит. Текст может и считаться архаикой, но например ITCH – это тоже вещь достаточно специфическая. А что рекомендуете вы?
Поддержка FIX’a, как показывает наша практика, позволяет частным клиентам максимально быстро разработать софт с нуля и выйти на рынок – за счёт его простоты, наличия библиотек и независимых ресурсов, где можно почитать туториалы или получить помощь сообщества. А у большинства крупных зарубежных банков/брокеров FIX считается стандартом де-факто и имеется солидный опыт в его использовании — если имеешь цель сделать фиксовый продукт с подключением ко многим биржам, наличие протокола делает задачу проще — вместо того, чтобы изучать совершенно разные протоколы каждой отдельной биржи, проще адаптировать свое FIX-решение к реалиям конкретной биржи.
2. Информация была собрана из открытых источников, среди которых IDC, CNews Analytics, Tadviser и др.
3. Анализ рынка был произведен самостоятельно, на основании информации, собранной в открытых источниках и опросов компаний-пользователей данных услуг.
4. По поводу методологии — это достаточно обширная тема, дайте ваш контактный email — постараемся подробно описать.