構建高併發&高可用&安全的IT系統-高併發部分

   

什麼是高併發？

狹義來說就是你的網站/軟件同一時間能承受的用戶數量有多少

相關指標有

併發數：對網站/軟件同時發起的請求數，通常也可表明實際的用戶

每秒響應時間：常指一次請求到系統正確響的時間（以秒爲單位）

TPS（每秒事務數）：每秒鐘能夠處理的事務（請求響應），大概的計算公式爲：併發數/每秒響應時間=TPS

QPS（每秒查詢數）：TPS事務有讀有寫，而QPS指的是讀取，通常狀況QPS應是高於TPS的

IP（獨立IP）：一個IP能夠發生屢次UV和PV

PV（訪問量）：即Page View，頁面瀏覽或點周量，用戶每次新刷新即被計算一次

UV（獨立訪客）：通常經過cookies記錄等判斷爲一個獨立用戶，同一IP可能有多個UV（共享IP），發生屢次PV

流量（網絡流量）：請求所產生的網絡流量，由於受限於帶寬也是併發中的一個重要指

 

通常公司演化階段

一、優化運算代碼、SQL查詢、數據庫索引等

二、進行應用負載均衡、數據庫作主從/主主複製進行讀寫分離、增長緩存(Redis\Mem)

三、對系統和數據進行垂直拆分，按業務模塊拆分紅不一樣的應用及數據庫表

四、分佈式服務化、異步消息機制、數據庫表水平拆分

 

優化運算代碼、SQL查詢、數據庫索引等

通常初創公司系統大多數都是單體單庫的系統，按照成本優先級第一要作的就是對系統進行代碼級的優化。好比應用代碼邏輯梳理、合理使用多線程、SQL避免全表掃描、少使用LIKE、

根據業務建立索引等。

案例

單次LIKE大數據量統計查詢Sending data狀態過多致使數據庫鏈接被耗盡，系統中止響應。經過在統計表創建觸發器更新單值表解決

 

 

 

負載均衡、讀寫分離、緩存

到了第二階段，單體應用經過優化與增長硬件配置已沒法解決高併發的問題，這時能夠考慮進行如下架構的演化，這種演化對系統基本沒有侵入性，成本低廉

負載均衡：

能夠經過Nginx反向代理、F5等進行應用的多流量分發，須要解決的問題就是會話問題，可採用Nginx的路由或是SESSION同步/獨立。

讀寫分離：

採用數據庫的主從複製機制，將寫入庫與讀取庫分離，可採用中間件進行代理路由，基本能夠不改代碼。

緩存：

可跟據業務規則將部分數據進行緩存

 

 

應用、數據垂直拆分

第二階段支撐過必定量後，隨着併發量再次的提高，因爲單庫表數據量變大以及訪問限制已經不能知足，這時能夠考慮進行數據庫表的按系統模塊垂直拆分。將內聯的業務劃分爲獨立的庫表，相應的應用也

應隨之拆分（應用這時加機器還能挺，不過作不到可審縮資源利用最大化）。同一應用系統訪問同一庫表，應用系統之間進行少許通訊。

 

 

 

分佈式服務化、異步消息機制、數據庫表水平拆分

在經歷過前三階段後，能走到第四階段說明平臺的發展很是好了，對系統的高併發又有了進一步的要求，這也是成本最高最複雜的，系統架構須要進行很大的改造

分佈式：

對系統應用進行服務化（如微服務），服務化的目的不僅是爲了高併發，也從系統的可維護性(團隊大了)、資源利用最大化(對服務進行差別化支撐)方面考慮。

面臨的挑戰主要是分佈式事務方面的控制，可採用二階段提交方式或是分佈式事務容器實現分佈式事務。

異步消息機制：

主要解決大併發寫入瓶頸，利用消息對列對寫入消息進行排隊，待數據庫進

行處理。

數據庫表水平拆分：按必定規則將同一業務表的數據拆分到不一樣的庫/表中（如HASH），面臨的挑戰主要是跟業務關聯性強、跨表的數據合併等。解決方案就是寫

好代碼吧。。。