Distributed cache શું છે અને તેની નિષ્ફળતા કેવી રીતે સંભાળશો?

Question

IT Interview Practice · Accepted Answer

**Distributed cache ઘણા application instancesને network મારફત data ફરી વાપરવા દે છે.** તેનો હેતુ ખર્ચાળ કામ વારંવાર કરવાનું ટાળવાનો છે, સાથે freshness અને failure માટે સ્પષ્ટ નિયમો રાખવાના છે.

એક જ product catalog વાંચતા ત્રણ backend instances ધારો. દરેક processની પોતાની cache હોય તો દરેક પોતાની copy રાખે. Shared cache service હોય તો એક instance value મૂકે અને બીજા તેનો ઉપયોગ કરે. Cache service પોતે પણ ઘણા nodes ધરાવી શકે.

## 1. શું સુરક્ષિત રીતે cache કરી શકાય તે નક્કી કરો

Data બનાવવાનો ખર્ચ અને કેટલો જૂનો data સ્વીકાર્ય છે ત્યાંથી શરૂ કરો. Product description થોડો વિલંબ સહન કરી શકે; ખરીદીની અંતિમ stock checkને authoritative data જોઈએ.

Tenant, language અને અન્ય સંબંધિત inputs સહિત આખું result ઓળખતી key બનાવો. નહીં તો ઝડપી cache ખોટા customerનો data આપી શકે. Durable business records માટે databaseને authority રાખો, કારણ કે cached values ગાયબ થઈ શકે.

## 2. Updates ડિઝાઇન કરતાં પહેલાં read path જુઓ

સામાન્ય રીત cache-aside છે: application પહેલાં cache જુએ, miss થાય તો database વાંચે અને resultને TTL કહેવાતા expiry time સાથે રાખે.

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

ઘણા requestsને સમાન value જોઈએ ત્યારે repeated database reads ઘટે છે. પરંતુ network calls અને બીજી dependency ઉમેરાય છે; બચતું કામ આ ખર્ચ કરતાં વધારે હોય ત્યારે જ cache ઉપયોગી છે. [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/) જુઓ.

## 3. Updates ક્યારે દેખાશે તે નક્કી કરો

Catalog માટે વ્યવહારુ શરૂઆત database update commit કરીને cached product invalidate કરવાની છે. આગળનો reader ફરી લોડ કરે. પરંતુ race હજી શક્ય છે: reader commit પહેલાં જૂની value વાંચે અને invalidation પછી cacheમાં મૂકે.

TTL એ નવી cached copy કેટલો સમય ટકે તે મર્યાદિત કરે છે; દરેક read તરત latest write જુએ તેની ખાતરી આપતું નથી. જૂની permissions, prices કે balances operationના નિયમો તોડે તો authoritative data સામે તપાસો અથવા સ્પષ્ટ ગેરંટી સાથે version-aware update mechanism બનાવો. Redis બધું ઉકેલે છે એમ માનવાને બદલે business operation પ્રમાણે consistency પસંદ કરો.

## 4. Cache missને outage બનતો અટકાવો

લોકપ્રિય entry expire થાય તો ઘણા callers એકસાથે database વાંચી શકે. તેને cache stampede કહે છે. Cache outage ઘણા entries માટે એ જ સમસ્યા ઊભી કરી શકે.

- સમાન keyના concurrent loads જોડો જેથી ઓછા callers તેને ફરી બનાવે; coordination એક processમાં છે કે બધા instancesમાં તે સ્પષ્ટ કરો.
- Expiry timesમાં ફેરફાર રાખો જેથી ઘણી entries સાથે expire ન થાય. તે refresh work ફેલાવે છે, પરંતુ દરેક hot-key સમસ્યા ઉકેલતું નથી.
- Refresh દરમિયાન જૂની cached value ત્યારે જ આપો જ્યારે business stale data મંજૂર કરે.
- ટૂંકા cache timeouts રાખો અને database fallback traffic મર્યાદિત કરો. કેટલાક requests નકારવા, આખો database ભરાઈને દરેક request નિષ્ફળ જવા કરતાં સુરક્ષિત હોઈ શકે.

આ paths જાણીજોઈને તપાસો. Normal operationમાં ઊંચો hit rate cache ગાયબ થાય ત્યારે service કેવી ચાલે તે વિશે બહુ ઓછું કહે છે.

## 5. વાસ્તવિક bottleneck પ્રમાણે scale કરો

Sharding keysને cache nodesમાં વહેંચે છે; replication availability અથવા reads માટે copies રાખે છે. તે જુદી સમસ્યાઓ ઉકેલે છે. Redis Cluster placement માટે hash slots વાપરે છે, એટલે nodes વધારવાથી એક hot keyનું કામ આપમેળે વહેંચાતું નથી. [Redis Cluster specification](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/) જુઓ.

Hit rate, request latency, timeouts, memory, evictions અને database સુધી આવતો load જુઓ. Eviction એટલે memory સંભાળવા cacheએ value દૂર કરી; તે TTL પહેલાં પણ થઈ શકે. Cache entryને business data કે queued work માટે guaranteed durable storage ન માનો.

Catalog માટે હું સ્પષ્ટ keysવાળા cache-aside data, freshness policy અને protected fallbackથી શરૂઆત કરું. માપણ distributionથી ઉકેલી શકાય એવી capacity સમસ્યા બતાવે ત્યારે જ વધુ cache nodes ઉમેરું. **સારી cache design value હાજર હોય ત્યારે તથા ગેરહાજર કે ખોટી હોય ત્યારે શું થાય છે તે સમજાવે છે.**

1. શું સુરક્ષિત રીતે cache કરી શકાય તે નક્કી કરો

2. Updates ડિઝાઇન કરતાં પહેલાં read path જુઓ

3. Updates ક્યારે દેખાશે તે નક્કી કરો

4. Cache missને outage બનતો અટકાવો

5. વાસ્તવિક bottleneck પ્રમાણે scale કરો

સંબંધિત પ્રશ્નો