Memcached für Seiten, Redis für den Lock
Der Stack hatte schon zwei Speicher. Jeder hat jetzt eine Aufgabe. HTML liegt in Memcached. Queues, Sessions und Rebuild-Locks liegen in Redis.
CACHE_STORE zeigte auf Memcached. QUEUE_CONNECTION und SESSION_DRIVER zeigten auf Redis. Sie als austauschbar zu behandeln mischt Seiten-Blobs mit reservierten Jobs unter einer Eviction-Policy. Wenn Redis an maxmemory stößt, können eine News-Liste und ein Horizon-Lock zusammen verschwinden. Das ist Stampede und hängende Queue am selben Nachmittag.
Memcached ist schnell bei get/set von HTML und schlecht bei Locks. Ein GET mit Miss kann nicht versprechen, dass nur ein Aufrufer neu baut. Redis kann das. SET key NX EX 5 ist ein Lock mit TTL, und dieselbe Instanz betreibt bereits die Queue.
Der Rebuild-Pfad
Bei einem Miss holt der Worker den Redis-Lock. Bekommt er ihn, liest er MySQL, schreibt Memcached, löscht den Lock. Bekommt er ihn nicht, liefert er das vorherige HTML aus einem Zwillings-Key, der bis zum nächsten erfolgreichen Write lebt. Zwei Sekunden veraltetes HTML schlägt eine Herde Listen-Queries.
Cache-Keys tragen Ressource, Locale und ein Versionssegment. Ein Versionssprung wirft eine Gruppe ohne Wildcard-Delete. Öffentliche Listen halten Minuten. Alles, was aus einem Write folgt, stirbt bei diesem Write.
nginx davor
Anonyme Hits laufen zusätzlich durch einen kurzen Microcache in nginx. Der Key ist Scheme, Host, URI und Locale. Requests mit auth_token umgehen ihn, ein eingeloggter Nutzer bekommt also kein öffentliches Fragment.
Die Trennung ist jetzt die Regel dieser Site. Neue gecachte Reads bekommen Memcached für den Blob und Redis für den Lock. Redis ist kein zweiter Seiten-Store. Memcached ist kein Session-Store. Das ist das Update.