效能追擊：萬字長文30+圖揭祕8大主流伺服器程式執行緒模型 | Node.js,Apache,Nginx,Netty,Redis,Tomcat,MySQL,Zuul
阿新 • • 發佈：2021-03-10
> 本文為《[高效能網路程式設計遊記](https://www.itzhai.com/articles/decrypt-the-threading-model-of-common-server-programs.html)》的第六篇“效能追擊：萬字長文30+圖揭祕8大主流伺服器程式執行緒模型”。
最近拍的照片比較少，不知道配什麼圖好，於是自己畫了一個，湊合著用，讓大家見笑了。
本文我們來探索一下主流的各種應用伺服器的網路處理模型，看看大家都是怎麼設計網路程式的。在本文中，我會從Node.js、Apache Server、Nginx、Netty、Redis、Tomcat、MySQL、Zuul等常用的伺服器程式，給大家逐一分析，分析各種伺服器程式的效能，心中有數，才能手中有術，從此效能是熟客。
雖然涉及到很多底層知識，各種框架的原理，但是我都會盡量配上直白易懂的圖文，方便大家理解。
更多優質文章，讓我們相約在`IT宅`(itzhai.com)的`Java架構雜談`公眾號。
首先，我們從什麼都能寫的Javascript說起，來看看Node.js伺服器的併發內幕。
# 1、Node.js
上篇文章中，我們介紹了JavaScript在瀏覽器端的執行模式，接下來，我們繼續講講Node.js的執行模式，揭開它高效能背後的實現機制。
## 1.1、Node.js執行模式
以下是一個流傳度很廣的Node.js系統檢視，來源於 Totally Radical Richard[^1]
Node.js是單執行緒的Event Loop[^2]：
* V8引擎解析JS指令碼，呼叫Node API；
* libuv庫執行Node API，會先將API請求**封裝成事件**，放入事件佇列，**Event Loop執行緒處於空閒狀態時，就開始遍歷處理事件佇列中的事件**，對事件進行處理：
* 如果不是阻塞任務，直接處理得到結果，通過回撥函式返回給V8；
* 如果是阻塞任務，則從Worker執行緒池中取出一個執行緒，交給執行緒處理，最終執行緒把處理結果設定到事件的結果屬性中，**把事件放回事件佇列**，等待Event Loop執行緒執行回撥返回給V8引擎。
其中請求的任務會被封裝成如下的結構：[^3]
```javascript
varevent= createEvent({
params:request.params, // 傳遞請求引數
result:null, // 存放請求結果
callback:function(){} // 指定回撥函式
});
```
更多精彩討論，可以閱讀這個帖子：[How the single threaded non blocking IO model works in Node.js](https://stackoverflow.com/questions/14795145/how-the-single-threaded-non-blocking-io-model-works-in-node-js)[^10]，以下是來源於這個帖子的圖片：
> 當然了，在客戶端請求到Node.js伺服器的時候，肯定會有一個建立已連線套接字的過程，然後把這個已連線套接字描述符與具體的執行程式碼關聯起來，這樣再非同步處理完成之後，才知道要響應給哪個客戶端。
## 1.2、Node.js非同步案例
以上的執行模式說明還是需要結合例子來說明比較好理解。
如果沒有通過回撥函式進行非同步處理，我們可能會寫出如下程式碼：
```javascript
var result = db.query("select * from t_user");
// do something with result here...
console.log("do something else...");
```
這個程式碼在執行查詢result的時候，查詢速度可能很慢，等待查詢出結果後，才可以執行後面的console.log操作，因為這是在一個執行緒上執行的。
但是Node.js不是這麼玩的，Node.js的執行模式下，只有一個Event Loop執行緒，如果這個執行緒被阻塞，這將導致無法接收新的請求。為了避免這種情況，我們按照Node.js的回撥方式重寫程式碼：
```javascript
db.query("select * from t_user", function(rows) {
var result = rows;
// do something with result here...
});
console.log("do something else...");
```
現在，Node.js可以非同步處理查詢請求了，並且把**查詢請求委託給Worker Thread，等待Worker Thread得到查詢結果之後，再把結果連同回撥匿名函式封裝成事件釋出到事件佇列，等待Event Loop執行緒執行該回調函式**。這樣console.log程式碼就可以立刻得到執行，而不會因為查詢請求導致被阻塞住了。
## 1.3、Node.js併發模型優缺點
從以上分析可知，Node.js通過事件驅動，把阻塞的IO任務丟到執行緒池中進行非同步處理，也就是說，**Node.js適合I/O密集型任務**。
但是，如果碰到CPU密集型任務的時候，Node.js中的EventLoop執行緒就會自己處理任務，這樣會導致在事件佇列中的CPU密集型任務沒有處理完，那麼後面的任務就不會被執行到了，從而導致後續的請求響應變慢。
如下圖，本來socket2和socket3很快就可以處理完的，但是由於socket1的任務一直佔用著CPU時間，導致socket2和socket3都不能及時得到處理，從表現上看，就是響應變慢了。
如果CPU是單核的還好，充分的利用了CPU核心，但是如果CPU是多核的，這種情況就會導致其他記憶體處於閒置狀態，造成資源浪費。
所以，**Node.js不適合CPU密集型任務**。
> Node.js適合請求和響應內容小，無需大量計算邏輯的場景，這能夠充分發揮Node.js執行模式的優勢。類似的場景有聊天程式。
不過，從Node.js可以通過提供cluster、child_process API建立子程序的方式來充分利用多核的能力，但是多程序也就意味著犧牲了共享記憶體，並且通訊必須使用json進行傳輸。[^4]
Node.js V10.5.0開始，提供了worker_threads，讓Node.js擁有了多工作執行緒：Event Loop執行緒 + 自己啟動的執行緒，多工作執行緒對於CPU密集型的JavaScript操作非常有用。
需要注意的是，worker_threads可以作為Node.js中CPU密集型問題的解決策略之一，對於IO，Node.js原生執行緒(Event Loop執行緒)已經做了很好的支援，無需自己啟動一個執行緒去做此類工作(參考本節第一張圖片的介紹)。
好了，前端知識不能聊深了，聊深就出破綻了，畢竟也是有前端大佬在關注IT宅的`Java架構雜談`公眾號，在偷偷學學Java技術的。
接下來，我們從一根羽毛的故事說起。
# 2、Apache
Apache於1995年首次釋出，並迅速佔領了市場，成為世界上最受歡迎的Web伺服器。配合世界上最好的語言——PHP搭建網站，在那個年代可謂是打遍天下無敵手。
這裡我們來探討下Apache Web伺服器使用的兩個工作模型：
* Apache MPM Prefork：用於實現多程序模型；
* Apache MPM Worker：用於實現多執行緒模型；
> Apache使用到了**Multi Processing Module**模組(MPM)來實現多程序或者多執行緒處理器。
## 2.1、Apache MPM Prefork
一句話總結：**Prefork是一個非執行緒型的、預派生的MPM**。
Prefork預派生出多個程序，每個程序在某個確定的時間只單獨處理一個連線，效率高，但記憶體使用比較大。
這種模型是**每個請求一個程序**的模型，由一個父程序建立了許多子程序，這些子程序等待請求的到達並且進行處理，每個請求均由單獨的程序進行處理。
需要注意的是，每個程序都會使用RAM和CPU等系統資源，使用的RAM數量都是相等的。
如果同時有很多請求，那麼apache會產生很多子程序，這將導致大量的資源利用率。
## 2.2、Apache MPM Worker
一句話總結：**Worker是支援混合的多執行緒多程序的MPM**。如下圖：
子程序藉助內部固定數量的執行緒來處理請求，該數量由配置檔案中的引數“`ThreadsPerChild`指定。
該模型一般使用多個子程序，每個子程序有多個執行緒，每個執行緒在某個確定的時間只處理一個連線，消耗記憶體較少。這種Apache模型可以用較少的系統資源來滿足大量請求，因為這種模型下，有限數量的程序將為許多請求提供服務。
> **PHP攻城獅提問題：為啥mod_php中不能使用MPM Worker？**
>
> 由於一些mod_php模組問題，導致該模組不能和MPM Worker一起使用，PMP Worker一般都是跟apache的mod_fcgid 搭配，而PHP則是安裝php-cgi來執行。
作為一個Java攻城獅，這裡我就不展開繼續講了，畢竟世界上最好的語言相信大家會主動去了解的。
即使是一個請求用一個執行緒，Apache在高併發場景下，執行效率也是很差的。因為，如果一個請求需要資料庫中的一些資料以及磁碟中的檔案等涉及到IO操作的處理，則該執行緒將進入等待。因此，**Apache中的某些執行緒(Worker模式)或者程序(Prefork模式)只是停下來下來等待某些任務完成，這些執行緒或者程序吃掉了系統資源。**
而接下來我們介紹對併發場景處理更高效的主角：Nginx，**從根本上說，Apache和Nginx差別很大。Nginx的誕生是為了解決Apache中的c10k問題。**
想象以下，從豬圈裡衝出一群豬，Apache Server能夠抵擋得住嗎，也許不行，但是，Nginx，一定可以。這就是Nginx的強大之處。
# 3、Nginx
Nginx是一種開源Web伺服器，自從最初作為Web伺服器獲得成功以來，現在還用作反向代理，HTTP快取和負載均衡器。
Nginx旨在提供**低記憶體使用率**和高併發性。Nginx不會為每個Web請求建立新的流程，而是使用非同步的，事件驅動的方法，在單個執行緒中處理請求。
接下來我們就來詳細介紹下。
## 3.1、Nginx的程序模型
### 3.1.1、Nginx的程序數
我們在作業系統各種啟動Nginx之後，一般會發現幾個Nginx程序，如下圖：
這裡有一個master程序，3個workder程序。
為什麼啟動Nginx會有3個worker程序呢，這是因為我們在配置檔案中指定了工作程序數：
```
worker_processes 3;
```
## 3.2、程序模型
Nginx是多程序模型，在啟動Nginx之後，以daemon的方式在後臺執行，後臺程序包含一個Master程序和多個worker程序，模型如下：
> CM: Cache Manager, CL Cache Loader
Master程序主要用於管理Worker程序，主要負責如下功能：
* 接收外接訊號；
* 向Worker程序傳送訊號；
* 監控Worker程序執行狀態；
* Workder程序異常退出，會自動建立新的Worker程序。
Worker程序主要用於處理網路事件，我們一般設定的Worker程序數為機器的CPU核數，以最有效的利用硬體資源。為此，可以進行如下配置：
```
worker_processes auto;
```
**通過使用共享快取來實現子程序的快取，會話永續性，限流，會話日誌等。**
## 3.3、工作原理
大致來說，Master程序執行以下步驟：
```c
socket();
bind();
listen();
fork();
```
fork出若干個Worker程序，Worker進執行以下步驟：
```c
accept(); // accept_mutex鎖
register IO handler;
epoll() or kqueue();
handle_events();
...
```
> accept_mutex鎖作用：保證同一時刻只有一個Worker程序在accept連線，從而解決驚群問題。當客戶連線到達時候，只有成功獲取到了鎖的程序才會執行accept。[^6]
>
> 驚群問題[^5]：一個程式派生出N個子程序，它們各自呼叫accept並因此而被投入核心睡眠。當第一個客戶連線到達的時候，所有N個子程序均被喚醒，這是因為所有子程序所用的監聽描述符指向了同一個socket結構。儘管有N個子程序被喚醒，但是隻有最先執行的子程序獲得那個客戶連線，其餘的N-1個子程序繼續恢復睡眠。
當Nginx伺服器處於活動狀態的時候，僅Worker程序處於繁忙狀態，每個Worker程序以非阻塞方式處理多個連線。
每個Worker程序都是單執行緒的，並且獨立執行。當Worker程序獲取到連線之後就進行處理，程序可以使用`共享記憶體`進行通訊以及共享快取資料、會話永續性資料和其他共享資源。
我們重點來看看Worker程序的工作原理。
### 3.3.1、Worker程序工作原理
每個Worker程序都是運行於非阻塞、事件驅動的Reactor模型。
一個客戶端請求在服務端的大致處理流程如下圖所示：
我們在上一篇文章中詳細介紹了單執行緒版本的Reactor模型：
而Worker程序中基本的處理邏輯則如上圖所示：
* 當一個請求到達Workder程序的之後，Accept接收新連線，把新連線IO讀寫事件註冊到同步事件多路解複用器；
* 執行dispatch呼叫多路解複用器阻塞等待IO事件；
* 分發事件到特定的Handler中處理；
> 可是，這裡有個問題：**compute環節一般是要執行upstream的，這裡又會跟backend建立一個新的連線，進行請求互動，Worker程序豈不是會阻塞在這裡？**如果你來設計一個類似的事件驅動的程式，這種場景你會如何處理呢？
>
> 很顯然，為了發起與backend的連線請求導致程序被阻塞，這裡也是需要進行非同步操作的，可以把與backend的fd連線套接字與客戶端請求進來的fd連線套接字的關係維護起來。
### 3.3.2、如何處理繁重的工作？
與Node.js類似，Nginx中也會有一些繁重的工作。比如第三方模組中使用了阻塞呼叫，有時候該模組開發人員都沒有意識到這個阻塞呼叫的缺點，如果直接在Worker程序中執行，就會導致整個事件處理週期都被阻塞了，必須等待操作完成才可以繼續處理後續的事先。顯然，這不是我們期望的效果。
為了解決該問題，Nginx 1.7.11版本中實現了執行緒池機制。
#### 使用執行緒池機制解決繁重工作或者第三方阻塞操作效能問題
以下操作可能導致Nginx進入阻塞狀態：
* 處理冗長佔用大量CPU的處理；
* 阻塞訪問資源，如硬碟資源，互斥量，或者系統呼叫等，或者以同步方式從資料庫獲取資料
* ...
以上這些情況都需要執行比較長的時間，遇到這種情況，Nginx會將需要執行很長時間的任務放入執行緒池處理佇列中，通過執行緒池非同步處理這些任務：
通過引入執行緒池，從而消除了對Worker程序的阻塞，將Nginx的效能提升到了新的高度。更加重要的是，以前那些與Nginx不相容的第三方類庫，都可以相對容易的使用，並且不影響Nginx的效能。
## 3.4、優雅更新配置[^8]
我們在更新完Nginx的配置之後，一般執行以下命令即可：
```
nginx -s reload
```
這行命令會檢查磁碟上的配置，並向主程序傳送SIGNUP訊號。
主程序收到SIGNUP訊號時，會執行如下操作：
* 重新載入配置，並派生一組新的工作程序，這組新的工作程序立即開始接受連線並處理流量；
* 指示舊的工作程序正常退出，工作程序停止接收新連線，當前的每個請求處理完成之後，舊的工作程序就會關掉，一旦所有的連線關閉，工作程序就將退出。
這種重新載入配置過程可能導致CPU的記憶體使用量小幅度提升，但是這個效能犧牲是值得的。
## 3.5、優雅的升級
Nginx的二進位制升級過程也實現了不停服的效果。
升級過程與政策重新載入配置的方法型別，新的Nginx主程序與原始主程序並行執行，他們共享監聽套接字，兩個程序都處於活動狀態，他們各自的工作程序都在處理流量，然後可以可以指示舊的Master和Worker程序正常退出。
## 3.5、Nginx的優勢
在每個請求一個程序，阻塞式的連線方法中，每個連線都需要大量額外的資源開銷，並且會導致頻繁的上下文切換。
而Nginx的單程序模型，可以儘可能消耗少的記憶體，每個連線幾乎沒有額外的開銷，Nginx程序數可以設定為CPU核心數，上下文切換相對較少。
那麼問題來了，我們自己寫網路程式的時候，有沒有可以幫助我們提高網路效能的程式框架呢？有，那就是大名鼎鼎的Netty，接下來就來說他。
# 4、Netty
## 4.1、Netty主從Reactor模式
Netty也不例外，是基於Reactor模型設計和開發的。
Netty採用了主從Reactor模式，主Reactor只負責建立連線，獲取已連線套接字，然後把已連線套接字的IO事件轉給從Reactor執行緒進行處理。
我們再來回顧一下主從模式的圖示，更詳細的說明參考我的部落格 `IT宅(itzhai.com)` 或者功眾號 `Java架構雜談(itread)`中的文章更新 [網路程式設計正規化：高效能伺服器就這麼回事 | C10K,Event Loop,Reactor,Proactor](https://www.itzhai.com/articles/high-performance-network-programming-paradigm.html)[^9]
我們先來大致講講Netty中的幾個與Reactor有關的抽象概念：
* Selector：可以理解為一個Reactor執行緒，內部會通過IO多路複用感知事件的發生，然後把事件交代給Channel進行處理；
* Channel：註冊到Selector中的物件，代表Selector監聽的事件，如套接字讀寫事件；
具體上，Netty抽象出了以下模型進行實現Reactor主從模式：
* Boss Group，即主Reactor，服務於監聽套接字，其中的NioEventLoop運行於主Reactor執行緒，其中：
* Selector為IO多路解複用器，用於感知監聽套接字的Accept事件；
* ServerSocketChannel對應監聽套接字，這裡綁定了OP_ACCEPT已連線事件；
* Acceptor為已連線事件的處理器，接收到已連線事件之後，會通過Acceptor進行處理。
* Worker Group，即從Reactor，服務於已連線套接字，Worker Group中可以開啟多個NioEventLoop，每個NioEventLoop運行於一個從Reactor執行緒，其中：
* Selector為IO多路解複用器，用於感知已連線套接字的IO讀寫事件；
* SocketChannel對應已連線套接字，監聽套接字獲取到已連線套接字之後，會包裝成SocketChannel，註冊到Worker Group的NioEventLoop的Selector中進行監聽；
* Handler為IO讀寫事件的處理器，由API傳入，自定義業務處理邏輯，最終的IO事件會通過這個Handler進行處理。
> Netty基於Pipeline管道的模式來處理Channel事件，從Netty的使用API中也可以瞭解到。
## 4.2、Netty主從Reactor+Worker執行緒池模式
為了降低具體業務邏輯對從Reactor的影響，我們可以單獨把業務邏輯處理放到一個執行緒池中處理，這樣無論是對於監聽套接字的事件處理，還是對於已連線套接字事件的處理，都不會因為業務處理程式而導致阻塞了，如下圖所示，更詳細的說明參考我的部落格 `IT宅(itzhai.com)` 或者功眾號 `Java架構雜談(itread)`中的文章更新 [網路程式設計正規化：高效能伺服器就這麼回事 | C10K,Event Loop,Reactor,Proactor](https://www.itzhai.com/articles/high-performance-network-programming-paradigm.html)[^9]：
**我們可以通過建立一個 DefaultEventExecutorGroup 執行緒池來處理業務邏輯。**
大致程式框架如下圖所示：
```java
// 宣告一個bossGroup作為主Reactor，本質是一個執行緒池，每個執行緒是一個EventLoop
EventLoopGroup bossGroup = new NioEventLoopGroup();
// 宣告一個workerGroup作為從Reactor，本質是一個執行緒池，每個執行緒是一個EventLoop
EventLoopGroup workerGroup = new NioEventLoopGroup();
// 構建業務處理Group
DefaultEventExecutorGroup defaultEventExecutorGroup =
new DefaultEventExecutorGroup(10,
new ThreadFactory() {
private AtomicInteger threadIndex = new AtomicInteger(0);
@Override
public Thread newThread(Runnable r) {
return new Thread(r, "BusinessThread-" + this.threadIndex.incrementAndGet());
}
});
try {
// 建立服務端啟動類
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
...
.childHandler(new ChannelInitializer() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
// 在pipeline中新增自定義的handler
ch.pipeline().addLast(defaultEventExecutorGroup, new BizHandler());
}
});
ChannelFuture future = bootstrap.bind(port).sync();
future.channel().closeFuture().sync();
} finally {
bossGroup.shutdownGracefully();
workerGroup.shutdownGracefully();
}
```
**Netty是基於NIO的，而Java中的NIO是JDK1.4開始支援，內部是基於IO多路複用實現的，具體的實現思路不再詳細說，底層都是IO複用技術，通過Channel藉助於Buffer處理感知到的IO事件**。
> **有了NIO為啥還要有Netty？**
>
> 這是兩個不同層次的東西，NIO只是一個IO類庫，實現同步非阻塞IO，而Netty是基於NIO實現的高效能網路框架，基於主從Reactor設計的。
>
> NIO類庫API複雜，需要處理多執行緒程式設計，自己寫Reactor模式，並且客戶端斷線重連、半包讀寫，失敗快取、網路阻塞和異常碼流等問題處理起來難度很大。而Netty對於NIO遇到的這些問題都做了很好的封裝，主要優點體現在：
>
> * API使用簡單；
> * 封裝度高，功能強大，提供多種編碼解碼器，解決了TCP拆包粘包問題；
> * 基於Reactor模式實現，效能高，無需在自己實現Reactor了；
> * 商用專案多，經歷過很多考驗，社群活躍...
# 5、Redis
相信大家已經聽過無數遍“Redis是單執行緒的”這句話了，**Redis真的是單執行緒的嗎，又是如何支撐那麼大的併發量**，並且運用到了這麼多的網際網路應用中的呢？
其實，Redis的單執行緒指的是Redis內部會有一個主處理執行緒，充分利用了非阻塞、IO多路複用模型，實現的一個Reactor架構。但是在某些情況下，Redis會生成執行緒或者子程序來執行某些比較繁重的任務。
Redis包含了一個稱為`AE事件模型`的強大的非同步事件庫來包裝不同作業系統的IO複用技術，如epoll、kqueue、select等。
## 5.1、Redis執行緒模型
還是那個Reactor模型，只不過我們再次踏入了不同的國界，於是又出現了一種新的的表述方式。
Redis基於Reactor模型開發了網路事件處理器，這個處理器被稱為檔案事件處理器。不過叫什麼不重要，重要的是原理都是一樣的。以下是Redis的執行緒模型：
這個圖基本上涵蓋了Redis程序處理的主要事情：
* 客戶端A發起請求建立連線，監聽套接字Server Socket建立連線之後，產生一個AE_READABLE事件；
* 該事件被IO多路複用處理，放入事件佇列，最終被檔案事件分派器分派給了連線應答處理器進行處理：
* 連線應答處理器處理新連線，將FD1套接字的AE_READABLE事件與命令請求處理器關聯起來。
* 客戶端A最終在客戶端生成一個已連線套接字FD1；
* 客戶端A傳送命令請求，產生一個AE_READABLE事件，該事件被IO多路複用處理，放入事件佇列，最終被檔案事件分派器分派給了命令請求處理器進行處理：
* 命令請求處理器執行客戶端FD1套接字命令操作，得到結果，將結果寫入到套接字的回覆緩衝區中，準備好響應給客戶端；
* 同時將FD1套接字的AE_WRITABLE事件與命令回覆處理器關聯；
* 當FD1套接字準備好寫的時候，會產生一個AE_WRITABLE事件，該事件被IO多路複用處理，放入事件佇列，最終被事件分派器分派給了命令回覆處理器進行處理：
* 命令回覆處理器把結果輸出響應給客戶端的FD1已連線套接字；
* 然後將FD1套接字的AE_WRITABLE事件跟命令回覆處理器解除關聯。
大致一個互動流程就這樣完成了，是不是很簡單呢。
思路還是那個思路，但是實現卻百花齊放。就好像如果有人覺得我的文章寫得好，都會表示支援，但是支援的方式卻各有不同，有的人會偷偷的收藏起來白嫖，有的人會點個贊，有的人會點個在看，也有的人會積極分享，點選Java架構雜談進行關注星標，訪問IT宅itzhai.com進一步閱讀。
這個Reactor模型沒有哪個伺服器程式實現是最好的一說，但是對於我來說，你的點贊，關注，評論，轉發就是最好的支援。
## 5.2、為啥Redis單執行緒也這麼高效？
前面已經講了這麼多Reactor模式的好處，詳細大家心裡也有個底了，大致總結下：
* Redis是存記憶體操作的，所以處理速度非常快，這同時也跟Redis高效的資料結構有關，不過本文重點是講網路相關的，資料結構不展開講；
* Redis的瓶頸不在CPU，而是在記憶體和網路。而基於Reactor模型，實現了非阻塞的IO多路複用，儘可能高效的利用了CPU，避免不必要的阻塞；
* 單執行緒反而避免了上下文切換的開銷。
對於開發人員來說，最關注的一點就是：單執行緒降低了開發的複雜度，再也不需要處理各種競態條件了，就連Hash的惰性Rehash，Lpush等執行緒不安全的命令都可以進行無鎖程式設計了。
頭髮都可以少掉幾根，難怪Redis的作者跟我說，Redis更強了，而我卻沒有禿，反而更帥了[^11]。
## 5.3、Redis真的是單執行緒的嗎？
我再問一句大家，Redis真的是單執行緒的嗎，從Reactor模型上來說，單執行緒肯定會存在瓶頸的，還不清楚的盆友可以回去翻看我IT宅(itzhai.com)上面的相關文章，或者Java架構雜談上面的文章。
比如 UNLINK、FLUSHALL ASYNC、FLUSHDB ASYNC等非阻塞的刪除操作，如果要釋放的記憶體空間比較大，就需要耗費比較多的時間進行處理，這些操作就會阻塞住待處理的執行緒。而如果是單執行緒模型，可想而知，整個Redis服務的請求都會被阻塞住了；
為此，Redis引入了多執行緒機制。
### Redis 4.0初步引入多執行緒
在Redis 4.0中，Redis開始使具有更多執行緒。這個版本僅限於在後臺刪除物件，其中包括非阻塞的刪除操作。
> UNLINK操作，只會將鍵從元資料中刪除，並不會立刻刪除資料，真正的刪除操作會在一個後臺執行緒非同步執行。
### Redis 6.0真正引入多執行緒
雖然基於Reactor模型，單執行緒也可以支援很大的併發量，但是要是IO讀寫多了，待處理的已連線套接字多了，需要執行的命令也多了，那麼，單執行緒依舊是瓶頸，這個時候我們就要引入主從Reactor模型，甚至主從Reactor模型+Worker執行緒池了。
再次強調下，這塊知識點落下的同學，可以閱讀我的部落格 `IT宅(itzhai.com)` 或者功眾號 `Java架構雜談(itread)`中的文章更新 [網路程式設計正規化：高效能伺服器就這麼回事 | C10K,Event Loop,Reactor,Proactor](https://www.itzhai.com/articles/high-performance-network-programming-paradigm.html)[^9]。
在Redis 6.0中，如果要開啟多執行緒，可以進行設定：
```
io-threads 執行緒數
io-threads-do-reads yes // 預設IO執行緒只會用於寫操作，如果要在讀操作和協議解析的時候啟用IO執行緒，則可以設定該選項為yes，但是Redis團隊聲稱它並沒有多大幫忙
```
不過呢，**Redis為了避免產生執行緒併發安全的問題，在執行命令階段仍然是單執行緒順序執行的，只是在網路資料讀寫和協議解析階段才用到了多執行緒。**
為了進一步瞭解這個特性，我們可以閱讀以下 redis.conf[^12] 配置檔案的說明。在這裡，這個特性被命名為：`THREADED I/O`，下面是翻譯整理自裡面的一些說明。
#### **THREADED I/O**
Redis大多是單執行緒的，但是有一些執行緒操作，例如UNLINK，執行緩慢的I/O訪問等是在後臺執行緒上執行的操作。
但是現在，可以在不同的I/O執行緒中處理Redis客戶端套接字的讀寫。 由於特別慢的寫入速度，因此Redis使用者通常使用pipelining流水線以加快每個核心的Redis效能，並生成多個例項以擴大規模。 而使用I/O執行緒可以輕鬆地將Redis寫入速度提升2倍。
IO執行緒預設是禁用的，建議在至少有4個核心的機器上啟用，至少保留一個備用核心。也就是說，如果您的CPU是4核的，請嘗試使用2~3個IO執行緒。
```
io-threads 4
```
**將io-threads設定為1只會像傳統一樣只啟用單執行緒。**
使用8個以上的執行緒不會有太大幫助，並且建議實際存在效能問題的時候才使用IO執行緒，否則就沒有必要使用了。
啟用IO執行緒後，我們僅將IO執行緒用於寫操作，即對write(2)系統呼叫進行執行緒化並將客戶端緩衝區傳輸到套接字。 但是，也可以使用以下配置指令通過以下方式啟用讀取執行緒和協議解析：
> io-threads-do-reads yes
**通常，執行緒讀取沒有太大幫助。**
**Redis用的是類似單執行緒版的Reactor + IO執行緒池(Worker執行緒池)**，不過與我們前面提到的單執行緒Reactor + Worker執行緒池模式有所不同，再回顧下Reactor + Worker執行緒池模式：
Redis是在所謂的Reactor執行緒(主執行緒)中把IO讀事件一批一批的交給IO執行緒池進行讀取，讀取完畢之後，統一執行所有請求的命令，然後才是一次性把所有請求的響應寫到socket，如下圖所示：
等待佇列中的待處理時間平均分給每個IO執行緒，IO執行緒池只是負責IO讀寫和解析資料，IO執行緒池充分利用了CPU多核處理的能力，提高了IO讀寫速度。所以，我們再來強調一次重點：**Redis為了避免產生執行緒併發安全的問題，在執行命令階段仍然是單執行緒順序執行的，只是在網路資料讀寫和協議解析階段才用到了多執行緒。**
#### Redis 6.0真的是單執行緒的嗎？
可以發現，Redis也不是簡單粗暴的引入多執行緒機制，而是基於避免引入併發操作的複雜度的前提下，進行的合理改良設計實現的，這樣才能保護頭髮，避免頭髮脫落的太快呀，程式設計師都需要重點關注這個...
如果真有人要跟你追究Redis是不是單執行緒的，**你要記住的是，即使是Redis 6.0，執行命令的過程仍然是單執行緒的。**
# 6、Tomcat
作為一個Java程式設計師，怎麼能不認識Tomcat呢，Tomcat的執行緒模型又是怎樣的？不用往下看，我們都能猜出Tomcat肯定會利用Reactor模式來優化網路處理，不過這個優化過程卻是跟隨者技術的發展慢慢演變的。
## 6.1、Tomcat整體架構[^13]
Tomcat是HTTP伺服器，同時還是一個Servlet容器，可以執行Java Servlet，並將JavaServer Pages（JSP）和JavaServerFaces（JSF）轉換為Java Servlet。
我們先來看看Tomcat各個元件的整體架構。Tomcat採用了分層和模組化的體系結構，如下所示，這個結構有點像套娃，一層套一層的，這也同時是Tomcat server.xml配置檔案的層級結構：
Server是頂層元件，代表著一個Tomcat例項，在配置檔案中一般如下：
```xml
......