Discord đang lưu trữ hàng Nghìn Tỷ tin nhắn như thế nào?

Tóm tắt ngắn:

Video kể về câu chuyện Discord giải quyết vấn đề lưu trữ hàng nghìn tỷ tin nhắn và đảm bảo hệ thống hoạt động ổn định.
Các điểm chính bao gồm việc chuyển từ cơ sở dữ liệu MongoDB sang Cassandra, sau đó lại chuyển sang ScyllaDB để giải quyết vấn đề hot partition (phân vùng nóng) và hiệu suất. Các công nghệ được đề cập bao gồm Cassandra, ScyllaDB, Rush (cho data service), và Spark Migrator. Phương pháp gossip dance được dùng để xử lý compaction trong Cassandra. Mô hình Meme Driven Engineering được nhắc đến trong quá trình lựa chọn công nghệ.
Hệ thống được tối ưu hóa đáng kể về hiệu suất, giảm độ trễ và số lượng node cần thiết. Việc chuyển đổi dữ liệu được thực hiện nhanh chóng nhờ công cụ migrate viết bằng Rush.
Video cũng mô tả chi tiết quá trình di chuyển dữ liệu khổng lồ từ Cassandra sang ScyllaDB, bao gồm việc sử dụng Super Disk và giải quyết vấn đề tombstone trong Cassandra. Kết quả là hệ thống hoạt động mượt mà ngay cả trong những thời điểm có lượng truy cập đột biến như trận chung kết World Cup 2022.

Tóm tắt chi tiết:

Video được chia thành các phần chính sau:

Phần 1: Vấn đề và giải pháp ban đầu:

Discord ban đầu sử dụng MongoDB, sau đó chuyển sang Cassandra (năm 2017) để xử lý lượng tin nhắn khổng lồ.
Hệ thống Cassandra ban đầu có 12 node, sau đó tăng lên 177 node vào đầu năm 2022. Tuy nhiên, hệ thống vẫn gặp vấn đề về độ ổn định do hot partition. Schema đơn giản dựa trên Channel ID và Bucket (10 ngày).
Vấn đề hot partition được giải thích rõ ràng: các kênh lớn (ví dụ: Minecraft Official) nhận lượng tin nhắn khổng lồ, gây quá tải cho một số node, ảnh hưởng đến hiệu suất toàn hệ thống. Ví dụ so sánh với việc xếp hàng mua iPhone được dùng để minh họa.

Phần 2: Khắc phục tạm thời với Cassandra:

Discord sử dụng kỹ thuật gossip dance để tạm thời ngắt node khỏi luồng xử lý để thực hiện compaction, giảm áp lực lên tài nguyên.
Vấn đề với garbage collection của JVM trong Cassandra gây ra độ trễ đột ngột và cần khởi động lại node thủ công. Việc tối ưu garbage collection được thực hiện nhưng không giải quyết được vấn đề triệt để.

Phần 3: Chuyển sang ScyllaDB:

ScyllaDB được chọn thay thế Cassandra vì hiệu suất cao hơn, kiến trúc Shard per core, và không có garbage collection phức tạp.
Một tầng data service được xây dựng bằng Rush (theo Meme Driven Engineering) để hợp nhất các request giống nhau, giảm tải cho database. Consistent hashing được sử dụng để định tuyến request.

Phần 4: Quá trình di chuyển dữ liệu:

Chuẩn bị database mới sử dụng Super Disk (kết hợp SSD và RAID).
Ban đầu, kế hoạch là cut-over time, nhưng quá trình di chuyển dự kiến mất 3 tháng.
Việc viết lại công cụ migrate bằng Rush (theo Meme Driven Engineering) giúp giảm thời gian di chuyển xuống còn 9 ngày, đạt tốc độ 3.2 triệu tin nhắn/giây.
Vấn đề tombstone trong Cassandra gây ra lỗi ở giai đoạn cuối, được giải quyết bằng compaction.

Phần 5: Kết quả và bài học:

Sau khi chuyển sang ScyllaDB, hệ thống hoạt động ổn định hơn, giảm độ trễ đáng kể (từ 40-125ms xuống 15ms cho đọc, giảm 10 lần cho ghi), và giảm số lượng node từ 177 xuống 72.
Biểu đồ hệ thống cho thấy sự ảnh hưởng của trận chung kết World Cup 2022 lên lượng tin nhắn. Đây là lý do để nhóm được xem bóng đá trong giờ họp.
Video kết thúc bằng lời kêu gọi tham gia cộng đồng System Design Việt Nam.

Các câu nói đáng chú ý: "Meme Driven Engineering", "hot partition", "gossip dance", miêu tả chi tiết về quá trình di chuyển dữ liệu và giải quyết vấn đề tombstone. Tất cả đều góp phần làm cho video trở nên sinh động và dễ hiểu.