Những Điểm Chính

  • 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.

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

Vai trò đằng sau hậu trường của Binance Ledger khiến nó 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 đề mà nó giải quyết trong hoạt động của sàn giao dịch tiền điện tử 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 hoạt động hiệu quả chưa? Với nhu cầu xử lý hàng triệu giao dịch mỗi ngày trên một lượng người dùng khổng lồ, bạn nên xem Binance có gì bên trong.

Nền tảng hoạt động kỹ thuật của Binance là Ledger. Ledger lưu trữ số dư và giao dịch của tài khoản trong khi 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 có thể tưởng tượng, các yêu cầu đối với Ledger rất cao để đá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 xử lý lượng TPS (giao dịch mỗi giây) lớn vào thời điểm cao điểm.

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

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

Hãy xem một ví dụ về mục nhập cơ bản trên Sổ cái. Đây là một giao dịch phổ biến trong đó tài khoản 1 chuyển 1 BTC sang tài khoản 2.

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

TÀI KHOẢN_ID

TÀI SẢN

SỰ CÂN BẰNG

1

BTC         

10

2

Tiền tệ

0,1

bảng-1

Số dư sau giao dịch:

TÀI KHOẢN_ID

TÀI SẢN

SỰ CÂN BẰNG

1

BTC         

9

2

Tiền tệ

1.1

bảng-2

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

  1. Tài khoản 1    -1 BTC

  2. Tài khoản 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 tra và đối chiếu.

TÀI KHOẢN_ID

TÀI SẢN

ĐỒNG BẰNG

Mã số TX

THỜI GIAN

100001

Tiền tệ

-1

tx-001

2022-01-01 01:02:03

100002

Tiền tệ

+1

tx-001

2022-01-01 01:02:03

bảng-3

Giải pháp công nghiệp tiêu chuẩn

Một giải pháp Ledger tiêu chuẩn của ngành dựa trên cơ sở dữ liệu quan hệ. Quay 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à thực hiện trong một giao dịch cơ sở dữ liệu (bảng-4).

bắt đầu giao dịch;

CẬP NHẬT balance_1 đặt balance = balance - 1

NƠI account_id=1 và tài sản = ‘BTC’ và số dư - 1 >= 0;

Nếu hàng thứ 0 bị ảnh hưởng thì hãy khôi phục lại;

CẬP NHẬT balance_2 đặt số dư = số dư + 1

NƠI account_id=2 và tài sản = ‘BTC’ và số dư + 1 >= 0;

Nếu hàng thứ 0 bị ảnh hưởng thì hãy khôi phục lại;

làm;

bảng-4

Ưu điểm của giải pháp

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

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

  3. Đội devops không gặp khó khăn khi khôi phục sau khi chuyển đổi dự phòng, cũng như giám sát và duy trì cơ sở dữ liệu thương mại.

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

  1. TPS sẽ giảm mạnh khi có tình trạng đua do kẹt hàng.

  2. Khó có thể mở rộng 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 cho Binance, 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 nó. Khi một giao dịch xảy ra, nó phải giữ các row lock của mọi row liên quan. Trong khi một số tài khoản có tương đối ít giao dịch để xử lý, tất nhiên, có những tài khoản bận rộn với nhiều giao dịch đồng thời. Trong trường hợp này, chỉ có một giao dịch có thể giữ row lock của tài khoản.

Các giao dịch khác sau đó không thể làm gì ngoài việc chờ 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)

bắt đầu giao dịch;

bắt đầu giao dịch;

CẬP NHẬT số dư thiết lập số dư = số dư - 1

NƠI account_id=1 và tài sản = ‘BTC’ và số dư - 1 >= 0;

(hàng bị khóa: account_id=1 và tài sản = ‘BTC’)

Nếu hàng thứ 0 bị ảnh hưởng thì hãy khôi phục lại;

CẬP NHẬT số dư thiết lập số dư = số dư - 2

NƠI account_id=1 và tài sản = ‘BTC’

và cân bằng - 2 >= 0;

Nếu hàng thứ 0 bị ảnh hưởng thì hãy khôi phục lại;

CẬP NHẬT số dư thiết lập số dư = số dư + 1

NƠI account_id=2 và tài sản = ‘BTC’ và số dư + 1 >= 0;

Nếu hàng thứ 0 bị ảnh hưởng thì hãy khôi phục lại;

chờ khóa

làm;

chờ khóa

khóa, thực hiện

CẬP NHẬT số dư thiết lập số dư = số dư + 2

NƠI account_id=3 và tài sản = ‘BTC’ và số dư + 1 >= 0;

Nếu hàng thứ 0 bị ảnh hưởng thì hãy khôi phục lại;

làm;

bảng-5

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

Làm thế nào để 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 ta là chuyển đổi sáng tạo mô hình đa luồng sang chế độ đơn luồng. Điều này sau đó tránh được vấn đề tình trạng chạy đua và kết quả là sẽ không có vấn đề về tài khoản nóng.

Mô hình chủ đề mới

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

Sau khi triển khai mô hình luồng mới của chúng tôi, một vấn đề giao tiếp cần được giải quyết. Lớp máy trạng thái là luồng đơn, nhưng lớp mạng là đa luồng, vậy làm thế nào để chúng ta 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 không khóa, hiệu suất cao dựa trên thiết kế bộ đệm vòng.

Tính khả dụng cao

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

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

Vai trò của miền Raft:

  • Người dẫn đầu. Người dẫn đầu 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ả những người theo dõi.

  • Người theo dõi. Người theo dõi sẽ theo dõi người lãnh đạo trong mọi hoạt động. Nếu người lãnh đạo thất bại, một trong những người theo dõi sẽ được bầu làm người lãnh đạo mới.

  • Người học. Người học là những người theo dõi không có quyền biểu quyết, gửi từng bản ghi thay đổi giao dịch/có giá trị bất biến đến các dịch vụ khác.

Vai trò miền bè

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

Một tiêu chí quan trọng khác mà chúng tôi muốn đảm bảo là hiệu suất ghi cao hơn của Ledger và khả năng cho các điều kiện truy vấn đa dạng hơn. Đối với điều này, chúng tôi cần tạo các miền khác nhau. Miền raft cung cấp khả năng ghi hiệu quả hơn dựa trên rocksdb+raft và 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ệ để truy vấn bên ngoài. Chúng tôi cũng có thể triển khai phân tách trách nhiệm truy vấn lệnh ở cấp độ kiến ​​trúc.

Kiến trúc sổ cái

Kiến trúc tổng thể

Điều khoản giữa Raft và Ledger:

bè

Sổ cái

máy trạng thái được sao chép

các nút sổ cái

tình trạng

THĂNG BẰNG

yêu cầu

giao dịch

bảng-6

Xem Vai trò miền

  • Trung tâm sổ cái bè

Sử dụng tin nhắn do người học 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.

Yêu cầu xử lý

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

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

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

  2. Lớp sổ cái – Lấy yêu cầu từ hàng đợi và chuẩn bị ngữ cảnh. Sau đó, nó sẽ đưa siêu dữ liệu yêu cầu vào hàng đợi raft.

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

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

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

Yêu cầu xử lý

Phục hồi dữ liệu

Mỗi nút Ledger sẽ kích hoạt một snapshot chung dựa trên một khoảng thời gian. Ngoài ra, chúng tôi cũng triển khai một snapshot nhất quán. Mỗi nút được kích hoạt tại cùng một chỉ mục nhật ký raft để đảm bảo rằng máy trạng thái hoàn toàn giống nhau khi mỗi nút kích hoạt snapshot. Sau đó, snapshot sẽ được tải lên S3 để Checker xác minh và dưới dạng bản sao lưu lạnh.

Khi Ledger khởi động lại, nó sẽ đọc snapshot cục bộ và xây dựng lại máy trạng thái. Sau đó, nó sẽ phát lại log raft cục bộ và đồng bộ log mới nhất từ ​​leader cho đến khi nó bắt kịp index mới nhất. Nếu snapshot cục bộ hoặc log raft không tồn tại, nó sẽ được lấy từ leader.

Ảnh chụp nhanh & Phục hồi

Khả năng chịu đựng thiên tai

Để cải thiện tính khả dụng và khả năng chịu lỗi, các nút Ledger được triển khai ở các vùng khác nhau. Miễn là hơn một nửa số nút 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, mặc dù khả năng này rất thấp, chúng ta vẫn có thể khôi phục cụm thông qua ảnh chụp nhanh 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 thông qua hệ thống hạ lưu.

Khả năng chịu lỗi

Hiệu suất

Bảng sau đây hiển thị 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 (Gbps)

Băng thông EBS (Gbps)

Loại lưu trữ EBS

Người lãnh đạo/Người theo dõi

M6i.4xlớn

16c64g

Lên đến 12,5

Lên đến 10

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

Người học

M6i.4xlớn

16c64g

Lên đến 12,5

Lên đến 10

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

Ghế dài

C5.4xlớn

16c32g

Lên đến 10

4.750

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

Các thử nghiệm nội bộ chứng minh rằng một cụm 4 nút (một nút dẫn đầu, hai nút theo sau và một nút học) có thể xử lý hơn 10.000 TPS. Theo thiết kế, cụm xử lý tất cả các giao dịch từng cái một. Không có tình trạng khóa và chạy đua nào cả. Vì vậy, trong kịch bản tài khoản nóng, TPS cao như trong các kịch bản bình thường.

Tài khoản nóng TPS

Hình sau đây cho thấy độ trễ của mỗi giao dịch. Hầu hết các giao dịch có thể hoàn tất trong vòng 10 ms. Các giao dịch chậm hơn có thể hoàn tất trong vòng 25ms.

Độ trễ ms

Cung cấp dịch vụ của chúng tôi với Binance Ledger

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

Đọ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:

  • (Blog Binance) Sử dụng MLOps để xây dựng một đường ống học máy đầu cuối thời gian thực

  • (Blog Binance) Gặp gỡ CTO: Rohit suy ngẫm về tiền điện tử, Blockchain, Web3 và tháng đầu tiên của anh ấy tại Binance

Tài liệu tham khảo

[1] Máy phá vỡ LMAX

[2] ĐáDB  

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