Beli Kripto
Pasar
Trade
Futures
Earn
Square
Selebihnya
Blog Binance

Cara Binance Ledger Mendukung Pengalaman Binance Anda

2023-03-06

Poin Utama

  • Ledger milik Binance menyimpan saldo dan transaksi akun, sekaligus memungkinkan layanan untuk melakukan transaksi.

  • Hal ini menciptakan kondisi yang diperlukan untuk throughput tinggi, ketersediaan 24/7, dan akurasi data tingkat bita.

Peran Binance Ledger di belakang layar menjadikannya salah satu teknologi terpenting Binance. Pelajari betul cara kerjanya dan masalah yang diselesaikannya dalam pengoperasian bursa kripto terbesar di dunia di sini.

Pernahkah Anda bertanya-tanya apa yang menggerakkan Binance? Dengan kebutuhan untuk memproses jutaan transaksi setiap hari di seluruh basis pengguna yang amat besar, ada baiknya melihat mesin penggerak Binance.

Penopang operasi teknis Binance adalah Ledger miliknya. Ledger tersebut menyimpan saldo dan transaksi akun sekaligus memungkinkan layanan untuk melakukan transaksi.

Binance Memiliki Persyaratan Tinggi untuk Ledger

Seperti yang dapat dibayangkan, persyaratan untuk Ledger sangat tinggi guna memenuhi permintaan pengguna yang sangat besar. Ada tiga poin 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 bita, tanpa kehilangan dana atau kesalahan transaksi.

Mari kita lihat sebuah contoh entri dasar di Ledger. Berikut adalah transaksi umum saat akun 1 mentransfer 1 BTC ke akun 2.

Saldo sebelum transaksi:

ID_AKUN

ASET

SALDO

1

BTC         

10

2

BTC

0,1

tabel 1

Saldo setelah transaksi:

ID_AKUN

ASET

SALDO

1

BTC         

9

2

BTC

1.1

tabel 2

Dalam transaksi ini, ada dua perintah:

  1. Akun 1  -1 BTC

  2. Akun 2 +1 BTC

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

ID_AKUN

ASET

DELTA

TX_ID

WAKTU

100001

BTC

-1

tx-001

01-01-2022 01.02.03

100002

BTC

+1

tx-001

01-01-2022 01.02.03

tabel 3

Solusi Standar Industri

Satu solusi Ledger berstandar industri didasarkan pada basis data relasional. Kembali ke contoh sebelumnya, dua perintah transaksi dapat diterjemahkan menjadi dua pernyataan SQL dan dieksekusi dalam transaksi basis data (tabel 4).

begin transaction;

UPDATE balance_1 set balance = balance - 1 

WHERE account_id=1 and asset = ‘BTC’ and balance - 1 >= 0; 

If 0 row is affected then rollback;

UPDATE balance_2 set balance = balance + 1 

WHERE account_id=2 and asset = ‘BTC’ and balance + 1 >= 0; 

If 0 row is affected then rollback;

commit;

tabel 4

Kelebihan dari solusi

  1. Implementasi solusi ini cukup sederhana.

  2. Sangat mudah untuk menerapkan teknik penyetelan basis data umum seperti pemisahan baca/tulis dan sharding untuk memperbaiki kinerja.

  3. Tidak sulit bagi DevOps untuk pulih dari failover, serta memantau dan memelihara basis data komersial.

Kekurangan dari solusi

  1. TPS akan turun tajam saat ada kondisi pacu akibat kunci baris.

  2. Sulit untuk diskalakan secara horizontal untuk memperbaiki kinerja.

Masalah Akun Panas

Sayangnya untuk Binance, solusi industri yang ditunjukkan di atas tidak memenuhi persyaratannya yang tinggi. Ketika sebuah transaksi terjadi, harus memiliki kunci baris dari setiap baris yang terlibat. Kendati 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 dapat memiliki kunci baris akun. 

Transaksi lain kemudian tidak dapat melakukan apa pun selain menunggu kunci dilepaskan. Kami menyebut situasi ini sebagai masalah akun panas (hot account), dan pengujian internal menunjukkan TPS akan turun setidaknya 10 kali lipat dalam situasi ini. Anda dapat melihat masalah ini pada tabel 5 di bawah ini.

Contoh akun panas:

Tx 1 (transfer 1 BTC dari akun 1 ke akun 2)

Tx 2 (transfer 2 BTC dari akun 1 ke akun 3)

begin transaction;

begin transaction;

UPDATE balance set balance = balance - 1 

WHERE account_id=1 and asset = ‘BTC’ and balance - 1 >= 0; 

(row locked: account_id=1 and asset = ‘BTC’)

If 0 row is affected then rollback;

UPDATE balance set balance = balance - 2 

WHERE account_id=1 and asset = ‘BTC’ 

and balance - 2 >= 0; 

If 0 row is affected then rollback;

UPDATE balance set balance = balance + 1 

WHERE account_id=2 and asset = ‘BTC’ and balance + 1 >= 0; 

If 0 row is affected then rollback;

wait lock

commit;

wait lock

get lock, execute

UPDATE balance set balance = balance + 2 

WHERE account_id=3 and asset = ‘BTC’ and balance + 1 >= 0; 

If 0 row is affected then rollback;

commit;

tabel 5

Solusi Ledger Binance 

Bagaimana cara mengatasi masalah akun panas?

Salah satu solusi memungkinkan untuk masalah kami adalah mengonversi secara inovatif model multiutas menjadi mode satu utas tunggal. Ini kemudian menghindari masalah kondisi pacu, sehingga tidak akan ada masalah akun panas.

Model utas baru

Komunikasi berbasis pesan

Setelah mengimplementasikan model utas baru kami, masalah komunikasi perlu diselesaikan. Lapisan state machine memiliki satu thread, tetapi lapisan jaringan memiliki beberapa thread. Jadi, bagaimana cara kita berkomunikasi secara efisien di antara keduanya?

Disruptor [1] adalah langkah selanjutnya dalam kerumitan ini. Ini menciptakan antrean berkinerja tinggi dan bebas kunci berdasarkan desain buffer cincin.

Ketersediaan yang tinggi

Sejauh ini, kami telah mencapai performa 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 di antara node, kami menggunakan Raft Consensus Algorithm [3]. Artinya, jumlah cadangan data setara dengan jumlah node nonpemimpin yang ada. Algoritma juga memastikan sistem akan tetap bekerja dengan setidaknya setengah dari node dalam keadaan sehat untuk membantu menyediakan ketersediaan layanan yang tinggi.

Peran Domain Raft:

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

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

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

Peran domain Raft:

CQRS (Command Query Responsibility Segregation)

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

Arsitektur Ledger

Arsitektur keseluruhan

Ketentuan antara Raft dan Ledger:

Raft

Ledger

state machine tereplikasi

node ledger

status

saldo

perintah

transaksi

tabel 6

Lihat Peran Domain

  • Pusat ledger raft

Gunakan pesan yang dihasilkan oleh pelajar dan simpan data transaksi serta saldo di MySQL untuk keperluan kueri.

Pemrosesan permintaan

Permintaan transaksi pertama-tama akan melalui lapisan jaringan, lapisan ledger (pengurus permintaan), lalu lapisan raft (sinkronisasi log raft). Kemudian, permintaan tersebut akan kembali ke lapisan ledger (state machine), lapisan jaringan (pengurus respons), dan akhirnya mengembalikan respons ke klien.

Data diteruskan melalui antrean antara dua lapisan. 

  1. Lapisan Jaringan – Lakukan deserialisasi permintaan rpc dan masukkan ke antrean permintaan.

  2. Lapisan Ledger – Dapatkan permintaan dari antrean dan siapkan konteks. Kemudian, lapisan ini akan memasukkan metadata permintaan ke dalam antrean raft. 

  3. Lapisan Raft – Dapatkan metadata permintaan dari antrean raft dan sinkronkan di antara semua pengikut. Kemudian, lapisan ini akan memasukkan hasilnya ke dalam antrean penerapan.

  4. Lapisan Ledger – Dapatkan data dari antrean penerapan dan perbarui state machine. Kemudian, lapisan ini akan memasukkan hasilnya ke dalam antrean respons.

  5. Lapisan Jaringan – Dapatkan hasil dari antrean respons dan susun serta buat serialisasi data respons sebelum mengembalikannya ke klien.

Pemrosesan permintaan

Pemulihan data

Setiap node Ledger akan memicu snapshot generik berdasarkan periode waktu. Selain itu, kami juga mengimplementasikan snapshot yang konsisten. Setiap node dipicu pada indeks log raft yang sama untuk memastikan bahwa state machine sama persis saat setiap node memicu snapshot. Kemudian, snapshot akan diunggah ke S3 untuk verifikasi oleh Checker dan sebagai cold backup.

Saat dimulai ulang, Ledger membaca snapshot lokal dan membangun kembali state machine. Kemudian, Ledger akan memutar ulang log raft lokal dan menyinkronkan log terbaru dari pemimpin hingga mengikuti indeks terbaru. Jika snapshot atau log raft lokal tidak ada, maka akan diperoleh dari pemimpin.

Snapshot & Pemulihan

Toleransi bencana

Untuk memperbaiki ketersediaan dan toleransi kesalahan, node Ledger dikerahkan di zona berbeda. Selama lebih dari setengah node sehat, data tidak akan hilang dan failover akan selesai dalam satu detik. 

Meskipun seluruh kluster gagal, yang memiliki probabilitas sangat rendah, kami masih dapat memulihkan kluster melalui snapshot konsisten yang disimpan di Amazon S3 dan mengambil data terakhir yang hilang melalui sistem downstream.

Toleransi kesalahan

Kinerja

Tabel berikut menunjukkan spesifikasi perangkat keras untuk pengujian kinerja

Komponen

Jenis Instans

Bandwidth Jaringan (Gbps)

Bandwidth EBS (Gbps)

Jenis Penyimpanan EBS

Pemimpin/ Pengikut

M6i.4xlarge

16c64g

Hingga 12,5

Hingga 10

2T GP3 * 3 IOPS6000 625MB/s

Pelajar

M6i.4xlarge

16c64g

Hingga 12,5

Hingga 10

2T GP3 * 3 IOPS6000 625MB/s

Bench

C5.4xlarge

16c32g

Hingga 10

4,750

Hanya Volume Akar

Pengujian internal membuktikan bahwa kluster 4 node (satu pemimpin, dua pengikut, dan satu pelajar) dapat memproses lebih dari 10.000 TPS. Secara desain, kluster memproses semua transaksi satu per satu. Sama sekali tidak ada kondisi kunci dan pacu. Jadi, dalam skenario akun panas, TPS setinggi dalam skenario normal.

TPS akun panas

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

Latensi ms

Memimpin Industri Dengan Binance Ledger

Kami sangat bangga dengan hasil yang kami capai dan solusi Ledger unik kami. Seperti yang Anda lihat, jawaban industri tradisional untuk masalah akun panas tidak memenuhi kebutuhan Binance dan pelanggannya. Dengan menggunakan pendekatan yang dirancang khusus untuk infrastruktur Binance, kami menyajikan salah satu pengalaman bursa dan produk paling lancar yang tersedia. Kami senang karena sekarang dapat membagikan pengalaman kami dengan Anda dan berharap Anda lebih memahami apa yang membuat layanan seperti Binance berfungsi.

Baca artikel berikut untuk informasi selengkapnya tentang infrastruktur teknologi kami:

Referensi

[1] LMAX Disruptor

[2] RocksDB  

[3] Raft Consensus Algorithm

219,831,262 pengguna memilih kami. Ketahui alasannya sekarang juga.
Daftar Sekarang