Prefetch Caching of Items at eBay

eBay · 2020 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Phần lớn traffic vào trang item đến từ trang kết quả tìm kiếm. Những năm trước eBay đã prefetch ảnh item sau khi trang tìm kiếm tải xong. Lần này họ muốn phục vụ cả trang item từ cache khi user bấm vào từ kết quả tìm kiếm.

Thay đổi chính

• Prefetch dự đoán ở phía server: khi xử lý một lần tìm kiếm, search service gọi bất đồng bộ tới item cache service với 5–10 item đầu (những item hay được bấm và chuyển đổi tốt; số lượng chọn theo chỉ số kinh doanh và năng lực phải thêm). Item cache service gọi item service cho từng item và lưu kết quả vào cụm memcached. Search trả về kèm cờ "có thể đã cache" cho từng item. Toàn bộ chạy trong thời gian search và trang tìm kiếm đang render, nên sẵn trước khi user bấm.
• Đọc: request trang item mang header đặc biệt; item service đọc cache, trượt thì quay về đường cũ (DB và các microservice).
• Chọn kho: cần hàng triệu insert, lookup và delete mỗi giờ, đọc dưới 15 ms, TTL từ dưới 1 phút tới 3 ngày, scale tới TB. Vì có đường quay về, hệ được phép fail-open: không cần bền, chấp nhận nhất quán cuối trong vài trăm ms trước khi user bấm, không cần replica trong cùng datacenter (Couchbase chẳng hạn cần replica mỗi region, đội chi phí); khả dụng dựa vào nhiều datacenter. Chọn CACHET (memcached + mcrouter, managed, nhiều DC), dưới 10 ms.
• Tối ưu: nén payload khi ghi, đọc và truyền nguyên dạng nén về ứng dụng; khoá là MD5 của item, site, locale, session/user, tham số URL (cache theo từng user; MD5 chỉ để khoá ngắn).
• Kiểm hợp lệ khi đọc: lưu kèm trạng thái item và user; bỏ cache nếu trạng thái đăng nhập đổi, người bán sửa item, quan hệ item–user đổi, locale đổi. Không prefetch item sắp hết hạn, đã kết thúc, vài danh mục, hay trang quá động. TTL vài phút, chọn theo thời gian trung bình user ở trang tìm kiếm và thời gian query lại.
• Kết quả: trang item trúng cache nhanh hơn khoảng 400 ms; prefetch 5–10 item phủ 70% traffic từ tìm kiếm sang item; thời gian render phần trên màn hình cải thiện 10%. Hướng tiếp: đưa cache ra edge, và cache không theo user.

Vì sao

• Thời gian user đọc trang tìm kiếm là cửa sổ rảnh để làm trước việc của trang tiếp theo; vì có đường quay về, cache được phép rẻ (không bền, không replica) (Cache và invalidation).

Bài học cho SWE

• Khi cache chỉ là đường tắt có fallback, bỏ bớt bảo đảm (bền, replica, nhất quán mạnh) để giảm chi phí.
• Chọn TTL theo hành vi user (bao lâu thì bấm), và kiểm hợp lệ bằng trạng thái lưu kèm thay vì dựa hết vào TTL.
• Chỉ prefetch phần có xác suất dùng cao; đo phần traffic được phủ để cân chi phí.

Liên quan

• Pinterest 2020 · eBay 2026 · Netflix 2018
• Cache và invalidation