Основные выводы
Наша миграция на Binance Ledger была направлена на решение проблемы «горячих» учетных записей, присущей нашему бывшему серверу реляционной базы данных.
Криптовалютная биржа работает 24 часа в сутки, 7 дней в неделю, 365 дней в году, без периода технического обслуживания, в отличие от обычной биржи, у которой есть ежедневные перерывы.
Переход на новый Binance Ledger должен был происходить онлайн, сохранять активы пользователей в безопасности и не оказывать никакого влияния на бизнес, чтобы конечные пользователи могли работать без проблем.
Мы выбрали постепенную стратегию миграции для каждой учетной записи вместо стратегии одновременного переключения, используемой инструментом gh-ost.
Узнайте больше о нашей миграции на Binance Ledger, а также об инструментах и методах, используемых на протяжении всего процесса.
Binance Ledger поддерживает наши технические операции и обрабатывает миллионы ежедневных транзакций через обширную базу пользователей. Вы можете узнать больше о системе, ее целях и проблемах в нашем блоге «Как Binance Ledger улучшает ваш опыт работы с Binance». В процессе перехода со старой версии на новую мы столкнулись с типичной проблемой: как мы можем модернизировать двигатель на лету, пока самолет еще в полете? Нам пришлось перенести активы наших пользователей, и сохранение средств SAFU было нашим главным приоритетом.
Ключевые проблемы миграции Binance
Для достижения поставленных целей необходимо было решить следующий список проблем:
Обеспечить полную корректность нового реестра
Уметь обнаружить любую проблему с фондом и своевременно и точно устранить ее.
Отсутствие простоев в восходящих потоках
Сравнение нашей миссии по миграции с онлайн-базой данных DDL
Прежде чем мы углубимся в детали нашего решения, давайте рассмотрим распространенную проблему выполнения онлайн-DDL (языка определения данных) для большой таблицы. Что такое DDL? Хорошо, представьте себе таблицу с сотнями миллионов строк, в которую нам нужно добавить еще один столбец. Мы хотим сделать это онлайн, не нарушая работу бизнеса.
Для решения этой проблемы широко используется инструмент gh-ost, и вы можете увидеть, как он работает, на следующей диаграмме.
По сути, процесс состоит из двух этапов:
Фаза синхронизации, которая продолжается до тех пор, пока новая таблица не станет полностью идентична исходной таблице. Существует два типа данных, которые необходимо синхронизировать:
Существующие данные
Инкрементальные данные (новые данные, созданные из исходной таблицы в ходе продолжающегося процесса миграции)
Фаза переключения: замена исходной таблицы на новую без прерывания текущих транзакций.
Чем отличались проблемы Binance Ledger
Несмотря на некоторые сходства, у Binance Ledger были некоторые уникальные проблемы в нашей миссии онлайн-миграции.
Во-первых, серверные системы Binance работают в распределенной среде, тогда как DDL онлайн-базы данных находится в монолитной среде. Во-вторых, мы не можем позволить себе использовать подход «все сразу», поскольку данные были активами наших пользователей. Наконец, нам необходимо убедиться, что все соответствующие службы работают как единое целое, прежде чем приступить к массовой миграции.
Как и в предыдущем примере онлайн-DDL, наша миграция также состояла из двух этапов:
Фаза синхронизации, на которой была специально создана специальная служба репликатора для синхронизации балансов из старого реестра в новый.
Этап переключения между аккаунтами
Поэтапные подходы
Задача была большая, и, как говорится, Рим не за один день строился. Подход «разделяй и властвуй» часто работает как чудо перед лицом большой и сложной проблемной области.
Этап 1: Репликация
Почему
Мы можем суммировать наш мыслительный процесс в двух основных пунктах:
Мы смоделировали Binance Ledger как новое подчиненное устройство, присоединяющееся к существующему кластеру MySQL, который поддерживает текущую систему реестра. Используя методы репликации, мы могли полностью асинхронно синхронизировать балансы пользователей.
Затем мы могли бы дословно направить производственный трафик в Binance Ledger, чтобы проверить его правильность и надежность. Даже если на этом этапе дела пойдут плохо, это не повлияет на нас и наших пользователей.
Что
Ниже мы проиллюстрировали общий конвейер репликации. Критический путь, на который следует обратить внимание:
Перевод → Ledger → Репликатор Binance Ledger → Binance Ledger
Как
Мы разбили процесс репликации на два отдельных этапа:
Сбросил снимок базы данных реестра, а затем импортировал его в Binance Ledger.
Реплицирован журнал корзины базы данных бухгалтерской книги после того, как был сделан дамп моментального снимка.
В конечном итоге данные балансов и журналов балансов будут полностью синхронизированы между старым реестром и Binance Ledger, что в дальнейшем можно будет проверить с помощью модуля полной сверки.
Когда
Binance Ledger был запущен в начале августа 2022 года. После этого мы запустили процесс репликации, который длился до середины ноября 2022 года. Этот процесс был для нас важным периодом, поскольку корректность новой системы реестра должна была быть проверена на 100%. Этот шаг нельзя пропустить, прежде чем переходить к следующему этапу миграции.
В конечном итоге мы не обнаружили никаких проблем и выполнили несколько процедур выпуска, чтобы чувствовать себя более комфортно в ситуации. Трехмесячный процесс не был особенно быстрым, но он был необходим для достижения нашей цели SAFU.
Этап 2: онлайн-миграция
Почему
Чтобы выполнить миграцию сотен миллионов учетных записей, мы разработали индивидуальное задание по миграции.
Что
Ниже мы изобразили основной поток миграции для одной учетной записи:
Вот несколько ключевых замечаний, которые следует иметь в виду:
Система учетных записей поддерживает сопоставление прав собственности для каждой учетной записи.
Счет А → бухгалтерская книга
Счет Б → Binance Ledger
Аккаунт C → запрещен
Перед переносом учетной записи, если существовала какая-либо ожидающая параллельная транзакция, она будет пропущена, чтобы уменьшить влияние на бизнес.
Мы изменили сопоставление прав собственности с реестра на запрещенное, запретив любые дальнейшие обновления баланса и сделав его неизменяемым.
Мы сверили балансы между старым реестром и Binance Ledger.
Мы изменили сопоставление прав собственности с запрещенного на Binance Ledger, что позволяет направлять будущие обновления баланса непосредственно в Binance Ledger.
Согласно нашему показателю производительности, переход от шага 3 к шагу 5 занял в среднем 150 мс. Теоретически пользователи не могут проводить какие-либо транзакции в течение этого периода миграции в 150 мс. Оказалось, что затронутых транзакций не было.
Выполнение
В Binance мы отстаиваем принцип «хорошее исполнение важнее тщательного планирования». Надежное исполнение жизненно важно для нашего успеха, а безопасность средств всегда является нашим главным приоритетом. Мы приняли стратегию постепенной миграции в течение трех недель, чтобы выявить проблемы как можно раньше, что, в свою очередь, помогло уменьшить масштаб негативного воздействия.
Процесс примирения
Согласование чрезвычайно важно для своевременного выявления потенциальных аномалий баланса с объективной точки зрения. Мы можем проводить этот процесс практически в режиме реального времени, чтобы принять оперативные меры, прежде чем ситуация ухудшится. Специально для процесса онлайн-миграции разработаны два типа модулей сверки: в режиме реального времени и полный.
В режиме реального времени
Процесс сверки на уровне транзакций создан для обнаружения любых проблем с фондами в режиме реального времени.
Полный
Мы можем периодически выполнять полную сверку на основе снимков, синхронизированных с хранилищем данных. Этот процесс гарантирует, что все балансы в старом реестре и Binance Ledger одинаковы.
Например, предположим, что у нас есть 10 миллионов пользователей, которые все еще находятся в старом реестре. Мы можем использовать эту полную сверку, чтобы убедиться, что балансы и журналы балансов одинаковы в старом реестре и Binance Ledger.
Завершение процесса миграции
В двух словах, миссия была выполнена путем 1) использования методов репликации для проверки правильности нового Binance Ledger 2) реализации стратегии миграции каждого аккаунта для медленного, безопасного, но уверенного обновления движка.
Мы считаем, что вышеупомянутую парадигму онлайн-миграции можно повторно использовать в аналогичных задачах. Если обсуждаемые процессы и темы заинтересовали вас, почему бы не подумать о присоединении к команде? Мы всегда ищем преданных своему делу людей со свежим взглядом на наши повседневные задачи в Binance.
Рекомендации
Как Binance Ledger улучшает ваш опыт работы с Binance
Онлайн-инструмент GitHub для миграции схем для MySQL
Дальнейшее чтение
Использование MLOps для создания сквозного конвейера машинного обучения в реальном времени | Бинанс Блог
Подходит ли вам Binance? Причины не присоединяться к Binance | Бинанс Блог