1、高併發之擴容思路
- 垂直擴容（縱向擴充套件）：提高系統部件能力。
增加記憶體 - 水平擴容（橫向擴充套件）：增加更多系統成員來實現。
增加伺服器，應關注對共享資源的訪問，是否有足夠的緩衝區以承載起負荷。
資料庫擴容
- 讀操作擴充套件：memcache、redis、CDN等快取
- 寫操作擴充套件：Cassandra、Hbase等
2、高併發之快取
快取特徵：
- 命中率：命中數/(命中數+沒有命中數)
- 最大元素（空間）
- 清空策略：FIFO、LFU（最少使用策略）、LRU（最近最少使用策略）、過期時間、隨機等。
本地快取：程式設計實現（成員變數、區域性變數、靜態變數）、Guava Cache
分散式快取：Memcache、Redis
Guava Cache
Memcache
Redis
- 資料的永續性。
- 資料備份。
- 豐富的資料型別。
高併發場景下快取常見問題： 原文出處：快取在高併發場景下的常見問題
- 快取一致性
當資料時效性要求很高時，需要保證快取中的資料與資料庫中的保持一致，而且需要保證快取節點和副本中的資料也保持一致，不能出現差異現象。這就比較依賴快取的過期和更新策略。一般會在資料發生更改的時，主動更新快取中的資料或者移除對應的快取。
- 快取併發問題
快取過期後將嘗試從後端資料庫獲取資料，這是一個看似合理的流程。但是，在高併發場景下，有可能多個請求併發的去從資料庫獲取資料，對後端資料庫造成極大的衝擊，甚至導致“雪崩”現象。此外，當某個快取key在被更新時，同時也可能被大量請求在獲取，這也會導致一致性的問題。那如何避免類似問題呢？我們會想到類似“鎖”的機制，在快取更新或者過期的情況下，先嚐試獲取到鎖，當更新或者從資料庫獲取完成後再釋放鎖，其他的請求只需要犧牲一定的等待時間，即可直接從快取中繼續獲取資料。 redis分散式鎖
- 快取穿透問題
快取穿透在有些地方也稱為“擊穿”。很多朋友對快取穿透的理解是：由於快取故障或者快取過期導致大量請求穿透到後端資料庫伺服器，從而對資料庫造成巨大沖擊。
這其實是一種誤解。真正的快取穿透應該是這樣的：
在高併發場景下，如果某一個key被高併發訪問，沒有被命中，出於對容錯性考慮，會嘗試去從後端資料庫中獲取，從而導致了大量請求達到資料庫，而當該key對應的資料本身就是空的情況下，這就導致資料庫中併發的去執行了很多不必要的查詢操作，從而導致巨大沖擊和壓力。
可以通過下面的幾種常用方式來避免快取傳統問題：
1）快取空物件 對查詢結果為空的物件也進行快取，如果是集合，可以快取一個空的集合（非null），如果是快取單個物件，可以通過欄位標識來區分。這樣避免請求穿透到後端資料庫。同時，也需要保證快取資料的時效性。這種方式實現起來成本較低，比較適合命中不高，但可能被頻繁更新的資料。
2）單獨過濾處理 對所有可能對應資料為空的key進行統一的存放，並在請求前做攔截，這樣避免請求穿透到後端資料庫。這種方式實現起來相對複雜，比較適合命中不高，但是更新不頻繁的資料。
快取的顛簸問題
有些地方可能被成為“快取抖動”，可以看做是一種比“雪崩”更輕微的故障，但是也會在一段時間內對系統造成衝擊和效能影響。一般是由於快取節點故障導致。業內推薦的做法是通過一致性Hash演算法來解決。
- 快取的雪崩現象
快取雪崩就是指由於快取的原因，導致大量請求到達後端資料庫，從而導致資料庫崩潰，整個系統崩潰，發生災難。導致這種現象的原因有很多種，上面提到的“快取併發”，“快取穿透”，“快取顛簸”等問題，其實都可能會導致快取雪崩現象發生。這些問題也可能會被惡意攻擊者所利用。還有一種情況，例如某個時間點內，系統預載入的快取週期性集中失效了，也可能會導致雪崩。為了避免這種週期性失效，可以通過設定不同的過期時間，來錯開快取過期，從而避免快取集中失效。
從應用架構角度，我們可以通過限流、降級、熔斷等手段來降低影響，也可以通過多級快取來避免這種災難。
此外，從整個研發體系流程的角度，應該加強壓力測試，儘量模擬真實場景，儘早的暴露問題從而防範。
快取無底洞現象
該問題由 facebook 的工作人員提出的， facebook 在 2010 年左右，memcached 節點就已經達3000 個，快取數千 G 內容。
他們發現了一個問題---memcached 連線頻率，效率下降了，於是加 memcached 節點，
新增了後，發現因為連線頻率導致的問題，仍然存在，並沒有好轉，稱之為”無底洞現象”。
主要可以從如下幾個方面避免和優化：
資料分佈方式 有些業務資料可能適合Hash分佈，而有些業務適合採用範圍分佈，這樣能夠從一定程度避免網路IO的開銷。
IO優化 可以充分利用連線池，NIO等技術來儘可能降低連線開銷，增強併發連線能力。
資料訪問方式 一次性獲取大的資料集，會比分多次去獲取小資料集的網路IO開銷更小。
3、高併發之訊息佇列
特性
- 業務無關：只做訊息分發。
- FIFO：先投遞先到達。
- 容災：節點的動態增刪和訊息的持久化。
- 效能：吞吐量提升，系統內部通訊效率的提高。
優點
- 業務解耦
- 最終一致性
- 廣播
- 錯峰與流控
參考：
大型網站架構之分散式訊息佇列
訊息佇列及常見訊息佇列介紹
4、應用拆分
基本原則：
- 業務優先
- 迴圈漸進
- 兼顧技術：重構、分層。
- 可靠測試
思考：
- 應用之間通訊：RPC（dubbo等）、訊息佇列。
- 應用資料庫設計：每個應用都有自己獨立的資料庫。
- 避免事務操作跨應用。
5、應用限流
限制某段程式碼執行速率
常用演算法：
- 計數器法
- 滑動視窗
- 漏桶演算法
- 令牌桶演算法
6、服務降級與熔斷
服務降級分類：
- 自動降級：超時、失敗次數、故障、限流。
- 人工降級：秒殺、雙十一大促。
降級與熔斷
- 區別：觸發原因、管理目標層次、實現方式
- 共性：目的、最終表現、粒度、自治
Hystrix
- 通過第三方客戶端訪問（通常是通過網路）依賴服務出現高延遲或者失敗時，為系統提供保護和控制。
- 在分散式系統中防止級聯失敗。
- 快速失敗同時能快速恢復。
- 提供失敗回退和優雅的服務降級機制。
- 提供近實時的監控、報警和運維控制手段。
參考：
談談我對服務熔斷、服務降級的理解
使用 Hystrix 實現自動降級與依賴隔離
7、高併發資料庫切庫分庫分表
解決資料庫的瓶頸。
資料庫切庫：
- 實際應用：讀寫分離
- 自定義註解實現資料庫切庫
資料支援多個資料來源與分庫：
- 支援多個資料來源分庫
資料庫分表：
- 橫向（水平）分表
- 縱向（垂直）分表
- 資料庫分表：mybatis分表外掛shardbatis2.0
8、高可用的一些手段
- 任務排程系統分散式：elastic-job+zookeeper 。
- 主備切換：apache curator + zookeeper分散式鎖實現。
- 監控報警機制。