Основні висновки

• Ledger Binance зберігає залишки на рахунках і транзакції, а також дозволяє сервісам здійснювати транзакції.

• Це створює умови, необхідні для високої пропускної здатності, цілодобової доступності та точності даних на бітовому рівні.

Роль Binance Ledger за лаштунками робить його однією з найважливіших технологій Binance. Дізнайтеся, як саме це працює, і проблеми, які він вирішує в роботі найбільшої у світі криптобіржі, тут.

Ви коли-небудь замислювалися, що саме робить Binance ефективним? З огляду на необхідність щодня обробляти мільйони транзакцій через величезну базу користувачів, варто поглянути на те, що є у Binance.

В основі технічних операцій Binance лежить її Ledger. Ledger зберігає баланси рахунків і транзакції, одночасно дозволяючи службам здійснювати транзакції.

Binance має високі вимоги до Ledger

Як ви можете собі уявити, вимоги до Ledger високі, щоб він міг задовольнити величезний попит користувачів. Є три основні моменти, які необхідно враховувати:

• Висока пропускна здатність із можливістю великої кількості TPS (транзакцій за секунду) у часи пік.

• Доступність 24/7 без простоїв.

• Точність даних на бітовому рівні, без втрати коштів або помилок транзакцій.

Давайте розглянемо приклад базового запису в Книзі. Ось звичайна транзакція, в якій рахунок 1 переказує 1 BTC на рахунок 2.

Баланс до транзакції:

таблиця-1

Баланс після транзакції:

таблиця-2

У цій транзакції є дві команди:

1. Рахунок 1    -1 BTC

2. Рахунок 2   +1 BTC

Після здійснення транзакції два журнали балансу будуть збережені для перевірки та звірки.

стіл-3

Стандартне промислове рішення

Одне стандартне галузеве рішення Ledger базується на реляційній базі даних. Повертаючись до попереднього прикладу, дві команди транзакції можна перевести в два оператори SQL і виконати в транзакції бази даних (таблиця 4).

стіл-4

Переваги рішення

1. Це досить просто реалізувати.

2. Легко застосувати загальні методи налаштування бази даних, такі як розділення читання/запису та сегментування для підвищення продуктивності.

3. Devops не складно відновлюватися після відмови, а також контролювати та підтримувати комерційну базу даних.

Недоліки рішення

1. TPS різко впаде, коли є умови гонки через блокування рядків.

2. Важко масштабувати горизонтально, щоб покращити продуктивність.

Проблема гарячого облікового запису

На жаль для Binance, галузеве рішення, продемонстроване вище, не відповідає високим вимогам. Коли відбувається транзакція, вона повинна утримувати блокування кожного рядка. Хоча деякі облікові записи мають відносно невелику кількість транзакцій, звісно, ​​є зайняті облікові записи з великою кількістю одночасних транзакцій. У цьому випадку лише одна транзакція може утримувати блокування рядка облікового запису.

Тоді інші транзакції не можуть нічого робити, крім як чекати, поки буде знято блокування. Ми називаємо цю ситуацію гарячою проблемою облікового запису, і внутрішні тести показують, що TPS у цій ситуації знизиться принаймні в 10 разів. Ви можете побачити цю проблему в таблиці 5 нижче.

Приклад гарячого аккаунта:

стіл-5

Рішення Ledger від Binance

Як вирішити проблему гарячого облікового запису?

Одним із можливих рішень нашої проблеми є інноваційне перетворення багатопоточної моделі в однопотоковий режим. Це дозволить уникнути проблеми з перегонами, і, як наслідок, не буде гарячої проблеми з обліковим записом.

Нова модель нитки

Спілкування на основі повідомлень

Після впровадження нашої нової моделі потоку потрібно вирішити проблему зв’язку. Рівень кінцевої машини є однопоточним, але мережевий рівень є багатопоточним, тож як ми зможемо ефективно спілкуватися між ними?

Disruptor [1] — наступний крок у головоломці. Він створює високопродуктивну чергу без блокування на основі конструкції кільцевого буфера.

Висока доступність

Наразі ми досягли високої продуктивності, використовуючи модель у пам’яті та локальне сховище RocksDB [2]. Але знову виникає новий виклик. Тепер потрібно подбати про високу доступність даних.

Щоб забезпечити узгодженість даних між вузлами, ми використовуємо алгоритм консенсусу Raft [3]. Це означає, що кількість резервних копій даних дорівнює кількості присутніх нелідерних вузлів. Алгоритм також гарантує, що система все ще працюватиме, якщо принаймні половина вузлів буде справною, щоб забезпечити високу доступність послуг.

Ролі домену Raft:

• Лідер. Лідер обробляє всі запити клієнтів і реплікує операцію для всіх послідовників.

• Послідовник. Послідовники йдуть за лідером у всіх операціях. Якщо лідер зазнає невдачі, новим лідером буде обраний один із послідовників.

• учень. Учні — це послідовники без права голосу, які надсилають кожен запис зміни ідемпотента/транзакції іншим службам.

Рафт доменних ролей

CQRS (Command Query Responsibility Segregation)

Іншим ключовим критерієм, який ми хочемо забезпечити, є вища продуктивність запису Ledger і можливість для більш різноманітних умов запиту. Для цього нам потрібно створити різні домени. Домен raft забезпечує більш ефективний запис на основі rocksdb+raft, а домен view прослуховує повідомлення домену raft і зберігає їх у реляційній базі даних для зовнішніх запитів. Ми також можемо реалізувати розподіл відповідальності за командний запит на рівні архітектури.

Архітектура книги

Загальна архітектура

Умови між Raft і Ledger:

стіл-6

Переглянути ролі домену

• Пліт бухгалтерський центр

Використовуйте повідомлення, створене учнем, і зберігайте дані транзакцій і балансу в MySQL для запитів.

Обробка запиту

Запит на транзакцію спочатку проходитиме через мережевий рівень, рівень реєстраційної книги (обробник запитів) і рівень raft (синхронізація журналу raft). Потім він повернеться до рівня реєстру (кінцевий автомат), мережевого рівня (обробник відповіді) і, нарешті, поверне відповідь клієнту.

Дані передаються через чергу між двома рівнями.

1. Мережевий рівень – десеріалізуйте запит rpc і помістіть його в чергу запитів.

2. Рівень книги – отримати запит із черги та підготувати контекст. Потім він помістить метадані запиту в чергу плоту.

3. Рівень плоту – отримайте метадані запиту з черги плоту та синхронізуйте їх між усіма підписниками. Потім він помістить результат у чергу застосування.

4. Ledger Layer – Отримайте дані з черги застосування та оновіть кінцевий автомат. Потім він помістить результат у чергу відповідей.

5. Мережевий рівень – отримайте результат із черги відповідей, створіть і серіалізуйте дані відповіді перед поверненням клієнту.

Обробка запиту

Відновлення даних

Кожен вузол 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 Disruptor

[2] RocksDB

[3] Алгоритм консенсусу Рафта