Java 淺談 高並發 處理方案詳解
高性能開發十大必須掌握的核心技術
我們循序漸進，從內存、磁盤I/O、網絡I/O、CPU、緩存、架構、算法等多層次遞進，串聯起高性能開發十大必須掌握的核心技術。
- I/O優化：零拷貝技術 - I/O優化：多路復用技術 - 線程池技術 - 無鎖編程技術 - 進程間通信技術 - RPC && 序列化技術 - 數據庫索引技術 - 緩存技術 && 佈隆過濾器 - 全文搜索技術 - 負載均衡技術
I/O優化：零拷貝技術
從磁盤讀文件、再通過網絡發送數據，數據從磁盤到網絡，兜兜轉轉需要拷貝四次，其中CPU親自搬運都需要兩次。
最近在學習nginx的底層設計，正好有看到這個。後面可以在nginx系列裡面補上這個。
零拷貝技術，解放CPU，文件數據直接從內核發送出去，無需再拷貝到應用程序緩沖區，白白浪費資源。
Linux API：
ssize_t sendfile( int out_fd, int in_fd, off_t *offset, size_t count );
函數名字已經把函數的功能解釋的很明顯瞭：發送文件。指定要發送的文件描述符和網絡套接字描述符，一個函數搞定！
I/O優化：多路復用技術
每個線程都要阻塞在recv等待對方的請求，這來訪問的人多瞭，線程開的就多瞭，大量線程都在阻塞，系統運轉速度也隨之下降。
這個時候，你需要多路復用技術，使用select模型，將所有等待（accept、recv）都放在主線程裡，工作線程不需要再等待。
過瞭一段時間之後，網站訪問的人越來越多瞭，就連select也開始有點應接不暇，老板繼續讓你優化性能。
這個時候，你需要升級多路復用模型為epoll。
select有三弊，epoll有三優。
select底層采用數組來管理套接字描述符，同時管理的數量有上限，一般不超過幾千個，epoll使用樹和鏈表來管理，同時管理數量可以很大。 select不會告訴你到底哪個套接字來瞭消息，你需要一個個去詢問。epoll直接告訴你誰來瞭消息，不用輪詢。 select進行系統調用時還需要把套接字列表在用戶空間和內核空間來回拷貝，循環中調用select時簡直浪費。epoll統一在內核管理套接字描述符，無需來回拷貝。
用上瞭epoll多路復用技術，開發瞭3.0版本，你的網站能同時處理很多用戶請求瞭。
之前的方案中，工作線程總是用到才創建，用完就關閉，大量請求來的時候，線程不斷創建、關閉、創建、關閉，開銷挺大的。這個時候，你需要：
線程池技術
我們可以在程序一開始啟動後就批量啟動一波工作線程，而不是在有請求來的時候才去創建，使用一個公共的任務隊列，請求來臨時，向隊列中投遞任務，各個工作線程統一從隊列中不斷取出任務來處理，這就是線程池技術。
多線程技術的使用一定程度提升瞭服務器的並發能力，但同時，多個線程之間為瞭數據同步，常常需要使用互斥體、信號、條件變量等手段來同步多個線程。這些重量級的同步手段往往會導致線程在用戶態/內核態多次切換，系統調用，線程切換都是不小的開銷。
在線程池技術中，提到瞭一個公共的任務隊列，各個工作線程需要從中提取任務進行處理，這裡就涉及到多個工作線程對這個公共隊列的同步操作。
有沒有一些輕量級的方案來實現多線程安全的訪問數據呢？這個時候，你需要：
無鎖編程技術
多線程並發編程中，遇到公共數據時就需要進行線程同步。而這裡的同步又可以分為阻塞型同步和非阻塞型同步。
阻塞型同步好理解，我們常用的互斥體、信號、條件變量等這些操作系統提供的機制都屬於阻塞型同步，其本質都是要加“鎖”。
與之對應的非阻塞型同步就是在無鎖的情況下實現同步，目前有三類技術方案：
Wait-freeLock-freeObstruction-free
三類技術方案都是通過一定的算法和技術手段來實現不用阻塞等待而實現同步，這其中又以Lock-free最為應用廣泛。
Lock-free能夠廣泛應用得益於目前主流的CPU都提供瞭原子級別的read-modify-write原語，這就是著名的CAS(Compare-And-Swap)操作。在Intel x86系列處理器上，就是cmpxchg系列指令。
我們常常見到的無鎖隊列、無鎖鏈表、無鎖HashMap等數據結構，其無鎖的核心大都來源於此。在日常開發中，恰當的運用無鎖化編程技術，可以有效地降低多線程阻塞和切換帶來的額外開銷，提升性能。
服務器上線瞭一段時間，發現服務經常崩潰異常，排查發現是工作線程代碼bug，一崩潰整個服務都不可用瞭。於是你決定把工作線程和主線程拆開到不同的進程中，工作線程崩潰不能影響整體的服務。這個時候出現瞭多進程，你需要：
進程間通信技術
提起進程間通信，你能想到的是什麼？
管道 命名管道 socket 消息隊列 信號 信號量 共享內存
以上各種進程間通信的方式詳細介紹和比較，推薦一篇文章再探進程間通信，這裡不再贅述。
Scale-out（橫向拓展）
采用分佈式部署的方式把流量分開，讓每個服務器都承擔一部分並發和流量。這也是我最喜歡的一種方法。
緩存
使用緩存來提高系統的性能。
為什麼緩存可以大幅度提升系統的性能呢？
那肯定是要更普通磁盤進行對比的啊。我們來看看普通磁盤的速度：
普通磁盤的尋道時間是 10ms 左右，而相比於磁盤尋道花費的時間，CPU 執行指令和內存尋址的時間都在是 ns（納秒）級別，從千兆網卡上讀取數據的時間是在μs（微秒）級別。所以在整個計算機體系中，磁盤是最慢的一環，甚至比其它的組件要慢幾個數量級。因此，我們通常使用以內存作為存儲介質的緩存，以此提升性能。
至於緩存為什麼快，因為它是內置的啊，在內存中。不過也有個缺點，就是燒內存。
異步
這是業務層面的異步。
內核層面的異步，需要調用內核指定的異步函數（aio族），不然，不論阻塞還是非阻塞都是同步。
高性能、高可用、高拓展 解決方案
以下實踐方案，有些我已經試過瞭，有些還沒體驗但是知道那麼一回事兒，有些則不知道啥時候能實踐瞭。
高性能的實踐方案
1、集群部署，通過負載均衡減輕單機壓力。 2、多級緩存，包括靜態數據使用CDN、本地緩存、分佈式緩存等，以及對緩存場景中的熱點key、緩存穿透、緩存並發、數據一致性等問題的處理。 3、分庫分表和索引優化，以及借助搜索引擎解決復雜查詢問題。 4、考慮NoSQL數據庫的使用，比如HBase、TiDB等，但是團隊必須熟悉這些組件，且有較強的運維能力。 5、異步化，將次要流程通過多線程、MQ、甚至延時任務進行異步處理。 6、限流，需要先考慮業務是否允許限流（比如秒殺場景是允許的），包括前端限流、Nginx接入層的限流、服務端的限流。 7、對流量進行削峰填谷，通過MQ承接流量。 8、並發處理，通過多線程將串行邏輯並行化。 9、預計算，比如搶紅包場景，可以提前計算好紅包金額緩存起來，發紅包時直接使用即可。 10、緩存預熱，通過異步任務提前預熱數據到本地緩存或者分佈式緩存中。 11、減少IO次數，比如數據庫和緩存的批量讀寫、RPC的批量接口支持、或者通過冗餘數據的方式幹掉RPC調用。 12、減少IO時的數據包大小，包括采用輕量級的通信協議、合適的數據結構、去掉接口中的多餘字段、減少緩存key的大小、壓縮緩存value等。 13、程序邏輯優化，比如將大概率阻斷執行流程的判斷邏輯前置、For循環的計算邏輯優化，或者采用更高效的算法。 14、各種池化技術的使用和池大小的設置，包括HTTP請求池、線程池（考慮CPU密集型還是IO密集型設置核心參數）、數據庫和Redis連接池等。 15、JVM優化，包括新生代和老年代的大小、GC算法的選擇等，盡可能減少GC頻率和耗時。 16、鎖選擇，讀多寫少的場景用樂觀鎖，或者考慮通過分段鎖的方式減少鎖沖突。
上述方案無外乎從計算和 IO 兩個維度考慮所有可能的優化點，需要有配套的監控系統實時瞭解當前的性能表現，並支撐你進行性能瓶頸分析，然後再遵循二八原則，抓主要矛盾進行優化。
高可用的實踐方案
1、對等節點的故障轉移，Nginx和服務治理框架均支持一個節點失敗後訪問另一個節點。 2、非對等節點的故障轉移，通過心跳檢測並實施主備切換（比如redis的哨兵模式或者集群模式、MySQL的主從切換等）。 3、接口層面的超時設置、重試策略和冪等設計。 4、降級處理：保證核心服務，犧牲非核心服務，必要時進行熔斷；或者核心鏈路出問題時，有備選鏈路。 5、限流處理：對超過系統處理能力的請求直接拒絕或者返回錯誤碼。 6、MQ場景的消息可靠性保證，包括producer端的重試機制、broker側的持久化、consumer端的ack機制等。 7、灰度發佈，能支持按機器維度進行小流量部署，觀察系統日志和業務指標，等運行平穩後再推全量。 8、監控報警：全方位的監控體系，包括最基礎的CPU、內存、磁盤、網絡的監控，以及Web服務器、JVM、數據庫、各類中間件的監控和業務指標的監控。 9、災備演練：類似當前的“混沌工程”，對系統進行一些破壞性手段，觀察局部故障是否會引起可用性問題。
高可用的方案主要從冗餘、取舍、系統運維3個方向考慮，同時需要有配套的值班機制和故障處理流程，當出現線上問題時，可及時跟進處理。
高擴展的實踐方案
1、合理的分層架構：比如上面談到的互聯網最常見的分層架構，另外還能進一步按照數據訪問層、業務邏輯層對微服務做更細粒度的分層 （但是需要評估性能，會存在網絡多一跳的情況）。 2、存儲層的拆分：按照業務維度做垂直拆分、按照數據特征維度進一步做水平拆分（分庫分表）。 3、業務層的拆分：最常見的是按照業務維度拆（比如電商場景的商品服務、訂單服務等）， 也可以按照核心接口和非核心接口拆，還可以按照請求源拆（比如To C和To B，APP和H5）。
總結
1、最簡單的系統設計滿足業務需求和流量現狀，選擇最熟悉的技術體系。
2、隨著流量的增加和業務的變化，修正架構中存在問題的點，如單點問題，橫向擴展問題，性能無法滿足需求的組件。
在這個過程中，選擇社區成熟的、團隊熟悉的組件幫助我們解決問題，在社區沒有合適解決方案的前提下才會自己造輪子。
3、當對架構的小修小補無法滿足需求時，考慮重構、重寫等大的調整方式以解決現有的問題。
本篇文章就到這裡瞭，希望能夠給你帶來幫助，也希望您能夠多多關註WalkonNet的更多內容!