水平擴展應用伺服器時，用戶請求可能被負載均衡器分發到不同節點。若 Session 僅存在本地記憶體，換節點即掉線。核心需求：透明、高效、高可用、資料不丟失。
| 方案 | 架構 | 優點 | 缺點 | 適用場景 |
|---|---|---|---|---|
| 1. 客戶端 Cookie 加密 | Stateless | 無伺服器狀態、擴展性最強、無同步開銷 | 資料量限 4KB、敏感資料風險、頻寬增加 | 僅存 User ID/Token 的輕量應用 |
| 2. 應用伺服器原生複寫 (Tomcat/JBoss/WAS) | DeltaManager / Buddy Replication | 配置簡單、透明無侵入 | 節點增加導致廣播風暴、序列化開銷大、記憶體壓力 | 小規模叢集（<5 節點）、Session 輕量 |
| 3. 資料庫持久化 | 共享 DB | 資料落地、單點可 HA、跨機房 | 每請求多一次 DB IO、需改造程式、DB 成單點（需主從） | 強一致性要求、Session 較大、已有 DB 基礎設施 |
| 4. 共享儲存 (NFS/NAS/SAN) | 共享檔案系統 | 資料落地、透明 | 序列化/反序列化開銷、NFS 單點（需 RAID/雙控）、延遲較高 | 舊系統遷移、不想引入新中間件 |
| 5. Memcached / Redis | 分散式記憶體 KV | 高效能、原生 TTL、支援叢集分片 | 需改造程式、序列化開銷、Memcached 節點掛掉資料全丟（Redis 可 AOF/RDB 持久化） | 高併發、大流量、微服務架構首選 |
| 6. Terracotta (現 Ehcache/BigMemory) | JVM 級叢集、細粒度變更同步 | 無需序列化、程式碼零侵入、原生 HA、支援大堆外記憶體 | 學習曲線陡、商業版收費、HA 同步效能需壓測驗證 | Java 單體應用平滑叢集化、大 Session、強一致性 |
階段 1（單機/雙機） → Tomcat 原生複寫 / Sticky Session
階段 2（3-10 節點） → Redis Cluster（Session 存 JSON，TTL 30min）
階段 3（大規模/多機房） → Redis + 本地快取（Caffeine）雙層，或 Terracotta BigMemory
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
</dependency>
# application.yml
spring:
session:
store-type: redis
redis:
namespace: "myapp:session"
flush-mode: on_save
redis:
cluster:
nodes: "10.0.1.1:6379,10.0.1.2:6379,10.0.1.3:6379"
僅需加依賴與配置，原有 HttpSession 代碼完全不變，自動實現分散式 Session。
沒有銀彈，只有貿易。選型前先量測：Session 平均大小、峰值 QPS、容忍延遲、團隊技能圖譜。最簡單能滿足 SLA 的方案，就是最好的方案。
