Bagaimana Binance Ledger Mendukung Pengalaman Binance Anda

Kesimpulan Utama

• Buku Besar Binance menyimpan saldo akun dan transaksi, sekaligus memungkinkan layanan untuk melakukan transaksi.

• Ini menciptakan kondisi yang diperlukan untuk throughput tinggi, ketersediaan 24/7, dan akurasi data tingkat bit.

Peran Binance Ledger di balik layar menjadikannya salah satu teknologi terpenting Binance. Pelajari dengan tepat cara kerjanya dan masalah yang dipecahkannya dalam pengoperasian pertukaran kripto terbesar di dunia di sini.

Pernah bertanya-tanya apa sebenarnya yang membuat Binance tergerak? Dengan kebutuhan untuk memproses jutaan transaksi setiap hari di basis pengguna yang sangat besar, ada baiknya kita melihat apa yang dimiliki Binance.

Yang mendasari operasi teknis Binance adalah Buku Besarnya. Buku Besar menyimpan saldo dan transaksi akun sekaligus memungkinkan layanan untuk melakukan transaksi.

Binance Memiliki Persyaratan Tinggi untuk Buku Besar

Seperti yang dapat Anda bayangkan, persyaratan untuk Ledger tinggi agar dapat memenuhi permintaan pengguna yang sangat besar. Ada tiga hal utama yang perlu diperhatikan:

• Throughput tinggi dengan kemampuan TPS (transaksi per detik) dalam jumlah besar pada waktu puncak.

• Ketersediaan 24/7 tanpa downtime.

• Akurasi data tingkat bit, tanpa kehilangan dana atau kesalahan transaksi.

Mari kita lihat contoh entri dasar di Buku Besar. Berikut adalah transaksi umum di mana akun 1 mentransfer 1 BTC ke akun 2.

Saldo sebelum transaksi:

Tabel 1

Saldo setelah transaksi:

Meja 2

Dalam transaksi ini, ada dua perintah:

1. Akun 1    -1 BTC

2. Akun 2   +1 BTC

Ketika transaksi dilakukan, dua log saldo akan disimpan untuk audit dan rekonsiliasi.

tabel-3

Solusi Industri Standar

Salah satu solusi Buku Besar industri standar didasarkan pada database relasional. Kembali ke contoh sebelumnya, dua perintah transaksi dapat diterjemahkan menjadi dua pernyataan SQL dan dieksekusi dalam transaksi database (tabel-4).

tabel-4

Keuntungan dari solusi tersebut

1. Penerapannya cukup sederhana.

2. Sangat mudah untuk menerapkan teknik penyetelan database umum seperti pemisahan baca/tulis dan sharding untuk meningkatkan kinerja.

3. Tidak sulit bagi pengembang untuk pulih dari kegagalan, serta memantau dan memelihara database komersial.

Kerugian dari solusi tersebut

1. TPS akan turun tajam ketika ada kondisi balapan akibat row lock.

2. Sulit untuk melakukan penskalaan secara horizontal untuk meningkatkan kinerja.

Masalah Akun Panas

Sayangnya bagi Binance, solusi industri yang ditunjukkan di atas tidak memenuhi persyaratan yang tinggi. Ketika suatu transaksi terjadi, ia harus memegang kunci baris dari setiap baris yang terlibat. Meskipun beberapa akun memiliki transaksi yang relatif sedikit untuk ditangani, tentu saja ada akun sibuk dengan banyak transaksi bersamaan. Dalam hal ini, hanya satu transaksi yang mampu menahan kunci baris akun. 

Transaksi lainnya kemudian tidak dapat melakukan apa pun selain menunggu hingga kunci dibuka. Kami menyebut situasi ini sebagai masalah akun panas, dan pengujian internal menunjukkan TPS akan turun setidaknya 10 kali lipat dalam situasi ini. Masalah ini dapat Anda lihat pada tabel 5 di bawah ini.

Contoh akun populer:

tabel-5

Solusi Buku Besar Binance 

Bagaimana cara mengatasi masalah akun panas?

Salah satu solusi yang mungkin untuk masalah kami adalah dengan secara inovatif mengubah model multi-thread ke mode single-threaded. Hal ini kemudian menghindari masalah kondisi balapan, dan alhasil tidak akan terjadi masalah akun yang panas.

Model benang baru

Komunikasi berbasis pesan

Setelah menerapkan model thread baru kami, masalah komunikasi perlu diselesaikan. Lapisan mesin negara adalah single-thread, namun lapisan jaringan adalah multi-threaded, jadi bagaimana kita berkomunikasi secara efisien di antara keduanya?

Pengganggu [1] adalah langkah selanjutnya dalam teka-teki ini. Ini menciptakan antrian berkinerja tinggi dan bebas kunci berdasarkan desain buffer cincin.

Ketersediaan tinggi

Sejauh ini, kami telah mencapai kinerja tinggi dengan menggunakan model dalam memori dan penyimpanan lokal RocksDB [2]. Namun, sekali lagi, tantangan baru muncul. Sekarang kita perlu menjaga ketersediaan data yang tinggi.

Untuk memastikan konsistensi data antar node, kami menggunakan Algoritma Konsensus Rakit [3]. Ini berarti jumlah cadangan data sama dengan jumlah node non-pemimpin yang ada. Algoritme ini juga memastikan sistem akan tetap bekerja dengan setidaknya setengah dari node dalam kondisi sehat, untuk membantu menyediakan ketersediaan layanan yang tinggi.

Peran Domain Rakit:

• Pemimpin. Pemimpin memproses semua permintaan klien dan mereplikasi operasi tersebut ke semua pengikut.

• Pengikut. Pengikut mengikuti pemimpin untuk semua operasi. Jika pemimpin gagal, salah satu pengikut akan terpilih sebagai pemimpin baru. 

• Pelajar. Pelajar adalah pengikut non-voting yang mengirimkan setiap catatan perubahan idempoten/transaksi ke layanan lain.

Peran domain rakit

CQRS (Pemisahan Tanggung Jawab Permintaan Perintah)

Kriteria utama lainnya yang ingin kami pastikan adalah kinerja penulisan Ledger yang lebih tinggi dan kemampuan untuk kondisi kueri yang lebih beragam. Untuk ini, kita perlu membuat domain yang berbeda. Domain raft menyediakan penulisan yang lebih efisien berdasarkan rocksdb+raft, dan domain tampilan mendengarkan pesan dari domain raft dan menyimpannya ke database relasional untuk kueri eksternal. Kami juga dapat menerapkan pemisahan tanggung jawab kueri perintah di tingkat arsitektur.

Arsitektur buku besar

Arsitektur keseluruhan

Ketentuan antara Raft dan Ledger:

tabel-6

Lihat Peran Domain

• Pusat buku besar rakit

Konsumsi pesan yang dihasilkan oleh pelajar dan simpan data transaksi dan saldo di MySQL untuk tujuan kueri.

Pemrosesan permintaan

Permintaan transaksi pertama-tama akan melewati lapisan jaringan, lapisan buku besar (penanganan permintaan), dan lapisan rakit (sinkronisasi log rakit). Kemudian akan kembali ke lapisan buku besar (mesin negara), lapisan jaringan (penanganan respons), dan akhirnya mengembalikan respons ke klien.

Data dilewatkan melalui antrian antara dua lapisan. 

1. Lapisan Jaringan – Deserialisasi permintaan rpc dan masukkan ke dalam antrian permintaan.

2. Lapisan Buku Besar – Dapatkan permintaan dari antrian dan siapkan konteksnya. Ini kemudian akan memasukkan metadata permintaan ke dalam antrian rakit. 

3. Lapisan Rakit – Dapatkan metadata permintaan dari antrian rakit dan sinkronkan di antara semua pengikut. Ini kemudian akan memasukkan hasilnya ke dalam antrian penerapan.

4. Lapisan Buku Besar – Dapatkan data dari antrian penerapan dan perbarui mesin status. Ini kemudian akan memasukkan hasilnya ke dalam antrian respons.

5. Lapisan Jaringan – Dapatkan hasil dari antrian respons dan buat serta buat serial data respons sebelum mengembalikannya ke klien.

Pemrosesan permintaan

Pemulihan data

Setiap node Ledger akan memicu snapshot umum berdasarkan periode waktu. Selain itu, kami juga menerapkan snapshot yang konsisten. Setiap node dipicu pada indeks log rakit yang sama untuk memastikan bahwa mesin status sama persis ketika setiap node memicu snapshot. Snapshot kemudian akan diunggah ke S3 untuk verifikasi oleh Checker dan sebagai cadangan dingin.

Saat Ledger dimulai ulang, ia membaca snapshot lokal dan membangun kembali mesin status. Kemudian ia memutar ulang log rakit lokal dan menyinkronkan log terbaru dari pemimpin hingga mencapai indeks terbaru. Jika snapshot lokal atau log rakit tidak ada, maka akan diperoleh dari pemimpin.

Cuplikan & Pemulihan

Toleransi bencana

Untuk meningkatkan ketersediaan dan toleransi kesalahan, node Ledger disebarkan di zona berbeda. Selama lebih dari separuh node dalam keadaan sehat, data tidak akan hilang dan failover akan selesai dalam satu detik. 

Sekalipun seluruh klaster gagal, yang kemungkinannya sangat rendah, kami masih dapat memulihkan klaster melalui snapshot konsisten yang disimpan di Amazon S3 dan mengambil data terbaru yang hilang melalui sistem hilir.

Toleransi kesalahan

Pertunjukan

Tabel berikut menunjukkan spesifikasi perangkat keras untuk pengujian kinerja

Pengujian internal membuktikan bahwa klaster 4 node (satu pemimpin, dua pengikut, dan satu pembelajar) dapat memproses lebih dari 10.000 TPS. Secara desain, cluster memproses semua transaksi satu per satu. Tidak ada kondisi lock dan race sama sekali. Jadi pada skenario hot account, TPSnya sama tinggi dengan skenario normal.

TPS akun panas

Gambar berikut menunjukkan latensi setiap transaksi. Sebagian besar transaksi dapat diselesaikan dalam waktu 10 ms. Transaksi yang lebih lambat dapat diselesaikan dalam waktu 25 ms.

Latensi ms

Mendukung Layanan kami Dengan Binance Ledger

Seperti yang Anda lihat, jawaban industri tradisional terhadap masalah akun panas tidak memenuhi kebutuhan Binance dan pelanggannya. Dengan menggunakan pendekatan yang dirancang khusus untuk infrastruktur Binance, kami mendapatkan salah satu pengalaman pertukaran dan produk paling lancar yang pernah ada. Kini kami dengan senang hati berbagi pengalaman kami dengan Anda dan berharap Anda lebih memahami apa yang diperlukan untuk membuat layanan seperti Binance berfungsi.

Baca artikel berikut untuk informasi lebih lanjut tentang infrastruktur teknologi kami:

• (Blog Binance) Menggunakan MLOps untuk Membangun Pipeline Pembelajaran Mesin End-to-End Secara Real-time

• (Blog Binance) Temui CTO: Rohit Merenungkan Crypto, Blockchain, Web3, dan Bulan Pertama di Binance 

Referensi

[1] Pengganggu LMAX

[2] RockDB  

[3] Algoritma Konsensus Rakit