（一）談談業務中使用分布式的場景
首先，需要了解系統為什么使用分布式。
隨着互聯網的發展，傳統單工程項目的很多性能瓶頸越發凸顯，性能瓶頸可以有幾個方面：
- 應用服務層：隨着用戶量的增加，並發量增加，單項目難以承受如此大的並發請求導致的性能瓶頸。
- 底層數據庫層：隨着業務的發展，數據庫壓力越來越大，導致的性能瓶頸。
場景1：應用系統集群的 Session 共享
應用系統集群最簡單的就是服務器集群，比如：Tomcat 集群。應用系統集群的時候，比較凸顯的問題是 Session 共享，Session 共享我們一是可以通過服務器插件來解決。另外一種也可以通過 Redis 等中間件實現。
場景2：應用系統的服務化拆分
服務化拆分，是目前非常火熱的一種方式。現在都在提微服務。通過對傳統項目進行服務化拆分，達到服務獨立解耦，單服務又可以橫向擴容。服務化拆分遇到的經典問題就是分布式事務問題。目前，比較常用的分布式事務解決方案有幾種：消息最終一致性、TCC 補償型事務等。
場景3：底層數據庫的壓力分攤
如果系統的性能壓力出現在數據庫，那我們就可以讀寫分離、分庫分表等方案進行解決。
（二）Session 分布式方案
基於 nfs(net filesystem) 的 Session 共享
將共享服務器目錄 mount 各服務器的本地 session 目錄，session 讀寫受共享服務器 io 限制，不能滿足高並發。
基於關系數據庫的 Session 共享
這種方案普遍使用。使用關系數據庫存儲 session 數據，對於 mysql 數據庫，建議使用 heap 引擎。這種方案性能取決於數據庫的性能，在高並發下容易造成表鎖（雖然可以采用行鎖的存儲引擎，性能會下降），並且需要自己實現 session 過期淘汰機制。
基於 Cookie 的 Session 共享
這種方案也在大型互聯網中普遍使用，將用戶的 session 加密序列化后以 cookie 的方式保存在網站根域名下（比如 taobao.com），當用戶訪問所有二級域名站點式，瀏覽器會傳遞所有匹配的根域名的 cookie 信息，這樣實現了用戶 cookie 化 session 的多服務共享。此方案能夠節省大量服務器資源，缺點是存儲的信息長度受到 http 協議限制；cookie 的信息還需要做加密解密；請求任何資源時都會將 cookie 附加到 http 頭上傳到服務器，占用了一定帶寬。
基於 Web 容器的 Session 機制
利用容器機制，通過配置即可實現。
基於 Zookeeper 的分布式 Session 存儲
基於 Redis/Memcached 的 Session 共享存儲
這些 key/value 非關系存儲有較高的性能，輕松達到 2000 左右的 qps，內置的過期機制正好滿足 session 的自動實效特性。
轉自：有夢想的咸魚