Mua Crypto
Thị trường
Giao dịch
Futures
Earn
Square
Nhiều hơn
Binance Blog

Cách Binance Ledger tối ưu trải nghiệm của bạn với Binance

2023-02-05

Các nội dung chính

  • Ledger (Sổ cái) của Binance lưu trữ số dư tài khoản và giao dịch, đồng thời cho phép các dịch vụ thực hiện giao dịch.

  • Ledger tạo ra môi trường cần thiết cho thông lượng cao, tính khả dụng 24/7 và độ chính xác của dữ liệu ở cấp độ bit.

Vai trò thực sự của Binance Ledger đã giúp giải pháp này trở thành một trong những công nghệ quan trọng nhất của Binance. Tìm hiểu chính xác cách thức hoạt động và các vấn đề Binance Ledger đang giải quyết trong hoạt động của sàn giao dịch tiền mã hóa lớn nhất thế giới tại đây.

Bạn đã bao giờ tự hỏi chính xác điều gì khiến Binance đạt được nhiều thành công vậy chưa? Với nhu cầu xử lý hàng triệu giao dịch hàng ngày trên một cơ sở người dùng khổng lồ, ta cần xem xét kỹ những gì Binance đã có.

Nền tảng cho các hoạt động kỹ thuật của Binance là Ledger - Sổ cái. Sổ cái lưu trữ số dư và giao dịch của tài khoản, đồng thời cho phép các dịch vụ thực hiện giao dịch.

Binance có yêu cầu cao đối với Ledger

Như bạn biết đấy, chúng tôi có yêu cầu rất cao đối với Ledger để có thể đáp ứng nhu cầu lớn của người dùng. Có ba điểm chính cần được xem xét:

  • Thông lượng cao với khả năng cho phép một lượng lớn TPS (giao dịch mỗi giây) vào thời gian cao điểm.

  • Sẵn sàng 24/7, không có thời gian chết.

  • Độ chính xác của dữ liệu ở cấp độ bit, không mất tiền hay lỗi giao dịch.

Hãy xem ví dụ về một khoản mục cơ bản trên Sổ cái. Đây là một giao dịch thường gặp, trong đó tài khoản 1 chuyển 1 BTC sang tài khoản 2.

Số dư trước giao dịch:

ACCOUNT_ID

TÀI SẢN

SỐ DƯ

1

BTC         

10

2

BTC

0,1

table-1

Số dư sau giao dịch:

ACCOUNT_ID

TÀI SẢN

SỐ DƯ

1

BTC         

9

2

BTC

1.1

table-2

Trong giao dịch này có hai lệnh:

  1. Account 1    -1 BTC

  2. Account 2 +1 BTC

Khi giao dịch được thực hiện, hai nhật ký số dư sẽ được lưu trữ để kiểm toán và đối chiếu.

ACCOUNT_ID

TÀI SẢN

DELTA

TX_ID

THỜI GIAN

100001

BTC

-1

tx-001

08:02:03 01/01/2022

100002

BTC

+1

tx-001

08:02:03 01/01/2022

table-3

Giải pháp ngành tiêu chuẩn

Một giải pháp Sổ cái tiêu chuẩn của ngành sẽ dựa trên cơ sở dữ liệu quan hệ. Quay trở lại ví dụ trước, hai lệnh của giao dịch có thể được dịch thành hai câu lệnh SQL và được thực hiện trong một giao dịch cơ sở dữ liệu (table-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;

table-4

Những ưu điểm của giải pháp

  1. Cách thực hiện khá đơn giản.

  2. Dễ áp dụng các kỹ thuật điều chỉnh cơ sở dữ liệu phổ biến như chia nhỏ và phân tách đọc/ghi để cải thiện hiệu suất.

  3. Không khó để các nhà phát triển phục hồi sau khi chuyển đổi dự phòng, cũng như theo dõi và duy trì cơ sở dữ liệu thương mại.

Những nhược điểm của giải pháp

  1. TPS sẽ giảm mạnh khi xảy ra điều kiện tranh đua do khóa hàng.

  2. Khó mở rộng quy mô theo chiều ngang để cải thiện hiệu suất.

Vấn đề tài khoản nóng

Thật không may, giải pháp ngành được trình bày ở trên không đáp ứng được các yêu cầu cao của Binance. Khi xảy ra một giao dịch, Binance phải giữ liên kết của các khóa hàng của mọi hàng. Bên cạnh một số tài khoản có tương đối ít giao dịch để xử lý thì đương nhiên, cũng có những tài khoản bận rộn với nhiều giao dịch diễn ra đồng thời. Trong trường hợp này, chỉ một giao dịch có thể giữ khóa hàng của tài khoản. 

Khi đó, các giao dịch khác chỉ có thể đợi khóa được mở. Chúng tôi gọi tình huống này là sự cố tài khoản nóng và các thử nghiệm nội bộ cho thấy TPS sẽ giảm ít nhất 10 lần trong tình huống này. Bạn có thể thấy vấn đề này trong bảng 5 bên dưới.

Ví dụ về tài khoản nóng:

Tx 1 (chuyển 1 BTC từ tài khoản 1 sang tài khoản 2)

Tx 2 (chuyển 2 BTC từ tài khoản 1 sang tài khoản 3)

begin transaction;

begin transaction;

UPDATE balance set balance = balance - 1 

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

(hàng bị khóa: account_id=1 và tài sản = '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;

table-5

Giải pháp Sổ cái của Binance 

Cách chúng tôi giải quyết vấn đề tài khoản nóng

Một giải pháp khả thi cho vấn đề của chúng tôi là chuyển đổi sáng tạo từ mô hình đa luồng sang chế độ đơn luồng. Điều này sẽ giúp tránh vấn đề về điều kiện tranh đua và do đó sẽ không có vấn đề về tài khoản nóng.

Mô hình luồng mới

Giao tiếp dựa trên tin nhắn

Sau khi triển khai mô hình luồng mới, chúng tôi có một vấn đề giao tiếp cần được giải quyết. Lớp máy trạng thái là đơn luồng, nhưng lớp mạng lưới lại là đa luồng, vậy chúng tôi làm thế nào để giao tiếp hiệu quả giữa hai lớp?

Disruptor [1] là bước tiếp theo trong câu đố. Nó tạo ra một hàng đợi hiệu suất cao, không khóa dựa trên thiết kế bộ đệm vòng.

Tính khả dụng cao

Tính đến nay, chúng tôi đã đạt được hiệu suất cao nhờ sử dụng mô hình trong bộ nhớ và bộ lưu trữ cục bộ RocksDB [2]. Nhưng một lần nữa, chúng tôi lại gặp phải một thách thức mới. Bây giờ chúng ta cần quan tâm đến tính khả dụng của dữ liệu cao.

Để đảm bảo tính nhất quán dữ liệu giữa các node, chúng tôi sử dụng thuật toán đồng thuận Raft [3]. Điều này nghĩa là số lượng bản sao lưu dữ liệu bằng với số lượng node không leader hiện có. Thuật toán cũng đảm bảo hệ thống sẽ vẫn hoạt động với ít nhất một nửa số node hoạt động tốt, giúp cung cấp tính khả dụng cao của dịch vụ.

Vai trò của miền Raft:

  • Leader. Leader xử lý tất cả các yêu cầu của khách hàng và sao chép hoạt động cho tất cả follower.

  • Follower. Follower đi theo leader trong mọi hoạt động. Nếu leader thất bại, một trong những follower sẽ được bầu làm leader mới. 

  • Learner. Learner là những follower không bỏ phiếu gửi từng bản ghi thay đổi giao dịch/bản ghi bình thường đến các dịch vụ khác.

Vai trò của miền Raft

CQRS (Phân tách trách nhiệm truy vấn lệnh)

Một tiêu chí quan trọng khác chúng tôi muốn đảm bảo là hiệu suất ghi cao hơn của Sổ cái và khả năng cung cấp các điều kiện truy vấn đa dạng hơn. Để làm được vậy, chúng tôi cần tạo nhiều miền khác nhau. Miền Raft cho khả năng ghi hiệu quả hơn dựa trên rocksdb+raft, miền View lắng nghe các thông báo của miền Raft và lưu chúng vào cơ sở dữ liệu quan hệ cho các truy vấn bên ngoài. Chúng tôi cũng có thể thực hiện phân tách trách nhiệm truy vấn lệnh ở cấp độ kiến trúc.

Kiến trúc của Ledger

Kiến trúc tổng thể

Các điều khoản giữa Raft và Sổ cái:

Raft

Ledger

máy trạng thái sao chép

node sổ cái

tình trạng

số dư

lệnh

giao dịch

table-6

Xem các vai trò của miền

  • Trung tâm sổ cái Raft

Sử dụng thông báo do learner tạo ra và lưu trữ dữ liệu giao dịch và số dư trong MySQL cho mục đích truy vấn.

Xử lý yêu cầu

Trước tiên, một yêu cầu giao dịch sẽ đi qua lớp mạng lưới, lớp sổ cái (trình xử lý yêu cầu) và lớp Raft (đồng bộ bản ghi Raft). Sau đó, yêu cầu sẽ quay trở lại lớp sổ cái (máy trạng thái), lớp mạng lưới (trình xử lý phản hồi) và cuối cùng trả về phản hồi cho khách.

Dữ liệu được truyền qua hàng đợi giữa hai lớp. 

  1. Lớp mạng lưới – Giải tuần tự hóa yêu cầu rpc và đặt vào hàng đợi yêu cầu.

  2. Lớp Ledger – Nhận yêu cầu từ hàng đợi và chuẩn bị bối cảnh. Sau đó, lớp sổ cái sẽ đặt siêu dữ liệu yêu cầu vào hàng đợi Raft. 

  3. Lớp Raft – Nhận siêu dữ liệu yêu cầu từ hàng đợi Raft và đồng bộ hóa giữa tất cả follower. Sau đó, lớp Raft sẽ đưa kết quả vào hàng đợi áp dụng.

  4. Lớp Ledger – Lấy dữ liệu từ hàng đợi áp dụng và cập nhật máy trạng thái. Sau đó, lớp sổ cái sẽ đưa kết quả vào hàng đợi phản hồi.

  5. Lớp mạng lưới – Nhận kết quả từ hàng đợi phản hồi, đồng thời xây dựng và tuần tự hóa dữ liệu phản hồi trước khi trả lại cho khách.

Xử lý yêu cầu

Phục hồi dữ liệu

Mỗi node sổ cái sẽ kích hoạt một lần thu thập dữ liệu chung dựa trên một khoảng thời gian. Ngoài ra, chúng tôi cũng triển khai thu thập dữ liệu nhất quán. Mỗi node được kích hoạt tại cùng một chỉ số bản ghi Raft để đảm bảo máy trạng thái hoàn toàn giống nhau khi mỗi node kích hoạt thu thập dữ liệu. Sau đó, dữ liệu thu thập sẽ được tải lên S3 để Trình kiểm tra xác minh và làm bản sao lưu lạnh.

Khi Ledger khởi động lại, nó sẽ đọc dữ liệu thu thập cục bộ và xây dựng lại máy trạng thái. Sau đó, Ledger phát lại bản ghi Raft cục bộ và đồng bộ hóa bản ghi mới nhất từ leader cho đến khi bắt kịp với chỉ số mới nhất. Nếu dữ liệu thu thập cục bộ hoặc nhật ký Raft không tồn tại, dữ liệu sẽ được lấy từ leader.

Thu thập dữ liệu và phục hồi

Chống chịu sự cố

Để cải thiện tính khả dụng và khả năng chịu lỗi, các node sổ cái được triển khai ở nhiều vùng khác nhau. Miễn là hơn một nửa node hoạt động tốt, dữ liệu sẽ không bị mất và quá trình chuyển đổi dự phòng sẽ hoàn tất trong một giây. 

Ngay cả khi toàn bộ cụm bị lỗi, dù xác suất này rất thấp, chúng tôi vẫn có thể khôi phục cụm thông qua dữ liệu thu thập nhất quán được lưu trữ trong Amazon S3 và truy xuất dữ liệu bị mất mới nhất qua hệ thống hạ lưu.

Khả năng chịu lỗi

Hiệu suất

Bảng sau đây thể hiện thông số kỹ thuật phần cứng cho bài kiểm tra hiệu suất

Thành phần

Loại phiên bản

Băng thông mạng lưới (Gbps)

Băng thông EBS (Gbps)

Loại lưu trữ EBS

Leader/Follower

M6i.4xlarge

16c64g

Lên tới 12,5

Lên tới 10

2T GP3 * 3 IOPS6000 625MB/giây

Learner

M6i.4xlarge

16c64g

Lên tới 12,5

Lên tới 10

2T GP3 * 3 IOPS6000 625MB/giây

Bench

C5.4xlarge

16c32g

Lên tới 10

4,750

Chỉ khối lượng gốc

Các thử nghiệm nội bộ chứng minh rằng cụm 4 node (một leader, hai follower và một learner) có thể xử lý hơn 10.000 TPS. Theo thiết kế, cụm xử lý từng giao dịch một. Không có khóa và điều kiện tranh đua. Vì vậy, khi có tài khoản nóng, TPS vẫn cao như trong các tình huống thông thường.

TPS tài khoản nóng

Hình dưới đây cho thấy tốc độ xử lý của mỗi giao dịch. Hầu hết các giao dịch có thể được hoàn tất trong vòng 10 ms. Các giao dịch chậm hơn có thể được hoàn tất trong vòng 25 mili giây.

Tốc độ xử lý ms

Dẫn đầu ngành với Binance Ledger

Chúng tôi vô cùng tự hào về những kết quả đã đạt được và giải pháp Sổ cái độc đáo của mình. Như bạn đã thấy, câu trả lời thường thấy của ngành cho vấn đề tài khoản nóng không đáp ứng nhu cầu của Binance và khách hàng của chúng tôi. Bằng cách sử dụng phương pháp được thiết kế dành riêng cho cơ sở hạ tầng của Binance, chúng tôi đã đạt được một trong những trải nghiệm sản phẩm và sàn giao dịch mượt mà nhất trên thị trường. Chúng tôi rất vui được chia sẻ với bạn trải nghiệm của mình và hy vọng bạn hiểu rõ hơn về những điều cần làm để một dịch vụ như Binance hoạt động.

Đọc bài viết sau để biết thêm thông tin về cơ sở hạ tầng công nghệ của chúng tôi:

Nội dung tham chiếu

[1] LMAX Disruptor

[2] RocksDB  

[3] Thuật toán đồng thuận Raft

219,799,592 người dùng đã chọn chúng tôi. Tìm hiểu lý do ngay hôm nay.
Đăng ký ngay