本文主要分兩部分，首先我們先聊一下Redis6.0之前為什么采用單執行緒模型，然后再詳細解釋Redis6.0的多執行緒，
Redis6.0之前為什么采用單執行緒模型
嚴格地說，從Redis 4.0之后并不是單執行緒，除了主執行緒外，還有一些后臺執行緒處理一些較為緩慢的操作，例如無用連接的釋放、大 key 的洗掉等等，
單執行緒模型，為何性能那么高？
Redis作者從設計之初，進行了多方面的考慮，最終選擇使用單執行緒模型來處理命令，之所以選擇單執行緒模型，主要有如下幾個重要原因：
- Redis操作基于記憶體，絕大多數操作的性能瓶頸不在CPU
- 單執行緒模型，避免了執行緒間切換帶來的性能開銷
- 使用單執行緒模型也能并發的處理客戶端的請求（多路復用I/O）
- 使用單執行緒模型，可維護性更高，開發，除錯和維護的成本更低
上述第三個原因是Redis最終采用單執行緒模型的決定性因素，其他的兩個原因都是使用單執行緒模型額外帶來的好處，在這里我們會按順序介紹上述的幾個原因，
性能瓶頸不在CPU
下圖是Redis官網對單執行緒模型的說明，大概意思是：Redis的瓶頸并不在CPU，它的主要瓶頸在于記憶體和網路，在Linux環境中，Redis每秒甚至可以提交100萬次請求，
為什么說Redis的瓶頸不在CPU？
首先，Redis絕大部分操作是基于記憶體的，而且是純kv（key-value）操作，所以命令執行速度非常快，我們可以大概理解成，redis中的資料存盤在一張大HashMap中，HashMap的優勢就是查找和寫入的時間復雜度都是O(1)，Redis內部采用這種結構存盤資料，就奠定了Redis高性能的基礎，根據Redis官網描述，在理想情況下Redis每秒可以提交一百萬次請求，每次請求提交所需的時間在納秒的時間量級，既然每次的Redis操作都這么快，單執行緒就可以完全搞定了，那還何必要用多執行緒呢！
執行緒背景關系切換問題
另外，多執行緒場景下會發生執行緒背景關系切換，執行緒是由CPU調度的，CPU的一個核在一個時間片內只能同時執行一個執行緒，在CPU由執行緒A切換到執行緒B的程序中會發生一系列的操作，主要程序包括保存執行緒A的執行現場，然后載入執行緒B的執行現場，這個程序就是“執行緒背景關系切換”，其中涉及執行緒相關指令的保存和恢復，
頻繁的執行緒背景關系切換可能會導致性能急劇下降，這會導致我們不僅沒有提升處理請求的速度，反而降低了性能，這也是 Redis 對于多執行緒技術持謹慎態度的原因之一，
在Linux系統中可以使用vmstat命令來查看背景關系切換的次數，下面是vmstat查看背景關系切換次數的示例：
vmstat 1 表示每秒統計一次, 其中cs列就是指背景關系切換的數目. 一般情況下, 空閑系統的背景關系切換每秒在1500以下，
并行處理客戶端的請求（I/O多路復用）
如上所述：Redis的瓶頸并不在CPU，它的主要瓶頸在于記憶體和網路，所謂記憶體瓶頸很好理解，Redis做為快取使用時很多場景需要快取大量資料，所以需要大量記憶體空間，這可以通過集群分片去解決，例如Redis自身的無中心集群分片方案以及Codis這種基于代理的集群分片方案，
對于網路瓶頸，Redis在網路I/O模型上采用了多路復用技術，來減少網路瓶頸帶來的影響，很多場景中使用單執行緒模型并不意味著程式不能并發的處理任務，Redis 雖然使用單執行緒模型處理用戶的請求，但是它卻使用 I/O 多路復用技術“并行”處理來自客戶端的多個連接，同時等待多個連接發送的請求，使用 I/O多路復用技術能極大地減少系統的開銷，系統不再需要為每個連接創建專門的監聽執行緒，避免了由于大量的執行緒創建帶來的巨大性能開銷，
下面我們詳細解釋一下多路復用I/O模型，為了能更充分理解，我們先了解幾個基本概念，
Socket（套接字）：Socket可以理解成，在兩個應用程式進行網路通信時，分別在兩個應用程式中的通信端點，通信時，一個應用程式將資料寫入Socket，然后通過網卡把資料發送到另外一個應用程式的Socket中，我們平常所說的HTTP和TCP協議的遠程通信，底層都是基于Socket實作的，5種網路IO模型也都要基于Socket實作網路通信，
阻塞與非阻塞：所謂阻塞，就是發出一個請求不能立刻回傳回應，要等所有的邏輯全處理完才能回傳回應，非阻塞反之，發出一個請求立刻回傳應答，不用等處理完所有邏輯，
內核空間與用戶空間：在Linux中，應用程式穩定性遠遠比不上作業系統程式，為了保證作業系統的穩定性，Linux區分了內核空間和用戶空間，可以這樣理解，內核空間運行作業系統程式和驅動程式，用戶空間運行應用程式，Linux以這種方式隔離了作業系統程式和應用程式，避免了應用程式影響到作業系統自身的穩定性，這也是Linux系統超級穩定的主要原因，所有的系統資源操作都在內核空間進行，比如讀寫磁盤檔案，記憶體分配和回收，網路介面呼叫等，所以在一次網路IO讀取程序中，資料并不是直接從網卡讀取到用戶空間中的應用程式緩沖區，而是先從網卡拷貝到內核空間緩沖區，然后再從內核拷貝到用戶空間中的應用程式緩沖區，對于網路IO寫入程序，程序則相反，先將資料從用戶空間中的應用程式緩沖區拷貝到內核緩沖區，再從內核緩沖區把資料通過網卡發送出去，
多路復用I/O模型，建立在多路事件分離函式select，poll，epoll之上，以Redis采用的epoll為例，在發起read請求前，先更新epoll的socket監控串列，然后等待epoll函式回傳（此程序是阻塞的，所以說多路復用IO本質上也是阻塞IO模型），當某個socket有資料到達時，epoll函式回傳，此時用戶執行緒才正式發起read請求，讀取并處理資料，這種模式用一個專門的監視執行緒去檢查多個socket，如果某個socket有資料到達就交給作業執行緒處理，由于等待Socket資料到達程序非常耗時，所以這種方式解決了阻塞IO模型一個Socket連接就需要一個執行緒的問題，也不存在非阻塞IO模型忙輪詢帶來的CPU性能損耗的問題，多路復用IO模型的實際應用場景很多，大家耳熟能詳的Redis，Java NIO，以及Dubbo采用的通信框架Netty都采用了這種模型，
下圖是基于epoll函式Socket編程的詳細流程，
可維護性
我們知道，多執行緒可以充分利用多核CPU，在高并發場景下，能夠減少因I/O等待帶來的CPU損耗，帶來很好的性能表現，不過多執行緒卻是一把雙刃劍，帶來好處的同時，還會帶來代碼維護困難，線上問題難于定位和除錯，死鎖等問題，多執行緒模型中代碼的執行程序不再是串行的，多個執行緒同時訪問的共享變數如果處理不當也會帶來詭異的問題，
我們通過一個例子，看一下多執行緒場景下發生的詭異現象，看下面的代碼：
flag為true時，cal() 方法回傳值是多少？很多人會說：這還用問嗎！肯定回傳2
結果可能會讓你大吃一驚！上面的這段代碼，由于陳述句1和陳述句2沒有資料依賴性，可能會發生指令重排序，有可能編譯器會把flag=true放到num=1的前面，此時set和cal方法分別在不同執行緒中執行，沒有先后關系，cal方法，只要flag為true，就會進入if的代碼塊執行相加的操作，可能的順序是：
- 陳述句1先于陳述句2執行，這時的執行順序可能是：陳述句1->陳述句2->陳述句3->陳述句4，執行陳述句4前，num = 1，所以cal的回傳值是2
- 陳述句2先于陳述句1執行，這時的執行順序可能是：陳述句2->陳述句3->陳述句4->陳述句1，執行陳述句4前，num = 0，所以cal的回傳值是0
我們可以看到，在多執行緒環境下如果發生了指令重排序，會對結果造成嚴重影響，
當然可以在第三行處，給flag加上關鍵字volatile來避免指令重排，即在flag處加上了記憶體柵欄，來阻隔flag（柵欄）前后的代碼的重排序，當然多執行緒還會帶來可見性問題，死鎖問題以及共享資源安全等問題，
boolean volatile flag = false;Redis6.0為何引入多執行緒？
Redis6.0引入的多執行緒部分，實際上只是用來處理網路資料的讀寫和協議決議，執行命令仍然是單一作業執行緒，
從上圖我們可以看到Redis在處理網路資料時，呼叫epoll的程序是阻塞的，也就是說這個程序會阻塞執行緒，如果并發量很高，達到幾萬的QPS，此處可能會成為瓶頸，一般我們遇到此類網路IO瓶頸的問題，可以增加執行緒數來解決，開啟多執行緒除了可以減少由于網路I/O等待造成的影響，還可以充分利用CPU的多核優勢，Redis6.0也不例外，在此處增加了多執行緒來處理網路資料，以此來提高Redis的吞吐量，當然相關的命令處理還是單執行緒運行，不存在多執行緒下并發訪問帶來的種種問題，
性能對比
壓測配置:
Redis Server: 阿里云 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 記憶體，主機型號 ecs.ic5.2xlarge
Redis Benchmark Client: 阿里云 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 記憶體，主機型號 ecs.ic5.2xlarge多執行緒版本Redis 6.0，單執行緒版本是 Redis 5.0.5，多執行緒版本需要新增以下配置:
io-threads 4 # 開啟 4 個 IO 執行緒
io-threads-do-reads yes # 請求決議也是用 IO 執行緒壓測命令: redis-benchmark -h 192.168.0.49 -a foobared -t set,get -n 1000000 -r 100000000 --threads 4 -d ${datasize} -c 256
從上面可以看到 GET/SET 命令在多執行緒版本中性能相比單執行緒幾乎翻了一倍，另外，這些資料只是為了簡單驗證多執行緒 I/O 是否真正帶來性能優化，并沒有針對具體的場景進行壓測，資料僅供參考，本次性能測驗基于 unstble 分支，不排除后續發布的正式版本的性能會更好，
最后
可見單執行緒有單執行緒的好處，多執行緒有多執行緒的優勢，只有充分理解其中的本質原理，才能靈活運用于生產實踐當中，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/63370.html
標籤：Java
上一篇：Go-資料型別以及變數,常量