Meta cache invalidation का उपयोग करते हुए cache consistency कैसे बनाए रखता है (अनुवाद)

Cache Inconsistency

• जब cache server db से x के लिए request भेजता है और db का x=42 response cache तक पहुँचने से पहले
  • बाहर से x=43 में update किया जाता है, और invalidation के ज़रिए x=43 cache को भेजा जाता है
  • cache x=43 प्राप्त करके उसे लागू कर देता है
  • x=42 response देर से पहुँचता है और फिर लागू हो जाता है
• ऊपर की समस्या को data के साथ version जोड़कर हल किया जा सकता है
• लेकिन version जोड़ने पर भी, अगर x=43 पर eviction हो जाए तो x=42 लागू हो सकता है

Polaris: Cache Inconsistency मापने की service

• काम करने की प्रक्रिया
  • Polaris भी invalidation event प्राप्त करता है
  • event मिलने पर वह सभी cache server को probe करके जाँचता है कि क्या उनके पास पुराना version है
  • अगर cache के पास पुराना version है, तो उसे inconsistency माना जाता है और retry हो सके इसलिए requeue किया जाता है
    • क्योंकि invalidation event cache server तक देर से पहुँच सकता है
  • एक निश्चित समय (1 मिनट, 3 मिनट, 5 मिनट आदि) बीत जाने पर inconsistency alert भेजा जाता है
• metric
  • यह metric दिखाता है कि पिछले M मिनटों में N nines के स्तर पर cache write consistent हैं या नहीं
  • अगर 5 मिनट के दौरान 10 nines है, तो इसका मतलब है कि पिछले 5 मिनट में 10 अरब में से 1 cache write inconsistent था

Cache Inconsistency को debug करने के लिए logging library

• सभी cache write को log करना संभव नहीं है
  • क्योंकि मूल रूप से cache एक read-heavy workload है, लेकिन "logging" की वजह से यह write-heavy workload बन जाएगा
• इसलिए invalidation होने के तुरंत बाद वाले time window के लिए logging की जा सके, ऐसी library बनाई गई
• invalidation में शामिल सभी services में इस library को embed किया गया
• logging के ज़रिए inconsistency होने पर, उसके होने तक की प्रक्रिया को timeline के रूप में पता लगाया जा सकता है