1.session共享問題

　　1. session復(fù)制

　　　　將session復(fù)制每一臺(tái)服務(wù)器上，缺點(diǎn)：每臺(tái)機(jī)器需要網(wǎng)絡(luò)通信，需要網(wǎng)絡(luò)開銷，有延遲；同時(shí)當(dāng)服務(wù)器太多時(shí)出現(xiàn)瓶頸，每臺(tái)都需要備份session，出現(xiàn)內(nèi)存不夠用的情況。早期的項(xiàng)目有些會(huì)這樣使用

　　2. session綁定

　　　　利用hash算法，將統(tǒng)一ip的用戶，分配到同一服務(wù)器上，如ngnix的ip_hash負(fù)載均衡算法，缺點(diǎn)，當(dāng)用戶ip發(fā)生變化，或者服務(wù)器宕機(jī)時(shí)，用戶需要重新登陸

　　3. session服務(wù)器

　　　　將session信息記錄在一臺(tái)服務(wù)器上。缺點(diǎn)需要保證服務(wù)器的穩(wěn)定性

　　　　實(shí)現(xiàn)：1.?修改sessionManager，如：shiro里

　　　　 org.apache.shiro.spring.web.ShiroFilterFactoryBean -> securityManager -> sessionManager -> sessionDAO
　　　2. 通過spring-redis-session包實(shí)現(xiàn)

2.分布式系統(tǒng)中的緩存

　　a. CDN：緩存一些靜態(tài)資源，距離用戶最近的網(wǎng)絡(luò)提供商提供。

　　b. 反向代理：緩存靜態(tài)資源，訪問網(wǎng)站數(shù)據(jù)中心前訪問。如ngnix

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

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

3. 緩存更新/刪除

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

　　2. 刪除緩存 -> 更新數(shù)據(jù)庫，還是 更新數(shù)據(jù)庫 -> 刪除緩存 ？？？

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

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

　　3. 更新緩存的策略選取需要根據(jù)實(shí)際情況，個(gè)人理解，當(dāng)查詢的并發(fā)量比較高時(shí)，優(yōu)先選取 更新數(shù)據(jù)庫 -> 刪除緩存。當(dāng)沒有什么高并發(fā)時(shí)，刪除緩存失敗的可能性會(huì)更大，此時(shí)選擇?刪除緩存 -> 更新數(shù)據(jù)庫。

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

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

　　　　a. 每天定時(shí)更新緩存（在半夜）

　　　　b. 設(shè)置緩存失效時(shí)間（注意緩存雪崩）

4. 分布式事務(wù)

　　太復(fù)雜，待完善

5. 分布式鎖

轉(zhuǎn)載于:https://www.cnblogs.com/jaxlove-it/p/9883273.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。