Distributed Session Consistency and Sharing Solutions

Distributed session consistency refers to the problem of sharing HTTP session data across a cluster of servers.

A session tracks the communication between client and server; the server issues a sessionId that the client stores in a cookie and sends with subsequent requests.

When a client accesses a different server in the cluster, the sessionId may not be found, causing the server to create a new session and breaking the intended shared state.

Common solutions include using cookies (though insecure), Nginx IP‑binding (no load balancing), synchronizing sessions via a database, using Tomcat’s built‑in session replication, replacing sessions with tokens, or employing Spring Session with Redis.

0x01 Database‑based session sharing: Typically MySQL with an in‑memory (Heap) table for faster reads/writes; effective but limited by database concurrency and requires custom eviction logic.

0x02 Cookie‑based session sharing: Encrypt and serialize the entire session into a cookie scoped to the root domain; avoids extra server resources but is constrained by HTTP header size limits and adds encryption overhead.

0x03 Memcache‑based session sharing: Uses Memcache’s key‑value store and expiration mechanism, which aligns well with session TTL, reducing database load and simplifying cleanup.

0x04 Redis‑based session sharing: Stores session data in Redis, leveraging its expiration policies; this is the most widely adopted approach in internet companies, with Spring providing dedicated distributed‑session components.