- Khi tăng trưởng, Discord đã liên tục thay thế DB lưu trữ hệ thống nhắn tin
- Ban đầu là một MongoDB đơn lẻ. Đến tháng 11/2015, khi số lượng tin nhắn tăng lên 100 triệu, giới hạn của MongoDB bắt đầu bộc lộ
- Năm 2017, họ chuyển sang Cassandra với cụm 12 node để lưu trữ hàng tỷ tin nhắn
- Đến năm 2022, số tin nhắn tăng vọt lên hàng nghìn tỷ, khiến hạ tầng phình lên tới 177 node, độ trễ trở nên khó dự đoán và chi phí bảo trì cực kỳ đắt đỏ
- Vấn đề của Discord với Cassandra là Hot Partition. Một phần cụ thể trong DB bị quá tải, làm suy giảm hiệu năng của toàn bộ ứng dụng
- Vì cấu trúc dữ liệu nội bộ của Cassandra sử dụng LSM tree nên chi phí đọc cao hơn ghi, và việc nhiều người dùng cùng đọc đồng thời trên một máy chủ đơn lẻ tạo ra hotspot, dẫn đến suy giảm hiệu năng
- Các tác vụ bảo trì như nén SSTable cũng ảnh hưởng tới hiệu năng tổng thể, khiến vấn đề trở nên nghiêm trọng hơn
- Vì vậy, Discord đã bắt tay vào thiết kế lại kiến trúc bằng cách hợp nhất nhiều thành phần khác nhau
- Họ tận dụng monolithic API, dịch vụ dữ liệu được triển khai bằng Rust, và hệ thống lưu trữ dựa trên ScyllaDB (DB tương thích Cassandra được phát triển bằng C++)
- Việc áp dụng ScyllaDB đã mang lại những cải thiện đáng kể
- p99 read latency giảm xuống còn 15ms, so với 40~125ms của Cassandra
- p99 write latency giảm xuống còn 5ms, so với 5~70ms của Cassandra
- Các kỹ sư Discord đã viết dịch vụ dữ liệu bằng Rust
- Họ sử dụng tính năng Fearless Concurrency của Rust để kiểm soát lưu lượng đồng thời đối với hot partition
- Các thư viện và tính năng đồng thời của Rust rất phù hợp với yêu cầu của Discord
- Dịch vụ dữ liệu đóng vai trò là lớp trung gian giữa API monolith và cụm cơ sở dữ liệu
3 bình luận
Đúng lúc tôi đang tìm hiểu về tech stack của Discord, cảm ơn bạn!
Cách Discord lưu trữ hàng chục tỷ tin nhắn
GC của Go có overhead khá lớn, vì vậy các cách tinh chỉnh vẫn liên tục được bổ sung và cả memory arena cũng đang được đưa vào.
Vì sao nên chọn ScyllaDB làm giải pháp thay thế Cassandra
Cách Discord giảm thiểu độ trễ của ổ đĩa mạng