根據實際場景選擇方案，訪問資料庫的請求處理使用佇列並對同樣的請求做加鎖處理是比較穩妥的解決思路。這種問題業內有個名詞，叫雪崩效應，就是說叢集在正常負載的時候沒有問題，一旦其中幾臺伺服器崩了，伺服器過載的壓力壓到後端資料庫上面，就會導致整個叢集像雪崩一樣完全崩潰。讀多寫少的業務場景下：對於這種問題，快取擋在資料庫伺服器前面是必須的，即問題的解決方案之一，根據sql查詢的條件在快取伺服器層面做鎖處理，同樣的請求只放一個到後端資料庫上面，其它請求則阻塞等待資料更新。其次是擋住這些快取大批失效導致的峰值，不允許直接連線資料庫進行查詢，在快取伺服器向資料庫發起的請求處理上全部都要使用佇列，把峰值分攤到更長的時間段上避免後端資料庫受到衝擊。此外為了避免大批快取失效又重新生成的這些快取再次同時失效的問題，快取伺服器的資料快取時間需要去一個時間令牌分發的伺服器申請令牌，在基本快取時間的基礎上，再加上一個令牌快取時間，將峰值分攤到更長的時間上。這樣的處理可以避免資料庫負載被峰值請求沖垮。寫入比例更大的業務場景下：對資料更新頻繁且實時性要求較高的時候，比如直播室場景，搶購場景，快取失效時間很短。需要考慮業務切分，把同類業務路由到不同伺服器上面，獨立開來。儘可能把寫入負載分攤到單點叢集可以承擔的程度。技術上面可選的策略就和業務相關度很大了，類似直播室的場景，甚至不需要走到資料庫伺服器，業務都在快取上面週轉，持久化到資料庫的業務則走非同步扔佇列裡面慢慢處理。電商搶購這類必須要校驗的業務又不一樣，但是思路還是同樣的，秒殺業務瞬時進來的業務太大，那就加驗證碼加排隊，總之儘可能拖延提交訂單的時間，把瞬時負載分攤到系統可以接受的時間段內，資料庫層面依然還是加鎖與佇列，不過在佇列入隊上還需要做個鎖，一旦排隊長度超過商品總數的一個倍數（具體按需求過往訂單支付成功率計算），則加鎖將後續請求擋住不再入隊。還有很多寫入業務量非常極端的場景，類似LBS產品的地理位置更新，SNS產品的訊息推送，大致思路都是類似的，加鎖和佇列，資料庫層面儘可能選用寫入效能優良的nosql承擔這些持久化的需求。否則也儘可能減少索引的使用，比如把mysql當key-value資料庫用等形式，儘可能減少寫入的效能消耗提高。
根據實際場景選擇方案，訪問資料庫的請求處理使用佇列並對同樣的請求做加鎖處理是比較穩妥的解決思路。這種問題業內有個名詞，叫雪崩效應，就是說叢集在正常負載的時候沒有問題，一旦其中幾臺伺服器崩了，伺服器過載的壓力壓到後端資料庫上面，就會導致整個叢集像雪崩一樣完全崩潰。讀多寫少的業務場景下：對於這種問題，快取擋在資料庫伺服器前面是必須的，即問題的解決方案之一，根據sql查詢的條件在快取伺服器層面做鎖處理，同樣的請求只放一個到後端資料庫上面，其它請求則阻塞等待資料更新。其次是擋住這些快取大批失效導致的峰值，不允許直接連線資料庫進行查詢，在快取伺服器向資料庫發起的請求處理上全部都要使用佇列，把峰值分攤到更長的時間段上避免後端資料庫受到衝擊。此外為了避免大批快取失效又重新生成的這些快取再次同時失效的問題，快取伺服器的資料快取時間需要去一個時間令牌分發的伺服器申請令牌，在基本快取時間的基礎上，再加上一個令牌快取時間，將峰值分攤到更長的時間上。這樣的處理可以避免資料庫負載被峰值請求沖垮。寫入比例更大的業務場景下：對資料更新頻繁且實時性要求較高的時候，比如直播室場景，搶購場景，快取失效時間很短。需要考慮業務切分，把同類業務路由到不同伺服器上面，獨立開來。儘可能把寫入負載分攤到單點叢集可以承擔的程度。技術上面可選的策略就和業務相關度很大了，類似直播室的場景，甚至不需要走到資料庫伺服器，業務都在快取上面週轉，持久化到資料庫的業務則走非同步扔佇列裡面慢慢處理。電商搶購這類必須要校驗的業務又不一樣，但是思路還是同樣的，秒殺業務瞬時進來的業務太大，那就加驗證碼加排隊，總之儘可能拖延提交訂單的時間，把瞬時負載分攤到系統可以接受的時間段內，資料庫層面依然還是加鎖與佇列，不過在佇列入隊上還需要做個鎖，一旦排隊長度超過商品總數的一個倍數（具體按需求過往訂單支付成功率計算），則加鎖將後續請求擋住不再入隊。還有很多寫入業務量非常極端的場景，類似LBS產品的地理位置更新，SNS產品的訊息推送，大致思路都是類似的，加鎖和佇列，資料庫層面儘可能選用寫入效能優良的nosql承擔這些持久化的需求。否則也儘可能減少索引的使用，比如把mysql當key-value資料庫用等形式，儘可能減少寫入的效能消耗提高。