वितरित कॅश म्हणजे काय आणि तिचे बिघाड कसे हाताळता?

Question

IT Interview Practice · Accepted Answer

**Distributed cache अनेक अॅप instance ना नेटवर्कवरून डेटा पुन्हा वापरू देते.** खर्चिक काम टाळणे हा उद्देश असून ताजेपणा आणि failure चे स्पष्ट नियम हवेत.

तीन backend instance तोच product catalog वाचतात असे समजा. Process मधील cache असेल तर प्रत्येकाची वेगळी प्रत. Shared cache service मध्ये एका instance ने भरलेली किंमत इतर वापरतात. Cache सेवा स्वतःही अनेक node वापरू शकते.

## 1. काय सुरक्षित cache करायचे ते ठरवा

डेटा तयार करण्याचा खर्च आणि किती जुना चालेल यापासून सुरू करा. Product description ला थोडा विलंब चालेल; खरेदीच्या अंतिम stock check ला अधिकृत डेटा हवा असू शकतो.

Tenant, भाषा आणि इतर संबंधित input धरून पूर्ण निकाल ओळखणारी key द्या. नाहीतर जलद cache चुकीच्या ग्राहकाचा डेटा देईल. टिकाऊ business record साठी database अधिकृत ठेवा, कारण cache किंमत हरवू शकते.

## 2. Update आधी read path पाहा

सामान्य cache-aside मध्ये अॅप cache पाहते, miss झाल्यास database वाचते आणि TTL नावाच्या expiry सह निकाल ठेवते.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

अनेक request ना तीच किंमत हवी असल्यास वारंवार database वाचन कमी होते. पण network call आणि dependency वाढते, म्हणून टाळलेले काम या खर्चापेक्षा मोठे असेल तरच उपयोगी. [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/) पाहा.

## 3. Update कसे दिसेल ते ठरवा

Catalog साठी database commit नंतर cached product invalidate करणे व्यावहारिक सुरुवात आहे. पुढचा वाचक पुन्हा आणतो. पण race राहते: commit आधी जुनी किंमत घेतलेला वाचक invalidation नंतर ती cache मध्ये टाकू शकतो.

TTL नव्याने ठेवलेल्या प्रतीचे आयुष्य मर्यादित करतो; प्रत्येक वाचन लगेच नवीन लेखन पाहील याची हमी नाही. जुन्या permission, price किंवा balance ने नियम मोडत असतील तर अधिकृत डेटा तपासा किंवा आवृत्ती-जाणणारा update स्पष्ट हमीसह बनवा. Redis वापरल्याने सुटेल असे न मानता business operation नुसार consistency निवडा.

## 4. Cache miss चे outage होऊ देऊ नका

लोकप्रिय entry expire झाल्यास अनेक वाचक database ला एकत्र जातात. हे cache stampede. Cache बंद पडल्यास अनेक entry साठी असे होते.

- त्याच key चे concurrent load एकत्र करा, म्हणजे कमी जण पुन्हा भरतील; समन्वय एका process पुरता की सर्व instance चा ते ठरवा.
- Expiry वेळा वेगळ्या ठेवा, म्हणजे अनेक entry एकत्र संपणार नाहीत. Refresh पसरतो पण सर्व hot-key प्रश्न सुटत नाहीत.
- व्यवसायाला जुना डेटा चालत असेल तरच refresh दरम्यान आधीची किंमत द्या.
- Cache timeout कमी ठेवा आणि database fallback traffic मर्यादित करा. Database भरडून सर्व request अयशस्वी करण्यापेक्षा काही काम नाकारणे सुरक्षित असेल.

हे मार्ग जाणीवपूर्वक तपासा. सामान्य स्थितीतील चांगला hit rate cache गायब झाल्यावरचे वर्तन सांगत नाही.

## 5. खऱ्या अडथळ्यानुसार scale करा

Sharding key अनेक cache node मध्ये विभागते; replication उपलब्धता किंवा read साठी प्रत ठेवते. प्रश्न वेगळे आहेत. Redis Cluster hash slot वापरतो, म्हणून node वाढवल्याने एका hot key चे काम आपोआप विभागत नाही. [Redis Cluster specification](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/) पाहा.

Hit rate, latency, timeout, memory, eviction आणि database भार पाहा. Eviction म्हणजे memory साठी किंमत काढणे; TTL आधीही होऊ शकते. Cache entry ला business data किंवा queue कामासाठी खात्रीची टिकाऊ storage समजू नका.

Catalog साठी स्पष्ट key असलेले cache-aside, freshness policy आणि संरक्षित fallback ने सुरू करेन. Distribution खरोखर सोडवू शकेल असा capacity प्रश्न मोजल्यावरच अधिक node जोडेन. **चांगले cache design किंमत असताना तसेच नसताना किंवा चुकीची असताना काय होईल ते सांगते.**

1. काय सुरक्षित cache करायचे ते ठरवा

2. Update आधी read path पाहा

3. Update कसे दिसेल ते ठरवा

4. Cache miss चे outage होऊ देऊ नका

5. खऱ्या अडथळ्यानुसार scale करा

संबंधित प्रश्न