什麼是高併發

高併發（High Concurrency）是網際網路分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。

高併發相關常用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒查詢率QPS（Query Per Second），併發使用者數等。

響應時間：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時間。

吞吐量：單位時間內處理的請求數量。

QPS：每秒響應請求數。在網際網路領域，這個指標和吞吐量區分的沒有這麼明顯。

併發使用者數：同時承載正常使用系統功能的使用者數量。例如一個即時通訊系統，同時線上量一定程度上代表了系統的併發使用者數。

如何提升系統的併發能力

網際網路分散式架構設計，提高系統併發能力的方式，方法論上主要有兩種：垂直擴充套件（Scale Up）與水平擴充套件（Scale Out）。

垂直擴充套件：提升單機處理能力。垂直擴充套件的方式又有兩種：

（1）增強單機硬體效能，例如：增加CPU核數如32核，升級更好的網絡卡如萬兆，升級更好的硬碟如SSD，擴充硬碟容量如2T，擴充系統記憶體如128G；

（2）提升單機架構效能，例如：使用Cache來減少IO次數，使用非同步來增加單服務吞吐量，使用無鎖資料結構來減少響應時間；
        水平擴充套件：只要增加伺服器數量，就能線性擴充系統性能。

常見網際網路分散式架構如上，分為：

（1）客戶端層：典型呼叫方是瀏覽器browser或者手機應用APP

（2）反向代理層：系統入口，反向代理

（3）站點應用層：實現核心應用邏輯，返回html或者json

（4）服務層：如果實現了服務化，就有這一層

（5）資料-快取層：快取加速訪問儲存

（6）資料-資料庫層：資料庫固化資料儲存

關於三種應對大併發的常見優化方案

【資料庫快取】

為什麼是要使用快取？

快取資料是為了讓客戶端很少甚至不訪問資料庫，減少磁碟IO，提高併發量，提高應用資料的響應速度。

【CDN加速】

什麼是CDN？

CDN的全稱是Content Delivery Network，CDN系統能夠實時地根據網路流量和各節點的連線、負載狀況以及到使用者的距離等綜合資訊將使用者的請求重新導向離使用者最近的服務節點上。

使用CDN的優勢？

CDN的本質是記憶體快取，就近訪問，它提高了企業站點(尤其含有大量圖片和靜態頁面站點)的訪問速度，跨運營商的網路加速，保證不同網路的使用者都得到良好的訪問質量。

同時，減少遠端訪問的頻寬，分擔網路流量，減輕原站點WEB伺服器負載。

二  什麼是高可用

高可用HA（High Availability）是分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設計減少系統不能提供服務的時間。

假設系統一直能夠提供服務，我們說系統的可用性是100%。

如果系統每執行100個時間單位，會有1個時間單位無法提供服務，我們說系統的可用性是99%。

很多公司的高可用目標是4個9，也就是99.99%，這就意味著，系統的年停機時間為8.76個小時。

    如何保障系統的高可用

我們都知道，單點是系統高可用的大敵，單點往往是系統高可用最大的風險和敵人，應該儘量在系統設計的過程中避免單點。方法論上，高可用保證的原則是“叢集化”，或者叫“冗餘”：只有一個單點，掛了服務會受影響；如果有冗餘備份，掛了還有其他backup能夠頂上。

保證系統高可用，架構設計的核心準則是：冗餘。

常見網際網路分散式架構如上，分為：

（1）客戶端層：典型呼叫方是瀏覽器browser或者手機應用APP

（2）反向代理層：系統入口，反向代理

（3）站點應用層：實現核心應用邏輯，返回html或者json

（4）服務層：如果實現了服務化，就有這一層

（5）資料-快取層：快取加速訪問儲存

（6）資料-資料庫層：資料庫固化資料儲存

整個系統的高可用，又是通過每一層的冗餘+自動故障轉移來綜合實現的。

高可用HA（High Availability）是分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設計減少系統不能提供服務的時間。

方法論上，高可用是通過冗餘+自動故障轉移來實現的。

整個網際網路分層系統架構的高可用，又是通過每一層的冗餘+自動故障轉移來綜合實現的，具體的：

（1）【客戶端層】到【反向代理層】的高可用，是通過反向代理層的冗餘實現的，常見實踐是keepalived + virtual IP自動故障轉移

（2）【反向代理層】到【站點層】的高可用，是通過站點層的冗餘實現的，常見實踐是nginx與web-server之間的存活性探測與自動故障轉移

（3）【站點層】到【服務層】的高可用，是通過服務層的冗餘實現的，常見實踐是通過service-connection-pool來保證自動故障轉移

（4）【服務層】到【快取層】的高可用，是通過快取資料的冗餘實現的，常見實踐是快取客戶端雙讀雙寫，或者利用快取叢集的主從資料同步與sentinel保活與自動故障轉移；更多的業務場景，對快取沒有高可用要求，可以使用快取服務化來對呼叫方遮蔽底層複雜性

（5）【服務層】到【資料庫“讀”】的高可用，是通過讀庫的冗餘實現的，常見實踐是通過db-connection-pool來保證自動故障轉移

（6）【服務層】到【資料庫“寫”】的高可用，是通過寫庫的冗餘實現的，常見實踐是keepalived + virtual IP自動故障轉移

水平切分+鎖粒度優化

上文中之所以鎖衝突嚴重，是因為所有司機都公用一把鎖，鎖的粒度太粗（可以認為是一個數據庫的“庫級別鎖”），是否可能進行水平拆分（類似於資料庫裡的分庫），把一個庫鎖變成多個庫鎖，來提高併發，降低鎖衝突呢？顯然是可以的，把1個Map水平切分成多個Map即可：

總結

在【超高併發】，【寫多讀少】，【定長value】的【業務快取】場景下：

1）可以通過水平拆分來降低鎖衝突

2）可以通過Map轉Array的方式來最小化鎖衝突，一條記錄一個鎖

3）可以把鎖去掉，最大化併發，但帶來的資料完整性的破壞

4）可以通過簽名的方式保證資料的完整性，實現無鎖快取