How Twitter Uses Redis to Scale - 105TB RAM, 39MM QPS, 10,000+ Instances

Twitter · 2014 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Nguồn thứ cấp: HighScalability tóm tắt talk của Yao Yue (đội Cache của Twitter từ 2010), kèm nhận xét riêng của người viết. Ghi "theo Yao Yue qua lời kể của HighScalability".

Bối cảnh

• Năm 2014 cache của Twitter: khoảng 105 TB RAM, 39 triệu QPS, hơn 10.000 instance; Redis từ 2010 cho Timeline (danh sách ID tweet), rồi Ads. Dịch vụ cache tăng từ một project lên gần trăm project dùng.
• Vì sao Redis thay memcache cho timeline: ghi/đọc nhỏ, tăng dần trên object lớn (home timeline có thể khoảng 3.000 phần tử); read-modify-write cả object qua mạng nghẽn băng thông khi object trên 1 KB ở 100K+ ops/giây. Cần thêm không gian khoá phân cấp cho schema linh hoạt và metric.

Thay đổi chính

• Fork Redis 2.4, thêm hai kiểu dữ liệu, quản lý cluster và log nội bộ (đổi lại bị kẹt ở bản cũ):
  • Hybrid List = danh sách liên kết của các ziplist kích thước cố định theo byte: tránh realloc/memmove ziplist lớn, tránh phải đuổi hàng loạt timeline nhỏ để có chỗ liền cho một timeline lớn, nên latency ghi khi fan-out dự đoán được.
  • BTree cho range query trên khoá phụ (lấy từ BSD); tốn bộ nhớ metadata.
• Cluster bằng proxy: không để server tự đồng thuận (giữ server "đơn giản, ngốc, nhanh"), không làm ở client (gần 100 project, đẩy thay đổi mất hàng năm). Tách đường dữ liệu nhanh khỏi đường điều khiển chậm; proxy stateless, một cluster leader giữ cái nhìn toàn cục. Theo đo đạc của họ, hop thêm không đáng kể: qua Redis dưới 0,5 ms, qua Finagle (JVM) gần 10 ms; proxy C++ nhanh hơn rõ nên tầng proxy chuyển về C/C++.
• Insight: cache ghi log mọi lệnh (chỉ metadata) nhưng tổng hợp ngay trên máy rồi gửi bản tóm tắt (Storm tổng hợp) vì gửi log thô tốn khoảng 10% băng thông; trả lời được top key, traffic gai, số khoá duy nhất. Theo Yao Yue, phần lớn lần "cache lỗi" thật ra là client cấu hình sai hoặc lạm dụng, và cần dữ liệu để chứng minh.
• Bài học khác: tail latency quan trọng khi fan-out nhiều shard; Mesos với giới hạn cứng làm Redis (fragmentation) phải dư 10–20% bộ nhớ; Lua on-demand chưa an toàn cho SLA.

Vì sao

• Ở quy mô gần trăm khách nội bộ, tính dự đoán được của service quan trọng hơn tính năng.

Bài học cho SWE

• Cấu trúc dữ liệu cần giới hạn kích thước khối để latency không phụ thuộc kích thước object.
• Logic cluster đặt ở proxy cho phép sửa mà không restart node có state và không phải cập nhật hàng trăm client.
• Tính toán gần dữ liệu (tóm tắt log tại máy) trước khi đẩy qua mạng.

Liên quan

• Cache và invalidation · Realtime và fan-out · Observability và monitoring
• Fan-out timeline của Twitter: Twitter 2013