Τι είναι η κατανεμημένη cache και πώς χειρίζεστε τις αστοχίες της;

Question

IT Interview Practice · Accepted Answer

**Ένα distributed cache επιτρέπει σε πολλά instances να επαναχρησιμοποιούν δεδομένα μέσω δικτύου.** Αποφεύγει επαναλαμβανόμενη ακριβή εργασία, με σαφείς κανόνες επικαιρότητας και αποτυχίας.

Τρία backend instances διαβάζουν τον ίδιο κατάλογο. Τοπικό cache σημαίνει τρεις ξεχωριστές κόπιες. Κοινή υπηρεσία επιτρέπει σε ένα instance να φορτώσει τιμή που χρησιμοποιούν άλλα. Η υπηρεσία μπορεί και η ίδια να έχει πολλούς κόμβους.

## 1. Αποφασίστε τι αποθηκεύεται ασφαλώς

Ξεκινήστε από κόστος παραγωγής και ανεκτή παλαιότητα. Περιγραφή προϊόντος ίσως επιτρέπει καθυστέρηση, τελικός έλεγχος αποθέματος μπορεί να απαιτεί έγκυρη πηγή.

Το κλειδί πρέπει να ορίζει ολόκληρο αποτέλεσμα, μαζί με tenant, γλώσσα και σχετικά inputs. Αλλιώς ένα γρήγορο cache επιστρέφει ξένα δεδομένα. Η βάση παραμένει κύρια πηγή μόνιμων επιχειρησιακών εγγραφών, γιατί cached τιμές χάνονται.

## 2. Δείτε ανάγνωση πριν σχεδιάσετε ενημέρωση

Στο cache-aside η εφαρμογή κοιτά cache, διαβάζει βάση σε miss και αποθηκεύει αποτέλεσμα με χρόνο λήξης TTL.

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

Αυτό μειώνει επαναλαμβανόμενες αναγνώσεις της ίδιας τιμής. Προσθέτει όμως δικτυακή κλήση και εξάρτηση, οπότε η εξοικονόμηση πρέπει να υπερβαίνει το κόστος. Δείτε [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Ορίστε την ορατότητα ενημερώσεων

Για τον κατάλογο, πρακτική αρχή είναι commit στη βάση και μετά invalidation προϊόντος. Ο επόμενος αναγνώστης φορτώνει ξανά. Υπάρχει όμως race: κάποιος διαβάζει παλιά τιμή πριν το commit και τη βάζει στο cache μετά το invalidation.

Το TTL περιορίζει τη διάρκεια της νέας κόπιας, όχι εγγυημένα άμεση ανάγνωση τελευταίου write. Αν παλιά δικαιώματα, τιμές ή υπόλοιπα παραβιάζουν κανόνες, ελέγξτε έγκυρη πηγή ή σχεδιάστε version-aware ενημέρωση με ρητές εγγυήσεις. Η συνέπεια επιλέγεται από τη λειτουργία, όχι απλώς με Redis.

## 4. Μην αφήσετε ένα miss να γίνει outage

Όταν λήξει δημοφιλής τιμή, πολλοί καλούν ταυτόχρονα τη βάση: cache stampede. Πτώση cache μπορεί να το προκαλέσει σε πολλές τιμές.

- Συνδυάστε ταυτόχρονες φορτώσεις ίδιου κλειδιού και ορίστε αν ο συντονισμός καλύπτει process ή όλα τα instances.
- Διαφοροποιήστε λήξεις ώστε να μη συμπίπτουν. Απλώνει το refresh, δεν λύνει κάθε hot-key πρόβλημα.
- Δώστε προηγούμενη τιμή κατά την ανανέωση μόνο όταν επιτρέπεται επιχειρησιακά.
- Βάλτε σύντομα timeouts και περιορισμένο database fallback. Μερική απόρριψη μπορεί να είναι ασφαλέστερη από πλήρη υπερφόρτωση.

Δοκιμάστε σκόπιμα αυτές τις διαδρομές. Υψηλό hit rate σε κανονική λειτουργία δεν αποδεικνύει σωστή συμπεριφορά χωρίς cache.

## 5. Κλιμακώστε με βάση το πραγματικό όριο

Το sharding μοιράζει κλειδιά, η replication κρατά αντίγραφα για διαθεσιμότητα ή ανάγνωση. Λύνουν διαφορετικά προβλήματα. Το Redis Cluster χρησιμοποιεί hash slots, άρα νέοι κόμβοι δεν χωρίζουν αυτόματα ένα hot key. Δείτε [προδιαγραφή Redis Cluster](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Παρακολουθήστε hit rate, latency, timeouts, μνήμη, evictions και φόρτο βάσης. Eviction αφαιρεί τιμές για διαχείριση μνήμης και μπορεί να προηγηθεί του TTL. Μην θεωρείτε cache entry εγγυημένη μόνιμη αποθήκη επιχειρησιακών δεδομένων ή queued work.

Στον κατάλογο θα ξεκινούσα με σαφή κλειδιά cache-aside, πολιτική επικαιρότητας και προστατευμένο fallback. Θα πρόσθετα κόμβους μόνο για μετρημένο πρόβλημα που η διανομή λύνει. **Καλός σχεδιασμός εξηγεί παρούσες, απούσες και λανθασμένες τιμές.**

1. Αποφασίστε τι αποθηκεύεται ασφαλώς

2. Δείτε ανάγνωση πριν σχεδιάσετε ενημέρωση

3. Ορίστε την ορατότητα ενημερώσεων

4. Μην αφήσετε ένα miss να γίνει outage

5. Κλιμακώστε με βάση το πραγματικό όριο

Σχετικές ερωτήσεις