Основные выводы
Binance’s Ledger хранит балансы счетов и транзакции, а также позволяет сервисам совершать транзакции.
Это создает условия, необходимые для высокой пропускной способности, круглосуточной доступности и точности данных на уровне битов.
Закулисная роль Binance Ledger делает ее одной из самых важных технологий Binance. Узнайте, как именно он работает и какие проблемы он решает в работе крупнейшей в мире криптовалютной биржи, здесь.
Вы когда-нибудь задумывались, что именно движет Binance? Учитывая необходимость ежедневно обрабатывать миллионы транзакций по огромной базе пользователей, стоит взглянуть на то, что у Binance под капотом.
В основе технических операций Binance лежит ее Ledger. В Ledger хранятся балансы счетов и транзакции, позволяя сервисам совершать транзакции.
У Binance высокие требования к Ledger
Как вы можете себе представить, требования к Ledger высоки, чтобы он мог удовлетворить огромный спрос пользователей. Есть три основных момента, которые необходимо учитывать:
Высокая пропускная способность с возможностью большого количества TPS (транзакций в секунду) в часы пик.
Доступность 24/7 без простоев.
Точность данных на уровне битов, без потерь средств или ошибок транзакций.
Давайте посмотрим на пример базовой записи в Ledger. Вот обычная транзакция, в которой учетная запись 1 переводит 1 BTC на учетную запись 2.
Остаток до транзакции:
Таблица 1
Баланс после транзакции:
Таблица 2
В этой транзакции есть две команды:
Счет 1 -1 BTC
Счет 2 +1 BTC
Когда транзакция будет совершена, два журнала баланса будут сохранены для аудита и сверки.
стол-3
Стандартное отраслевое решение
Одно стандартное отраслевое решение Ledger основано на реляционной базе данных. Возвращаясь к предыдущему примеру, две команды транзакции можно преобразовать в два оператора SQL и выполнить в транзакции базы данных (таблица-4).
стол-4
Преимущества решения
Это довольно просто реализовать.
Для повышения производительности легко применить распространенные методы настройки базы данных, такие как разделение чтения/записи и сегментирование.
Devops несложно восстановиться после аварийного переключения, а также отслеживать и поддерживать коммерческую базу данных.
Недостатки решения
TPS резко упадет в условиях гонки из-за блокировки рядов.
Трудно масштабировать горизонтально для повышения производительности.
Горячая проблема с аккаунтом
К несчастью для Binance, продемонстрированное выше отраслевое решение не соответствует ее высоким требованиям. Когда происходит транзакция, она должна удерживать блокировки каждой задействованной строки. Хотя на некоторых учетных записях приходится обрабатывать относительно мало транзакций, есть, конечно, загруженные учетные записи с большим количеством одновременных транзакций. В этом случае только одна транзакция способна удерживать блокировку строки учетной записи.
Остальные транзакции не могут ничего делать, кроме как ждать снятия блокировки. Мы называем эту ситуацию горячей проблемой аккаунта, и внутренние тесты показывают, что TPS в этой ситуации упадет как минимум в 10 раз. Эту проблему можно увидеть в таблице 5 ниже.
Пример горячего аккаунта:
стол-5
Решение Binance для Ledger
Как решить проблему с горячими счетами?
Одним из возможных решений нашей проблемы является инновационное преобразование многопоточной модели в однопоточный режим. Это позволит избежать проблемы состояния гонки и, как следствие, не возникнет проблем с учетной записью.
Новая модель резьбы
Общение на основе сообщений
После реализации нашей новой модели потоков необходимо решить проблему связи. Уровень конечного автомата является однопоточным, а сетевой уровень — многопоточным, так как же нам эффективно взаимодействовать между ними?
Разрушитель [1] — следующий шаг в головоломке. Он создает высокопроизводительную очередь без блокировок на основе конструкции кольцевого буфера.
Высокая доступность
До сих пор мы добились высокой производительности за счет использования модели в памяти и локального хранилища RocksDB [2]. Но снова возникает новый вызов. Теперь нам нужно позаботиться о высокой доступности данных.
Чтобы обеспечить согласованность данных между узлами, мы используем алгоритм консенсуса Raft [3]. Это означает, что количество резервных копий данных равно количеству присутствующих узлов, не являющихся ведущими. Алгоритм также гарантирует, что система по-прежнему будет работать, хотя бы половина узлов находится в работоспособном состоянии, что помогает обеспечить высокую доступность услуг.
Роли домена Raft:
Лидер. Лидер обрабатывает все запросы клиентов и повторяет операцию всем последователям.
Последователь. Последователи следуют за лидером во всех операциях. Если лидер терпит неудачу, один из последователей будет избран новым лидером.
Ученик. Учащиеся — это подписчики без права голоса, которые отправляют каждую запись изменения идемпотента/транзакции в другие службы.
Роли домена Raft
CQRS (разделение ответственности за командный запрос)
Еще одним ключевым критерием, который мы хотим обеспечить, является более высокая производительность записи в Ledger и возможность обработки более разнообразных условий запросов. Для этого нам нужно создать разные домены. Домен raft обеспечивает более эффективную запись на основе rockdb+raft, а домен просмотра прослушивает сообщения домена raft и сохраняет их в реляционную базу данных для внешних запросов. Мы также можем реализовать разделение ответственности за запросы команд на архитектурном уровне.
Архитектура реестра
Общая архитектура
Условия между Raft и Ledger:
стол-6
Просмотр ролей домена
Центр учета плотов
Потребляйте сообщение, созданное обучаемым, и сохраняйте данные о транзакциях и балансе в MySQL для целей запроса.
Обработка запроса
Запрос транзакции сначала пройдет через сетевой уровень, уровень реестра (обработчик запросов) и уровень плота (синхронизация журналов). Затем он вернется на уровень реестра (конечный автомат), сетевой уровень (обработчик ответов) и, наконец, вернет ответ клиенту.
Данные передаются через очередь между двумя уровнями.
Сетевой уровень: десериализуйте запрос RPC и поместите его в очередь запросов.
Уровень книги — получите запрос из очереди и подготовьте контекст. Затем он поместит метаданные запроса в очередь.
Уровень плота — получите метаданные запроса из очереди плота и синхронизируйте их между всеми последователями. Затем он поместит результат в очередь применения.
Уровень книги — получите данные из очереди применения и обновите конечный автомат. Затем он поместит результат в очередь ответов.
Сетевой уровень. Получите результат из очереди ответов, создайте и сериализуйте данные ответа перед возвратом их клиенту.
Обработка запроса
Восстановление данных
Каждый узел Ledger запускает общий снимок на основе периода времени. Кроме того, мы также реализуем согласованный снимок. Каждый узел запускается по одному и тому же индексу журнала плота, чтобы гарантировать, что конечный автомат будет точно таким же, когда каждый узел запускает моментальный снимок. Затем снимок будет загружен в S3 для проверки Checker и в качестве холодного резервного копирования.
Когда Ledger перезапускается, он считывает локальный снимок и перестраивает конечный автомат. Затем он воспроизводит локальный журнал группы и синхронизирует последний журнал от лидера, пока не догонит последний индекс. Если локальный снимок или журнал плота не существует, он будет получен от лидера.
Снимок и восстановление
Терпимость к стихийным бедствиям
Для повышения доступности и отказоустойчивости узлы Ledger развертываются в разных зонах. Пока более половины узлов исправны, данные не будут потеряны, а отработка отказа будет завершена за одну секунду.
Даже если весь кластер выйдет из строя, вероятность чего очень мала, мы все равно сможем восстановить кластер с помощью согласованного моментального снимка, хранящегося в Amazon S3, и получить последние потерянные данные через нижестоящую систему.
Отказоустойчивость
Производительность
В следующей таблице показаны характеристики оборудования для теста производительности.
Внутренние тесты доказывают, что кластер из 4 узлов (один лидер, два последователя и один ученик) может обрабатывать более 10 000 TPS. По замыслу кластер обрабатывает все транзакции одну за другой. Здесь вообще нет состояния блокировки и гонки. Таким образом, в сценарии горячего счета TPS такой же высокий, как и в обычных сценариях.
Горячий аккаунт TPS
На следующем рисунке показана задержка каждой транзакции. Большинство транзакций могут быть завершены в течение 10 мс. Более медленные транзакции могут быть завершены в течение 25 мс.
Задержка мс
Расширение наших услуг с помощью Binance Ledger
Как вы видели, традиционный ответ отрасли на проблему с горячими счетами не удовлетворяет потребности Binance и ее клиентов. Используя подход, разработанный специально для инфраструктуры Binance, мы получили один из самых удобных вариантов обмена и продуктов. Мы рады поделиться с вами нашим опытом и надеемся, что вы лучше поймете, что нужно для работы такого сервиса, как Binance.
Прочтите следующую статью для получения дополнительной информации о нашей технологической инфраструктуре:
(Блог Binance) Использование MLOps для создания сквозного конвейера машинного обучения в реальном времени
(Блог Binance) Знакомьтесь, технический директор: Рохит размышляет о криптовалюте, блокчейне, Web3 и своем первом месяце в Binance
Рекомендации
[1] Разрушитель LMAX
[2] РоксДБ
[3] Алгоритм консенсуса Raft
