1.session共享問題

　　1. session復制

　　　　將session復制每一臺服務器上，缺點：每臺機器需要網絡通信，需要網絡開銷，有延遲；同時當服務器太多時出現瓶頸，每臺都需要備份session，出現內存不夠用的情況。早期的項目有些會這樣使用

　　2. session綁定

　　　　利用hash算法，將統一ip的用戶，分配到同一服務器上，如ngnix的ip_hash負載均衡算法，缺點，當用戶ip發生變化，或者服務器宕機時，用戶需要重新登陸

　　3. session服務器

　　　　將session信息記錄在一臺服務器上。缺點需要保證服務器的穩定性

　　　　實現：1.?修改sessionManager，如：shiro里

　　　　 org.apache.shiro.spring.web.ShiroFilterFactoryBean -> securityManager -> sessionManager -> sessionDAO
　　　2. 通過spring-redis-session包實現

2.分布式系統中的緩存

　　a. CDN：緩存一些靜態資源，距離用戶最近的網絡提供商提供。

　　b. 反向代理：緩存靜態資源，訪問網站數據中心前訪問。如ngnix

　　c. 本地緩存：緩存在本地的訪問內容，常用的本地緩存開源框架有EhCache。

　　d. 分布式緩存：緩存在分布式緩存集群中，常用的分布式緩存開源框架有redis，memcache。

3. 緩存更新/刪除

　　1. 再修改數據庫時，是更新還是刪除緩存，主要看需要更新緩存的代價大小，如果代價小，此時我們應該更傾向于更新緩存，以保證更高的緩存命中率。否則，刪除緩存

　　2. 刪除緩存 -> 更新數據庫，還是 更新數據庫 -> 刪除緩存 ？？？

　　　　刪除緩存 -> 更新數據庫，可能帶來的問題是在并發情況下，1線程刪除緩存，2線程執行讀取操作，緩存未命中重新查詢，再將緩存保存；然后1線程再執行更新數據庫。此時緩存中的便出現了臟數據。

　　　　更新數據庫 -> 刪除緩存，可能帶來的問題是 a. 更新數據庫成功后，更新緩存失敗;b. 1線程更新數據庫，2線程執行讀取操作，緩存未命中重新查詢完成，1線程更新數據庫成功，清除緩存，2線程此時再保存緩存（此概率極低）

　　3. 更新緩存的策略選取需要根據實際情況，個人理解，當查詢的并發量比較高時，優先選取 更新數據庫 -> 刪除緩存。當沒有什么高并發時，刪除緩存失敗的可能性會更大，此時選擇?刪除緩存 -> 更新數據庫。

　　4. 為優化 刪除緩存 -> 更新數據庫方案，有人給出了其他解決方法：https://blog.csdn.net/qq_27384769/article/details/79499373

　　5. 從上述可知，上面的倆種方案不能確保緩存的準確性，因此我們需要一些輔助促使

　　　　a. 每天定時更新緩存（在半夜）

　　　　b. 設置緩存失效時間（注意緩存雪崩）

4. 分布式事務

　　太復雜，待完善

5. 分布式鎖

轉載于:https://www.cnblogs.com/jaxlove-it/p/9883273.html

總結

以上是生活随笔為你收集整理的分布式问题总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。