วิธีที่ Meta รักษาความสอดคล้องของแคชขณะใช้การทำให้แคชเป็นโมฆะ (แปล)

Cache Inconsistency

• เซิร์ฟเวอร์แคชส่งคำขอสำหรับ x ไปยัง db และก่อนที่คำตอบ x=42 จาก db จะมาถึงแคช
  • มีการอัปเดตจากภายนอกเป็น x=43 และส่ง x=43 ไปยังแคชผ่าน invalidation
  • แคชรับ x=43 และนำไปใช้
  • จากนั้นคำตอบ x=42 มาถึงช้าและถูกนำไปใช้
• ปัญหาข้างต้นสามารถแก้ได้โดยแนบ version ให้กับข้อมูล
• แต่ถึงจะใส่ version แล้ว หากเกิด eviction ของ x=43 ก็ยังอาจทำให้ x=42 ถูกนำไปใช้ได้

Polaris: บริการวัด Cache Inconsistency

• กระบวนการทำงาน
  • Polaris ก็รับ invalidation event ด้วย
  • เมื่อได้รับ event จะไปเช็กทุก cache server ว่ายังถือ version ก่อนหน้าอยู่หรือไม่
  • ถ้าแคชยังมี version ก่อนหน้าอยู่ จะถือว่าเป็น inconsistency และนำกลับเข้า requeue เพื่อให้ลองใหม่ได้
    • เพราะ invalidation event อาจไปถึง cache server ช้าได้
  • เมื่อเวลาผ่านไปช่วงหนึ่ง (เช่น 1 นาที, 3 นาที, 5 นาที) จะส่งสัญญาณเตือน inconsistency
• metric
  • แสดง metric ว่า cache write ที่อยู่ในระดับ N nines ภายในช่วง M นาทีล่าสุดมีความ consistent หรือไม่
  • ถ้า 5 นาทีอยู่ที่ 10 nines จะตีความได้ว่าในช่วง 5 นาทีล่าสุด มี cache write 1 รายการจาก 10 พันล้านรายการที่เกิด inconsistency

ไลบรารีล็อกสำหรับดีบัก Cache Inconsistency

• ไม่สามารถล็อก cache write ทั้งหมดได้
  • เพราะโดยธรรมชาติแล้วแคชเป็น read-heavy workload แต่ถ้าเพิ่ม "logging" เข้าไป จะกลายเป็น write-heavy workload
• ดังนั้นจึงสร้างไลบรารีที่สามารถทำ logging ได้กับ time window ทันทีหลังเกิด invalidation
• ฝังไลบรารีนี้ไว้ในทุกบริการที่เกี่ยวข้องกับ invalidation
• เมื่อเกิด inconsistency ขึ้นผ่าน logging ก็สามารถย้อนดูเป็น timeline ได้ว่ามีกระบวนการอะไรเกิดขึ้นบ้างก่อนจะเกิดปัญหา