什麼是高併發？
狹義來講就是你的網站/軟體同一時間能承受的使用者數量有多少
相關指標有
併發數：對網站/軟體同時發起的請求數，一般也可代表實際的使用者
每秒響應時間：常指一次請求到系統正確響的時間（以秒為單位）
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