從單體到分散式，必須解決的四個問題
- 2020 年 5 月 6 日
- 筆記
一般來說，為了應對高並發和高可用，應用伺服器都會由單體向分散式演變。而從單體到分散式，通常會遇到四個問題必須要去解決。
一，session共享
首先第一個要解決的就是sesison共享的問題，如下圖。
通常有兩種解決方案，第1種是配置nginx的負載集群策略為ip_hash，第2種是將session存儲到其它地方，一般推薦放到redis中。
第1種方案適合於臨時解決或者是為了兼容歷史項目，但是從應用伺服器無狀態的角度考慮，推薦把用戶會話session放到redis，如下圖。
二，本地快取
如果使用本地快取，當從單體遷移到集群後，就會面臨快取同步的問題，如下圖。
最佳實踐是上分散式快取，既解決了快取同步的問題，也釋放了應用伺服器的記憶體資源，如下圖。
三，文件服務
應用伺服器在上集群之前，文件通常會放在本地，或者單獨的文件伺服器上，因為文件服務需要佔用大量的硬碟空間，以上兩種方案都無法很好的解決硬碟擴容的問題，最佳實踐是放到雲存儲上，比如阿里雲的OSS，或者騰訊雲的COS上，這樣可以做到按需擴容，如下圖。
四，分散式環境下執行緒同步問題
在單機環境下，使用lock就可以解決執行緒同步的問題，一旦上了集群之後，lock就不管用了，這時需要上分散式鎖，分散式鎖的解決方案也有很多，我這裡推薦使用redis的setnx，需要注意的是，如果redis是集群部署的，需要考慮這種情形：假設我們在redis的主節點上添加了一把分散式鎖，不幸的是主節點掛掉了，而且主節點上的鎖還沒有同步到從節點上，如果此時有客戶端來請求獲得同一把鎖，那麼它將順利地獲得鎖，之前那把鎖會被無情地忽視掉，這就是分散式鎖在Redis集群中遇到的麻煩。
為了解決這個問題，Redis的作者提出了Redlock的演算法來解決這個問題，推薦大家直接使用這個開源項目：//github.com/samcook/RedLock.net
那麼，順利解決了以上四個問題之後，我們的系統架構就演變成以下這個樣子。
歡迎大家掃描下方二維碼獲取我的最新原創文章：
