作者：sflaqiu
來源：http://blog.thankbabe.com
前言
高並發經常會發生在有大活躍用戶量，用戶高聚集的業務場景中，如：秒殺活動，定時領取紅包等。
為了讓業務可以流暢的運行並且給用戶一個好的交互體驗，我們需要根據業務場景預估達到的並發量等因素，來設計適合自己業務場景的高並發處理方案。
在電商相關產品開發的這些年，我有幸的遇到了並發下的各種坑，這一路摸爬滾打過來有著不少的血淚史，這裡進行的總結，作為自己的歸檔記錄，同時分享給大家。
伺服器架構
業務從發展的初期到逐漸成熟，伺服器架構也是從相對單一到集群，再到分布式服務。
一個可以支持高並發的服務少不了好的伺服器架構，需要有均衡負載，資料庫需要主從集群，nosql緩存需要主從集群，靜態文件需要上傳cdn，這些都是能讓業務程序流暢運行的強大後盾。
伺服器這塊多是需要運維人員來配合搭建，具體我就不多說了，點到為止。
大致需要用到的伺服器架構如下：
並發測試
高並發相關的業務，需要進行並發的測試，通過大量的數據分析評估出整個架構可以支撐的並發量。
測試高並發可以使用第三方伺服器或者自己測試伺服器，利用測試工具進行並發請求測試，分析測試數據得到可以支撐並發數量的評估，這個可以作為一個預警參考，俗話說知己自彼百戰不殆。
第三方服務：
並發測試工具：
實戰方案
通用方案
日用戶流量大，但是比較分散，偶爾會有用戶高聚的情況；
場景：用戶簽到，用戶中心，用戶訂單，等
伺服器架構圖：
說明：
場景中的這些業務基本是用戶進入APP後會操作到的，除了活動日(618,雙11，等)，這些業務的用戶量都不會高聚集，同時這些業務相關的表都是大數據表，業務多是查詢操作，所以我們需要減少用戶直接命中DB的查詢；優先查詢緩存，如果緩存不存在，再進行DB查詢，將查詢結果緩存起來。
更新用戶相關緩存需要分布式存儲，比如使用用戶ID進行hash分組，把用戶分布到不同的緩存中，這樣一個緩存集合的總量不會很大，不會影響查詢效率。
方案如：
http://blog.thankbabe.com/2016/08/05/redis-up/
以上例子是一個相對簡單的高並發架構，並發量不是很高的情況可以很好的支撐，但是隨著業務的壯大，用戶並發量增加，我們的架構也會進行不斷的優化和演變，比如對業務進行服務化，每個服務有自己的並發架構，自己的均衡伺服器，分布式資料庫，nosql主從集群，如：用戶服務、訂單服務；
消息隊列
秒殺、秒搶等活動業務，用戶在瞬間湧入產生高並發請求
場景：定時領取紅包，等
伺服器架構圖：
說明：
場景中的定時領取是一個高並發的業務，像秒殺活動用戶會在到點的時間湧入，DB瞬間就接受到一記暴擊，hold不住就會宕機，然後影響整個業務；
像這種不是只有查詢的操作並且會有高並發的插入或者更新數據的業務，前面提到的通用方案就無法支撐，並發的時候都是直接命中DB；
設計這塊業務的時候就會使用消息隊列的，可以將參與用戶的信息添加到消息隊列中，然後再寫個多線程程序去消耗隊列，給隊列中的用戶發放紅包；
方案如：
附加：
通過消息隊列可以做很多的服務。
如：定時簡訊發送服務，使用sset(sorted set)，發送時間戳作為排序依據，簡訊數據隊列根據時間升序，然後寫個程序定時循環去讀取sset隊列中的第一條，當前時間是否超過發送時間，如果超過就進行簡訊發送。
一級緩存
高並發請求連接緩存伺服器超出伺服器能夠接收的請求連接量，部分用戶出現建立連接超時無法讀取到數據的問題；
因此需要有個方案當高並發時候時候可以減少命中緩存伺服器；
這時候就出現了一級緩存的方案，一級緩存就是使用站點伺服器緩存去存儲數據，注意只存儲部分請求量大的數據，並且緩存的數據量要控制，不能過分的使用站點伺服器的內存而影響了站點應用程式的正常運行，一級緩存需要設置秒單位的過期時間，具體時間根據業務場景設定，目的是當有高並發請求的時候可以讓數據的獲取命中到一級緩存，而不用連接緩存nosql數據伺服器，減少nosql數據伺服器的壓力
比如APP首屏商品數據接口，這些數據是公共的不會針對用戶自定義，而且這些數據不會頻繁的更新，像這種接口的請求量比較大就可以加入一級緩存；
伺服器架構圖：
合理的規範和使用nosql緩存資料庫，根據業務拆分緩存資料庫的集群，這樣基本可以很好支持業務，一級緩存畢竟是使用站點伺服器緩存所以還是要善用。
靜態化數據
高並發請求數據不變化的情況下如果可以不請求自己的伺服器獲取數據那就可以減少伺服器的資源壓力。
對於更新頻繁度不高，並且數據允許短時間內的延遲，可以通過數據靜態化成JSON，XML,HTML等數據文件上傳CDN，在拉取數據的時候優先到CDN拉取，如果沒有獲取到數據再從緩存，資料庫中獲取，當管理人員操作後台編輯數據再重新生成靜態文件上傳同步到CDN，這樣在高並發的時候可以使數據的獲取命中在CDN伺服器上。
CDN節點同步有一定的延遲性，所以找一個靠譜的CDN伺服器商也很重要
其他方案
分層，分割，分布式
大型網站要很好支撐高並發，這是需要長期的規劃設計
在初期就需要把系統進行分層，在發展過程中把核心業務進行拆分成模塊單元，根據需求進行分布式部署，可以進行獨立團隊維護開發。
網站分層-圖1來自網絡
集群
對於用戶訪問集中的業務獨立部署伺服器，應用伺服器，資料庫，nosql資料庫。核心業務基本上需要搭建集群，即多台伺服器部署相同的應用構成一個集群，通過負載均衡設備共同對外提供服務， 伺服器集群能夠為相同的服務提供更多的並發支持，因此當有更多的用戶訪問時，只需要向集群中加入新的機器即可, 另外可以實現當其中的某台伺服器發生故障時，可以通過負載均衡的失效轉移機制將請求轉移至集群中其他的伺服器上，因此可以提高系統的可用性
通過反向代理均衡負載-圖2來自網絡
異步
在高並發業務中如果涉及到資料庫操作，主要壓力都是在資料庫伺服器上面，雖然使用主從分離，但是資料庫操作都是在主庫上操作，單台資料庫伺服器連接池允許的最大連接數量是有限的
當連接數量達到最大值的時候，其他需要連接數據操作的請求就需要等待有空閒的連接，這樣高並發的時候很多請求就會出現connection time out 的情況
那麼像這種高並發業務我們要如何設計開發方案可以降低資料庫伺服器的壓力呢？
緩存
高並發業務接口多數都是進行業務數據的查詢，如：商品列表，商品信息，用戶信息，紅包信息等，這些數據都是不會經常變化，並且持久化在資料庫中
高並發的情況下直接連接從庫做查詢操作，多台從庫伺服器也抗不住這麼大量的連接請求數（前面說過，單台資料庫伺服器允許的最大連接數量是有限的）
那麼我們在這種高並發的業務接口要如何設計呢？
面向服務
使用服務化思維，將核心業務或者通用的業務功能抽離成服務獨立部署，對外提供接口的方式提供功能。
最理想化的設計是可以把一個複雜的系統抽離成多個服務，共同組成系統的業務，優點：松耦合，高可用性，高伸縮性，易維護。
通過面向服務化設計，獨立伺服器部署，均衡負載，資料庫集群，可以讓服務支撐更高的並發
冗餘，自動化
當高並發業務所在的伺服器出現宕機的時候，需要有備用伺服器進行快速的替代，在應用伺服器壓力大的時候可以快速添加機器到集群中，所以我們就需要有備用機器可以隨時待命。最理想的方式是可以通過自動化監控伺服器資源消耗來進行報警，自動切換降級方案，自動的進行伺服器替換和添加操作等，通過自動化可以減少人工的操作的成本，而且可以快速操作，避免人為操作上面的失誤。
通過GitLab事件，我們應該反思，做了備份數據並不代表就萬無一失了，我們需要保證高可用性，首先備份是否正常進行，備份數據是否可用，需要我們進行定期的檢查，或者自動化監控， 還有包括如何避免人為上的操作失誤問題。(不過事件中gitlab的開放性姿態，積極的處理方式還是值得學習的)
總結
高並發架構是一個不斷衍變的過程，冰洞三尺非一日之寒，長城築成非一日之功 。打好基礎架構方便以後的拓展，這點很重要。