Daniel Allaire
716be304c5
Complète les 14 unités d'apprentissage au moule à 4 temps : Reverse-proxy, Courriel, Bases de données, Cache, Métriques & journaux, Supervision & impact, Virtualisation, Sécurité & durcissement, Infra as Code & idempotence, Liaisons (bindings, avec l'analogie NetScaler). Navigation complétée. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
64 lines
2.6 KiB
Markdown
64 lines
2.6 KiB
Markdown
# Cache
|
|
|
|
> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
|
|
|
|
---
|
|
|
|
## ① Le concept *(générique)*
|
|
|
|
Un **cache** garde en **mémoire** (rapide) des données coûteuses à recalculer ou à relire (disque,
|
|
base, réseau). Modèle **clé-valeur** : `SET clé valeur`, `GET clé`.
|
|
|
|
Comme la mémoire est limitée :
|
|
- **éviction** — quand c'est plein, on jette (souvent **LRU** : *Least Recently Used*) ;
|
|
- **TTL** — une valeur peut **expirer** après un délai.
|
|
|
|
Règle d'or : **le cache n'est PAS la source de vérité**. Il est **éphémère** — on doit pouvoir le
|
|
**perdre sans drame** (la vraie donnée est ailleurs). Le vider = plus lent un instant, jamais faux.
|
|
|
|
---
|
|
|
|
## ② Comment Set-OPS le fait
|
|
|
|
`serveur_redis` (nœud `data-sql`) fournit un cache réseau. Points notables :
|
|
- **authentification obligatoire** (`requirepass`, secret en voûte) — il est exposé sur le réseau
|
|
interne, donc on ne laisse jamais un cache ouvert ;
|
|
- **`maxmemory` + politique `allkeys-lru`** — borne la mémoire, évince en LRU ;
|
|
- Icinga a son **propre** Redis dédié (`icingadb-redis`) — un cache par besoin, pas un fourre-tout.
|
|
|
|
Conséquence directe : Redis est **Tier 3** (éphémère) — **on ne le sauvegarde pas**. C'est le
|
|
pendant parfait de l'unité *Sauvegardes* : on protège la donnée d'état, **pas** le cache.
|
|
|
|
---
|
|
|
|
## ③ Pourquoi c'est transférable
|
|
|
|
| Set-OPS | Équivalents ailleurs |
|
|
|---|---|
|
|
| Redis | Memcached · Valkey · KeyDB · caches cloud (ElastiCache…) |
|
|
| LRU + TTL | mécanismes **universels** d'éviction/expiration |
|
|
| cache éphémère ≠ source de vérité | principe valable partout |
|
|
|
|
Tu as appris **le cache clé-valeur, l'éviction LRU, le TTL, l'éphémère** — pas « Redis ».
|
|
|
|
---
|
|
|
|
## ④ À toi de jouer
|
|
|
|
1. **Écris/lis avec authentification** (sur data-sql-01) :
|
|
```bash
|
|
redis-cli -a "<mot de passe vault_redis>" SET essai:1 bonjour
|
|
redis-cli -a "<mot de passe vault_redis>" GET essai:1
|
|
```
|
|
2. **Teste le TTL** : `redis-cli -a … SET court 1 EX 5` puis `GET court` avant/après 5 s — il **expire**.
|
|
3. **Vois la borne** : `redis-cli -a … CONFIG GET maxmemory` et `… maxmemory-policy` (LRU).
|
|
4. **Casse & répare.** Interroge **sans** mot de passe : `redis-cli GET essai:1` → **`NOAUTH`**
|
|
(refusé). Puis vide le cache (`FLUSHALL`) : rien ne casse dans l'écosystème — la vraie donnée est
|
|
en base. Tu *sens* qu'un cache est **jetable**.
|
|
|
|
---
|
|
|
|
## Pour aller plus loin *(dépôt)*
|
|
- Rôle : `roles/serveur_redis`.
|
|
- Redis dédié d'Icinga : `roles/serveur_icinga` (`icingadb-redis`).
|
|
- Tiers de sauvegarde (Redis = Tier 3, non sauvegardé) : unité **Sauvegardes**.
|