之前的兩篇系統架構的博客中都提到了高併發、高可用技術，但是卻都沒有詳細聊過，今天就好好聊一下常見的高併發技術。 一 高併發技術核心 高併發技術的核心是分流；分別針對請求的各個環節，根據具體場景和業務特點採用不同的分流方案，逐層逐級的分擔系統壓力，從而達到高併發能力。 常見的高併發技術有：動靜分離、緩 ...
之前的兩篇系統架構的博客中都提到了高併發、高可用技術，但是卻都沒有詳細聊過，今天就好好聊一下常見的高併發技術。
一 高併發技術核心
高併發技術的核心是分流；分別針對請求的各個環節，根據具體場景和業務特點採用不同的分流方案，逐層逐級的分擔系統壓力，從而達到高併發能力。
常見的高併發技術有：動靜分離、緩存、非同步併發、水平擴展等。分流簡單來說就是：一臺伺服器承擔不了的流量，就讓多台伺服器共同分擔；DB承擔不了流量就讓緩存來幫忙分擔；等等。接下來討論的所有內容都是圍繞著分流來實現的。
現實中沒有一招鮮吃遍天的美事兒，每一個公司、每一種業務、每一個場景、每一個功能都有其與眾不同的特點，現實中一般都會根據業務特征、根據請求的各個環節特點，做針對性優化。
二 分階段優化策略
1. 模型
一次請求主要分為四個階段：客戶端發起請求；通過網路將請求信息發送到服務端；服務端處理請求；服務端將結果返回給客戶端。為了追求併發的極致，我們可以針對每一個階段分別使用不同的策略，來提升系統的併發性能。模型如下：
這是一個漏斗型的模型，通過逐層過濾，將流量分散，讓儘可能少的請求到達底層。
此模型的核心就是，根據各環節的特點，選擇相應的優化策略，從而實現高併發的目的。
2. 客戶端優化技術
客戶端優化技術主要指的是客戶端通過緩存數據，減少訪問服務端的次數，以實現降低服務端壓力，達到支持更多併發量的需求。
常見的處理方式是：緩存不經常變動的內容，每隔一定時間更新一次，或者除非修改了否則較長時間不更新；如：更新微信公眾賬號的頭像時，手機端不會立即看到這個更新。另外，根據業務場景可以限制不必要的請求；如：點擊一個按鈕，發送一次請求到服務端時，禁用按鈕，避免因用戶多次點擊，而發送不必要的請求。
3. 網路優化技術
網路優化的核心目標是：將資源緩存到距離用戶最近的網路節點上，這樣除了可以省下大量網路帶寬外，還可以達到最快的請求速度；一般針對靜態資源。
通過靜態化技術（將不經常變動的內容生成靜態文件）或動靜分離技術（例如H5+ajax），將靜態的內容存儲在CDN上，當用戶查看一個頁面時，只讓少數的動態請求落到伺服器端，其他內容從CDN上直接獲取，這樣就可以極大的減少伺服器端的流量。
4. 服務端優化技術
1) 負載均衡
負載均衡的核心是讓每台伺服器以一個合適的負載來分擔所有的請求。
常見的負載均衡方案有：隨機、輪詢、hash、一致性hash。當然在這些基礎上有很多擴展，例如在負載均衡的機器中設置不同的權重；根據key的範圍不同調用不同的伺服器等等。
2) 緩存
a) 為什麼高效
緩存的結構一般都是key-value結構，通過key直接定址，時間複雜度為O(1)，這比DB的遍歷比較來快了非常多；另外，不少的緩存中間件通過在記憶體中存儲數據，不用從磁碟中獲取數據，性能也就會非常高。
說明一下：大部分緩存中間件都會對value做一些擴充，讓value也成為一個複雜的數據結構，例如Redis的Set、SortSet，如果需要在value中尋找某一個值，時間複雜度會退化成為O(N)；這些數據結構提供了強大的功能，使用的時候註意合理使用，以避免因為緩存亂用導致性能降低的問題。
b) 分散式緩存
如redis、tair、memcached等。
優點是：集群部署，不用考慮容量問題，數據支持持久化，支持高可用。
缺點是：因為伺服器和緩存數據交換時存在一次網路交互，如果數據結構選擇不合理或者併發量非常大或者每次交互的數據量較大時，可能會引起io阻塞等問題，需謹慎。
c) 堆緩存
通過java的堆來緩存數據。
優點是：速度非常快。
缺點是：存儲數據量受限，斷點數據丟失，分散式場景中如果出現不一致時，處理麻煩。
d) 磁碟文件緩存
將數據存儲到伺服器所在的磁碟上。
優點是：存儲內容較堆記憶體多（少於分散式緩存），是持久化的。
缺點是：伺服器遷移時也要遷移磁碟中的文件，分散式場景中如果出現不一致時，處理麻煩。
e) 註意事項
緩存數據和資料庫數據不一致的問題。
緩存擊穿問題。
緩存數據丟失問題（緩存一般都需要持久化的，為了保證性能緩存一般都不是同步持久化，所以是可能存在數據丟失問題的）。
3) 通信模型
高性能的IO通信模型可以給系統帶來巨大的性能提升。目前就較為成熟、高效的IO通行模型是NIO（也叫IO多路復用、非同步阻塞IO）。
在java伺服器前加一層Nginx伺服器，它既可以提供良好的負載均衡能力，也能夠支持非常高的併發。當然Nginx的高性能還與他的master-worker設計有關，幾乎做到了無線程切換。
使用Dubbo進行RPC調用時，預設使用的Netty也是基於NIO的。
4) 隊列技術
隊列技術的作用是將同步轉化成非同步；相比於同步，非同步可以根據伺服器的處理能力來消化這些請求；同步則是不顧忌伺服器的承受能力，所有請求一起蜂擁而入。
常見的技術有MQ消息伺服器，例如RocketMQ、RabbitMQ、kafka；其中RocketMQ和kafka都可以支持非常大的併發量和消息量，性能非常的好。
5) 線程池
線程池是一種很實用的提升系統的服務能力的方案，其思路就是一個線程處理的慢，那創建一堆線程出來處理，速度自然就快了；線程池還有另外一個優點，重覆利用連接，降低創建成本。線程池大小的設置一般參考一下兩點：
高併發、任務執行時間短的任務，線程池線程數可以設置為CPU核數，減少線程上下文的切換；主要針對cpu密集型任務。例如：nginx中worker線程的數目。
線程池設置可以參考《ThreadPoolExecutor》博客中的“線程池配置”部分內容
6) DB存儲
DB一般是服務端性能的瓶頸，所以對DB的優化方式也比較多，整理起來主要有以下幾種：
表級別性能優化，例如：單表操作，避免聯表操作；使用索引；事務儘可能短；查詢優化；等等。
讀寫分離。
分庫分表；分區（註意不合適的分區策略不但不能提升性能，反而可能降低性能）。
5. 響應優化技術
返回結果優化主要是壓縮返回結果，通過降低位元組長度來降低網路消耗。分多次載入數據，每次只顯示一屏數據。
這種技術在靜態內容中使用的比較多，例如壓縮javascript、css文件等，動態請求中使用的不多。
三 根據業務特征優化
現實中有非常多種根據業務特征優化的示例，這裡僅僅提供兩個示例，以示說明。
1. 業務特征定製流程
例如：秒殺活動其實是交易的一種變種，他的特點是瞬間下單併發量很高，但受實際秒殺商品數量限制，最終僅少量訂單可以創建成功。基於這種業務特點，可以在服務端通過過濾和隊列技術，先攔截掉絕大多數流量，僅僅讓可以成功的請求到達底層，從而輕鬆實現高併發目標。
2. 調整流程
在《抽獎活動的高可用、高併發優化》博客中“流程順序調整”內容，討論過一種場景，當中獎概率比較低時，甚至可以通過調整流程中某些環節的順序，從而提升性能。
四 分流技術
以寫請求為例，以下是一種常見的分流模型，通過下圖我們可以看到，在經歷前面眾多環節的分流後，僅有少量請求會需要寫DB，當然也就可以輕鬆支持大併發流量了。
