Cách Meta duy trì tính nhất quán của bộ nhớ đệm khi dùng vô hiệu hóa bộ nhớ đệm (bản dịch)

Cache Inconsistency

• máy chủ cache gửi yêu cầu về x tới DB, và trước khi phản hồi x=42 từ DB tới được cache
  • bên ngoài cập nhật thành x=43, rồi thông qua invalidation chuyển x=43 cho cache
  • cache nhận x=43 và áp dụng
  • phản hồi x=42 đến muộn và được áp dụng
• vấn đề trên có thể được giải quyết bằng cách gắn version vào dữ liệu
• nhưng ngay cả khi có version, nếu xảy ra eviction đối với x=43 thì x=42 vẫn có thể được áp dụng

Polaris: dịch vụ đo lường Cache Inconsistency

• quy trình hoạt động
  • Polaris cũng nhận invalidation event
  • khi nhận event, nó sẽ truy vấn tất cả máy chủ cache để kiểm tra xem có đang giữ version cũ hay không
  • nếu cache đang giữ version cũ thì coi là inconsistency và đưa lại vào hàng đợi để có thể thử lại
    • vì invalidation event có thể đến máy chủ cache muộn
  • sau một khoảng thời gian nhất định (1 phút, 3 phút, 5 phút, v.v.), hệ thống gửi cảnh báo inconsistency
• metric
  • hiển thị metric cho biết trong M phút gần đây, các lượt ghi cache ở mức N nines có nhất quán hay không
  • nếu trong 5 phút đạt 10 nines, có nghĩa là trong 5 phút gần đây, 1 trên 10 tỷ lượt ghi cache là không nhất quán

Thư viện logging để debug Cache Inconsistency

• không thể logging mọi lượt ghi cache
  • vì bản chất cache là read-heavy workload, nhưng do "logging" mà có thể biến thành write-heavy workload
• vì vậy, họ tạo một thư viện để có thể logging cho time window ngay sau khi invalidation xảy ra
• cài thư viện này vào tất cả các dịch vụ tham gia vào quá trình invalidation
• khi inconsistency xảy ra, có thể dùng logging để truy vết toàn bộ quá trình dẫn tới sự cố dưới dạng timeline