Sharding Cash · SWE Wiki

Square · 2018 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bài mở đầu một series về Vitess ở Cash App; các phần sau không có trong wiki.

Bối cảnh

Cash App bắt đầu là thử nghiệm Hack Week trên một MySQL; tới cuối 2016 đã hơn nửa triệu dòng code, chật vật giữ uptime lúc đỉnh. Đã dùng hết "sách giáo khoa": cache, chuyển dữ liệu lịch sử ra, đọc replica, mua phần cứng đắt; mỗi thứ chỉ mua thêm thời gian.

Ban đầu tự thiết kế giải pháp, rồi chọn Vitess (YouTube làm) dù tài liệu còn sơ sài, vì nó cho cảm giác vẫn là một DB và route SQL tới đúng shard.
Chỗ "ảo giác" hở: transaction xuyên shard không ACID đầy đủ, query fan-out có hiệu năng và uptime khác hẳn. Vì giữ tiền của khách, Cash App không đổi nhất quán lấy availability: sửa code để phần xử lý tiền không làm transaction xuyên shard.
Khái niệm entity group (chủ yếu là khách hàng): mọi dữ liệu của một nhóm luôn ở cùng shard qua các lần split, trong nhóm là ACID; ghi xuyên nhóm ("cowrite") cần biện pháp riêng.
Shard split đầu tiên (khoảng 11/2017) là vertical split tách các bảng không shard khỏi các bảng sẽ shard tiếp: clone bảng, giữ đồng bộ bằng replay binlog, rồi MigrateServedFrom ... MASTER chuyển traffic master. Lúc đó lệnh không đảo ngược được nếu không mất dữ liệu (về sau Vitess đã cho đảo ngược). Downtime dưới một giây. Một năm sau họ làm split thường xuyên, tránh giờ đỉnh thứ Sáu.

Tăng trưởng quá nhanh so với scale dọc và replica; sharding là bước cuối còn lại.

Lớp sharding trong suốt vẫn rò rỉ ngữ nghĩa; phải đổi domain model để ranh giới transaction trùng ranh giới shard.
Bước cutover không đảo ngược được cần được giảm rủi ro bằng chạy thử, clone + diff trước.