什麽是高並發？

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

相關指標有

並發數：對網站/軟件同時發起的請求數，一般也可代表實際的用戶

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

TPS（每秒事務數）：每秒鐘可以處理的事務（請求響應），大概的計算公式為：並發數/每秒響應時間=TPS

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

IP（獨立IP）：一個IP可以發生多次UV和PV

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

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

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

一般公司演化階段

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

2、進行應用負載均衡、數據庫做主從/主主復制進行讀寫分離、增加緩存(Redis\Mem)

3、對系統和數據進行垂直拆分，按業務模塊拆分成不同的應用及數據庫表

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

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

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

根據業務創建索引等。

案例

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

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

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

負載均衡：

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

讀寫分離：

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

緩存：

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

應用、數據垂直拆分

第二階段支撐過一定量後，隨著並發量再次的提升，由於單庫表數據量變大以及訪問限制已經不能滿足，這時可以考慮進行數據庫表的按系統模塊垂直拆分。將內聯的業務劃分為獨立的庫表，相應的應用也

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

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

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

分布式：

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

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

異步消息機制：

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

行處理。

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

好代碼吧。。。

http://www.cnblogs.com/assion/p/7239106.html

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