Apache 2.0 · Open Source
Keycloak sur Redis. Sans la taxe JGroups.
Locke is a drop-in Keycloak distribution that runs Keycloak's caching on Redis instead of an embedded JGroups cluster. Same admin console, same base de données, one switch (KC_CACHE=redis).
What is Locke
Keycloak standard, avec un backend de cache Redis.
Locke is the upstream Keycloak codebase plus one thing: a Redis cache backend behind a single switch. Same SPIs, same admin console, same base de données schema. Flip it back and you have ordinary Keycloak.
Drop-in
Basculez KC_CACHE=infinispan|redis au démarrage. Aucun changement de code, aucune migration.
Apache 2.0
Entièrement open source : Keycloak standard plus un backend de cache Redis, rien de verrouillé.
Apportez votre propre Redis
Fonctionne avec n'importe quel Redis géré. Colocalisé ou externe performent de la même manière.
Pas de JGroups à exploiter
Pas de découverte de cluster, de gestion split-brain ou de transfert d'état. Redis coordonne.
The benchmark
Même débit. Comportement en cas de panne considérablement meilleur.
Un cluster de production à 3 instances, face à face. Le débit est égal. La différence apparaît au moment où un nœud meurt.
| Load (logins/sec) | Stock / Infinispan | Locke / Redis | Parity |
|---|---|---|---|
| 80 | 274 req/s | 274 req/s | 100% |
| 160 | 548 req/s | 548 req/s | 100% |
| 250 | 856 req/s | 856 req/s | 100% |
latence p99 de connexion lorsqu'un nœud est perdu (plus bas est mieux)
Les barres utilisent une échelle compressée pour garder Locke visible ; l'écart est d'environ 15-34x. Lorsqu'un nœud Infinispan meurt, le cluster se bloque sur un rééquilibrage JGroups et un transfert d'état. Locke continue de servir depuis Redis.
Cluster à 3 instances, Keycloak 26.6.1, start --optimized, flux keycloak-benchmark Gatling AuthorizationCode. Méthodologie complète dans le rapport.
Why it matters
Conçu pour les opérateurs de permanence.
Resilience
A lost node is a sub-second blip, not a 31-second JGroups rebalance stall that hangs authentification mid-incident.
mises à niveau
Across an Infinispan-version boundary the recommended Keycloak path is a brief planned restart; Locke can do that same mise à niveau as a rolling update because there is no JGroups version handshake. Keycloak doesn't guarantee no-downtime minor mises à niveau in general, so this is one fewer constraint, not a blanket promise.
Operations
Pointez Keycloak vers le Redis géré que vous exécutez et surveillez déjà. Pas de découverte JGroups, pas de transfert d'état, un système distribué de moins à exploiter.
Quick start
Une image. Un switch.
Exécutez l'image Locke en mode production et pointez-la vers votre Redis.
docker run ghcr.io/sky-cloak/locke:latest start --optimized
# Basculez le backend de cache vers Redis
KC_CACHE=redis
KC_CACHE_REDIS_URL=redis://your-redis:6379
The honest part
An honest trade. Moving local caches to Redis adds a few milliseconds of read latency at moderate load (both stay under 170ms p99 to 250 logins/sec). And Redis does not raise Keycloak's realm-count ceiling. That limit is base de données-bound, not cache-bound. We benchmark these things and say so.
Exécutez Keycloak sur le cache que vous exploitez déjà.
Open source, Apache 2.0, benchmark en mode production.