Memcached-Cache

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

import { MemcachedCache, MemcachedCacheOptions } from 'actor-ts/cache';

const memcachedCacheOptions = MemcachedCacheOptions.create().withServers('memcached-1:11211,memcached-2:11211');
const cache = new MemcachedCache(
  memcachedCacheOptions,
);

Wann Memcached

Zwei Hauptgründe:

1. Bestehende Memcached-Infrastruktur — dein Team betreibt es bereits.
2. 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

type MemcachedCacheOptionsType = {
  servers?:   string;                // kommagetrennt, Default 'localhost:11211'
  username?:  string;
  password?:  string;
  keyPrefix?: string;                // serverseitig, auf jede Operation angewendet
  client?:    MemcachedClientLike;   // vorgefertigter memjs-Client
};

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.

Für alles, was eine Garantie trägt, ist es das nicht. InMemoryCache evictet Einträge ohne Garantie, bevor er ein Lock, einen Rate-Limit-Zähler oder einen Idempotency-Record anfasst; hier gibt es dazu kein Gegenstück, denn die Entscheidung fällt im Server und der Client wird nicht gefragt. Ein von setIfAbsent geschriebener Eintrag kann also mit dem größten Teil seiner TTL verschwinden — ein zweimal vergebenes Lock, ein zurückgesetztes Limit, ein Retry, der seinen Handler erneut ausführt — und nichts in der API meldet es. Dimensioniere die Memcached-Instanz für die Garantien, die sie hält, halte sie von einem Key-Raum fern, den Aufrufer aufzählen können, und siehe was Eviction schützt und was nicht für die Grundlage der Garantie. Das ist unabhängig von der Topologie-Gefahr weiter unten: die braucht einen Server, der dazu- oder wegkommt, diese hier nur Speicherdruck.

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).

Keine Persistenz

# 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.

Keine atomaren Multi-Key-Operationen

// 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 sind incr und setIfAbsent die einzigen atomaren Primitive des Frameworks.

Skalierung des Memcached-Clusters

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.

ADD ist pro Server atomar, nicht pro Cluster

servers: 'm1:11211,m2:11211';
// 'lock:job' hasht auf m1 — ADD ist dort atomar, also gewinnt ein Aufrufer
// m3 hinzufügen: der Key kann auf einen Server rehashen, der ihn nie sah
// → setIfAbsent('lock:job') gelingt ein zweites Mal, während der erste
//   Halter noch glaubt, das Lock zu besitzen

Memcached hat keine clusterweite Koordination. ADD ist atomar auf dem einen Server, auf den ein Key hasht — genau das macht setIfAbsent und acquireLock im eingeschwungenen Zustand korrekt: alle Konkurrenten um einen Key landen auf demselben Server. Eine Topologie-Änderung bricht diese Annahme: memjs rehasht den Keyspace, der Key kann auf einem anderen Server ohne Eintrag landen, und das Lock wird zweimal vergeben.

Clientseitig gibt es dagegen kein Mittel — das Framework kann einen Rehash nicht erkennen, ohne in memjs’ internen Hashring zu greifen, also genau in das Detail, das memjs zu verbergen da ist. Wer acquireLock auf Memcached nutzt, hält entweder die Serverliste über die Lebensdauer des Locks stabil, oder behandelt eine Doppelvergabe als möglich und sichert die Ressource mit einem Fencing-Token ab. Redis ist das bessere Backend zum Locken; Memcached-Locks bleiben besser auf Optimierungen beschränkt, bei denen ein doppelter Lauf Zeit kostet, nicht Korrektheit.

Wohin als Nächstes

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