什麼是高并發？
狹義來講就是你的網站/軟體同一時間能承受的使用者數量有多少
相關名額有
并發數：對網站/軟體同時發起的請求數，一般也可代表實際的使用者
每秒響應時間：常指一次請求到系統正确響的時間（以秒為機關）
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），面臨的挑戰主要是跟業務關聯性強、跨表的資料合并等。解決方案就是寫
好代碼吧。。。