Memcached-Cache

MemcachedCache ist die Memcached-gestützte Cache- Implementierung. Verteilter Cache über Pods, geteilt über Prozesse hinweg.

import { MemcachedCache } from 'actor-ts';

const cache = new MemcachedCache({
  servers: ['memcached-1:11211', 'memcached-2:11211'],
});

Wann Memcached

Zwei Hauptgründe:

Bestehende Memcached-Infrastruktur — dein Team betreibt es bereits.
Reiner Cache-Anwendungsfall — du brauchst Redis’ Extra- Features nicht (Persistenz, Pub/Sub, Scripting, Sorted Sets).

Memcached ist einfacher als Redis — weniger Features, geringerer operativer Footprint, geringerer Speicher-Overhead. Für pures Key-Value-Caching mit TTLs reicht das voll.

Konfiguration

interface MemcachedCacheSettings {
  servers:      string[];               // 'host:port'
  username?:    string;
  password?:    string;
  timeoutMs?:   number;
  retries?:     number;
}

memjs (der zugrunde liegende Client) unterstützt SASL-Auth über username/password. Mehrere Server werden über Hashing verteilt.

Peer-Dependency

npm install memjs
# oder: bun add memjs

Was funktioniert

Cache-Methode	Memcached-Implementierung
`get`/`set`/`delete`	Direkte Memcached-Befehle.
`incr`	Kombination aus Memcached `INCR`/`ADD`.
`setIfAbsent`	Memcached `ADD` (atomar).
`mget`/`mset`	Parallele Single-Key-Operationen.

mget/mset sind auf Memcached nicht Single-Round-Trip (keine Multi-Key-Befehle). Das Framework parallelisiert die einzelnen Operationen.

Memcached vs. Redis

Aspekt	Memcached	Redis
Speicher-Overhead pro Eintrag	Niedriger	Höher
Multi-Key-Operationen	Langsamer (parallele Single-Key)	Schneller (MGET, MSET)
Persistenz	Keine	RDB / AOF verfügbar
Pub/Sub	Nein	Ja
Datentypen	Nur Strings	Strings, Listen, Sets, Hashes, Sorted Sets
Cluster-Support	Clientseitiges Hashing	Eingebautes Clustering
Replikation	Keine (oder über Sidecars)	Eingebaute Replikation

Für puren Cache: beides funktioniert. Redis gewinnt bei fast allem anderen, was das Framework wollen könnte. Memcached gewinnt bei minimalem operativen Footprint, wenn Caching der einzige Bedarf ist.

Eviction

// Memcached konfiguriert mit --memory-limit=2048 (MB)
// → LRU-Eviction, sobald voll

Memcacheds Eviction ist LRU, konfiguriert auf der Memcached- Serverebene (nicht vom Cache-Client). Keine clientseitige Eviction-Policy.

Für einen Cache fester Größe ist das okay — Memcached wirft alte Einträge raus, um Platz zu schaffen.

Connection-Pooling

memjs hält seinen eigenen Connection-Pool; das Framework verwaltet ihn nicht direkt. Tune über memjs-Optionen, falls nötig (meist sind die Defaults okay).

# systemctl restart memcached
# → ganzer Cache weg

Memcached hat null Persistenz. Behandle Caches als “neu-aus-Quelle-bauen” — speichere nie etwas, das du nicht neu berechnen kannst.

// Zwei Operationen: A lesen, B basierend auf A setzen → Race möglich

Memcached hat keine Transaktionen / atomaren Multi-Key- Operationen. Für “atomarer Counter + Check”-Muster ist das incr des Frameworks das einzige atomare Primitiv.

servers: ['m1:11211', 'm2:11211'];
// m3 hinzufügen: Keys rebalancieren über Consistent-Hashing — einige Cache-Misses während des Rebalances

Memcached-Skalierung braucht clientseitiges Bewusstsein für Consistent-Hashing. memjs erledigt das; rechne mit einem kurzen Cache-Miss-Spike, wenn sich die Cluster-Topologie ändert.

Wohin als Nächstes

Cache-Übersicht — das große Bild.
In-Memory-Cache — für Single-Pod.
Redis-Cache — mehr Features.