分布式问题总结
1.session共享問題
1. session復(fù)制
將session復(fù)制每一臺服務(wù)器上，缺點：每臺機器需要網(wǎng)絡(luò)通信，需要網(wǎng)絡(luò)開銷，有延遲；同時當服務(wù)器太多時出現(xiàn)瓶頸，每臺都需要備份session，出現(xiàn)內(nèi)存不夠用的情況。早期的項目有些會這樣使用
2. session綁定
利用hash算法，將統(tǒng)一ip的用戶，分配到同一服務(wù)器上，如ngnix的ip_hash負載均衡算法，缺點，當用戶ip發(fā)生變化，或者服務(wù)器宕機時，用戶需要重新登陸
3. session服務(wù)器
將session信息記錄在一臺服務(wù)器上。缺點需要保證服務(wù)器的穩(wěn)定性
實現(xiàn)：1.?修改sessionManager，如：shiro里
org.apache.shiro.spring.web.ShiroFilterFactoryBean -> securityManager -> sessionManager -> sessionDAO2. 通過spring-redis-session包實現(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ù)庫時，是更新還是刪除緩存，主要看需要更新緩存的代價大小，如果代價小，此時我們應(yīng)該更傾向于更新緩存，以保證更高的緩存命中率。否則，刪除緩存
2. 刪除緩存 -> 更新數(shù)據(jù)庫，還是 更新數(shù)據(jù)庫 -> 刪除緩存 ？？？
刪除緩存 -> 更新數(shù)據(jù)庫，可能帶來的問題是在并發(fā)情況下，1線程刪除緩存，2線程執(zhí)行讀取操作，緩存未命中重新查詢，再將緩存保存；然后1線程再執(zhí)行更新數(shù)據(jù)庫。此時緩存中的便出現(xiàn)了臟數(shù)據(jù)。
更新數(shù)據(jù)庫 -> 刪除緩存，可能帶來的問題是 a. 更新數(shù)據(jù)庫成功后，更新緩存失敗;b. 1線程更新數(shù)據(jù)庫，2線程執(zhí)行讀取操作，緩存未命中重新查詢完成，1線程更新數(shù)據(jù)庫成功，清除緩存，2線程此時再保存緩存（此概率極低）
3. 更新緩存的策略選取需要根據(jù)實際情況，個人理解，當查詢的并發(fā)量比較高時，優(yōu)先選取 更新數(shù)據(jù)庫 -> 刪除緩存。當沒有什么高并發(fā)時，刪除緩存失敗的可能性會更大，此時選擇?刪除緩存 -> 更新數(shù)據(jù)庫。
4. 為優(yōu)化 刪除緩存 -> 更新數(shù)據(jù)庫方案，有人給出了其他解決方法：https://blog.csdn.net/qq_27384769/article/details/79499373
5. 從上述可知，上面的倆種方案不能確保緩存的準確性，因此我們需要一些輔助促使
a. 每天定時更新緩存（在半夜）
b. 設(shè)置緩存失效時間（注意緩存雪崩）
4. 分布式事務(wù)
太復(fù)雜，待完善
5. 分布式鎖
轉(zhuǎn)載于:https://www.cnblogs.com/jaxlove-it/p/9883273.html
總結(jié)
