一文弄懂Redis為什么這么快？
前言
說起當前主流NoSql數據庫非 Redis 莫屬。因為它讀寫速度極快，一般用于緩存熱點數據加快查詢速度，大家在工作里面也肯定和 Redis 打過交道，但是對于Redis 為什么快，除了對八股文的背誦，好像都還沒特別深入的了解。
今天我們一起深入的了解下redis吧：
高效的數據結構
Redis 的底層數據結構一共有6種，分別是，簡單動態字符串，雙向鏈表，壓縮列表，哈希表，跳表和整數數組，它們和數據類型的對應關系如下圖所示：
本文暫時按下不表，后續會針對以上所有數據結構進行源碼級深入分析
單線程vs多線程
多線程VS單線程
在學習計算機操作系統時一定遇到過這個問題：多線程一定比單線程快嗎? 相信各位看官們一定不會像上面的傻哪吒一樣落入敖丙的圈套中。
多線程有時候確實比單線程快，但也有很多時候沒有單線程那么快。首先用一張3歲小孩都能看懂的圖解釋并發與并行的區別：
- 并發(concurrency)：指在同一時刻只能有一條指令執行，但多個進程指令被快速的輪換執行，使得在宏觀上具有多個進程同時執行的效果，但在微觀上并不是同時執行的，只是把時間分成若干段，使多個進程快速交替的執行。
- 并行(parallel)：指在同一時刻，有多條指令在多個處理器上同時執行。所以無論從微觀還是從宏觀來看，二者都是一起執行的。
不難發現并發在同一時刻只有一條指令執行，只不過進程(線程)在CPU中快速切換，速度極快，給人看起來就是“同時運行”的印象，實際上同一時刻只有一條指令進行。但實際上如果我們在一個應用程序中使用了多線程，線程之間的輪換以及上下文切換是需要花費很多時間的。
何同學
Talk is cheap,Show me the code
如下代碼演示了串行和并發執行并累加操作的時間：
- public class ConcurrencyTest {
- private static final long count = 1000000000;
- public static void main(String[] args) {
- try {
- concurrency();
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- serial();
- }
- private static void concurrency() throws InterruptedException {
- long start = System.currentTimeMillis();
- Thread thread = new Thread(new Runnable() {
- @Override
- public void run() {
- int a = 0;
- for (long i = 0; i < count; i++)
- {
- a += 5;
- }
- }
- });
- thread.start();
- int b = 0;
- for (long i = 0; i < count; i++) {
- b--;
- }
- thread.join();
- long time = System.currentTimeMillis() - start;
- System.out.println("concurrency : " + time + "ms,b=" + b);
- }
- private static void serial() {
- long start = System.currentTimeMillis();
- int a = 0;
- for (long i = 0; i < count; i++)
- {
- a += 5;
- }
- int b = 0;
- for (long i = 0; i < count; i++) {
- b--;
- }
- long time = System.currentTimeMillis() - start;
- System.out.println("serial : " + time + "ms,b=" + b);
- }
- }
執行時間如下表所示，不難發現，當并發執行累加操作不超過百萬次時，速度會比串行執行累加操作要慢。
由于線程有創建和上下文切換的開銷，導致并發執行的速度會比串行慢的情況出現。
上下文切換
多個線程可以執行在單核或多核CPU上，單核CPU也支持多線程執行代碼，CPU通過給每個線程分配CPU時間片(機會)來實現這個機制。CPU為了執行多個線程，就需要不停的切換執行的線程，這樣才能保證所有的線程在一段時間內都有被執行的機會。
此時，CPU分配給每個線程的執行時間段，稱作它的時間片。CPU時間片一般為幾十毫秒。CPU通過時間片分配算法來循環執行任務，當前任務執行一個時間片后切換到下一個任務。
但是，在切換前會保存上一個任務的狀態，以便下次切換回這個任務時，可以再加載這個任務的狀態。所以任務從保存到再加載的過程就是一次上下文切換。
根據多線程的運行狀態來說明：多線程環境中，當一個線程的狀態由Runnable轉換為非Runnable(Blocked、Waiting、Timed_Waiting)時，相應線程的上下文信息(包括CPU的寄存器和程序計數器在某一時間點的內容等)需要被保存，以便相應線程稍后再次進入Runnable狀態時能夠在之前的執行進度的基礎上繼續前進。而一個線程從非Runnable狀態進入Runnable狀態可能涉及恢復之前保存的上下文信息。這個對線程的上下文進行保存和恢復的過程就被稱為上下文切換。
基于內存
以MySQL為例，MySQL的數據和索引都是持久化保存在磁盤上的，因此當我們使用SQL語句執行一條查詢命令時，如果目標數據庫的索引還沒被加載到內存中，那么首先要先把索引加載到內存，再通過若干尋址定位和磁盤I/O，把數據對應的磁盤塊加載到內存中，最后再讀取數據。
如果是機械硬盤，那么首先需要找到數據所在的位置，即需要讀取的磁盤地址。可以看看這張示意圖：
磁盤結構示意圖
讀取硬盤上的數據，第一步就是找到所需的磁道，磁道就是以中間軸為圓心的圓環，首先我們需要找到所需要對準的磁道，并將磁頭移動到對應的磁道上，這個過程叫做尋道。
然后，我們需要等到磁盤轉動，讓磁頭指向我們需要讀取的數據開始的位置，這里耗費的時間稱為旋轉延遲，平時我們說的硬盤轉速快慢，主要影響的就是耗費在這里的時間，而且這個轉動的方向是單向的，如果錯過了數據的開頭位置，就必須等到盤片旋轉到下一圈的時候才能開始讀。
最后，磁頭開始讀取記錄著磁盤上的數據，這個原理其實與光盤的讀取原理類似，由于磁道上有一層磁性介質，當磁頭掃過特定的位置，磁頭感應不同位置的磁性狀態就可以將磁信號轉換為電信號。
可以看到，無論是磁頭的移動還是磁盤的轉動，本質上其實都是機械運動，這也是為什么這種硬盤被稱為機械硬盤，而機械運動的效率就是磁盤讀寫的瓶頸。
扯得有點遠了，我們說回redis，如果像Redis這樣把數據存在內存中，讀寫都直接對數據庫進行操作，天然地就比硬盤數據庫少了到磁盤讀取數據的這一步，而這一步恰恰是計算機處理I/O的瓶頸所在。
在內存中讀取數據，本質上是電信號的傳遞，比機械運動傳遞信號要快得多。
硬盤數據庫讀取流程
內存數據庫讀取流程
因此，可以負責任地說，Redis這么快當然跟它基于內存運行有著很大的關系。但是，這還遠遠不是全部的原因。
Redis FAQ
面對單線程的 Redis 你也許又會有疑問：敖丙，我的多核CPU發揮不了作用了呀!別急，Redis 針對這個問題專門進行了解答。
CPU成為Redis性能瓶頸的情況并不常見，因為Redis通常會受到內存或網絡的限制。例如，在 Linux 系統上使用流水線 Redis 每秒甚至可以提供 100 萬個請求，所以如果你的應用程序主要使用O(N)或O(log(N))命令，它幾乎不會占用太多的CPU。
然而，為了最大化CPU利用率，你可以在同一個節點中啟動多個Redis實例，并將它們視為不同的Redis服務。在某些情況下，一個單獨的節點可能是不夠的，所以如果你想使用多個cpu，你可以開始考慮一些更早的分片方法。
你可以在Partitioning頁面中找到更多關于使用多個Redis實例的信息。
然而，在Redis 4.0中，我們開始讓Redis更加線程化。目前這僅限于在后臺刪除對象，以及阻塞通過Redis模塊實現的命令。對于未來的版本，我們的計劃是讓Redis變得越來越多線程。
注意：我們一直說的 Redis 單線程，只是在處理我們的網絡請求的時候只有一個線程來處理，一個正式的Redis Server運行的時候肯定是不止一個線程的!
例如Redis進行持久化的時候會 fork了一個子進程 執行持久化操作
四種IO模型
當一個網絡IO發生(假設是read)時，它會涉及兩個系統對象，一個是調用這個IO的進程，另一個是系統內核。
當一個read操作發生時，它會經歷兩個階段：
①等待數據準備;
②將數據從內核拷貝到進程中。
為了解決網絡IO中的問題，提出了4中網絡IO模型：
- 阻塞IO模型
- 非阻塞IO模型
- 多路復用IO模型
- 異步IO模型
阻塞和非阻塞的概念描述的是用戶線程調用內核IO操作的方式：阻塞時指IO操作需要徹底完成后才返回到用戶空間;而非阻塞是指IO操作被調用后立即返回給用戶一個狀態值，不需要等到IO操作徹底完成。
阻塞IO模型
在Linux中，默認情況下所有socket都是阻塞的，一個典型的讀操作如下圖所示：
當應用進程調用了recvfrom這個系統調用后，系統內核就開始了IO的第一個階段：準備數據。
對于網絡IO來說，很多時候數據在一開始還沒到達時(比如還沒有收到一個完整的TCP包)，系統內核就要等待足夠的數據到來。而在用戶進程這邊，整個進程會被阻塞。
當系統內核一直等到數據準備好了，它就會將數據從系統內核中拷貝到用戶內存中，然后系統內核返回結果，用戶進程才解除阻塞的狀態，重新運行起來。所以，阻塞IO模型的特點就是在IO執行的兩個階段(等待數據和拷貝數據)都被阻塞了。
非阻塞IO模型
在Linux中，可以通過設置socket使IO變為非阻塞狀態。當對一個非阻塞的socket執行read操作時，讀操作流程如下圖所示：
從圖中可以看出，當用戶進程發出 read 操作時，如果內核中的數據還沒有準備好，那么它不會阻塞用戶進程，而是立刻返回一個錯誤。
從用戶進程角度講，它發起一個read操作后，并不需要等待，而是馬上就得到了一個結果。當用戶進程判斷結果是一個錯誤時，它就知道數據還沒有準備好，于是它可以再次發送read操作。
一旦內核中的數據準備好了，并且又再次收到了用戶進程的系統調用，那么它馬上就將數據復制到了用戶內存中，然后返回正確的返回值。
所以，在非阻塞式IO中，用戶進程其實需要不斷地主動詢問kernel數據是否準備好。非阻塞的接口相比阻塞型接口的顯著差異在于被調用之后立即返回。
多路復用IO模型
多路IO復用，有時也稱為事件驅動IO(Reactor設計模式)。它的基本原理就是有個函數會不斷地輪詢所負責的所有socket，當某個socket有數據到達了，就通知用戶進程，多路IO復用模型的流程如圖所示：
當用戶進程調用了select，那么整個進程會被阻塞，而同時，內核會"監視"所有select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操作，將數據從內核拷貝到用戶進程。
這個模型和阻塞IO的模型其實并沒有太大的不同，事實上還更差一些。因為這里需要使用兩個系統調用(select和recvfrom)，而阻塞IO只調用了一個系統調用(recvfrom)。但是，用select的優勢在于它可以同時處理多個連接。所以，如果系統的連接數不是很高的話，使用select/epoll的web server不一定比使用多線程的阻塞IO的web server性能更好，可能延遲還更大;select/epoll的優勢并不是對單個連接能處理得更快，而是在于能處理更多的連接。
如果select()發現某句柄捕捉到了"可讀事件"，服務器程序應及時做recv()操作，并根據接收到的數據準備好待發送數據，并將對應的句柄值加入writefds，準備下一次的"可寫事件"的select()檢測。同樣，如果select()發現某句柄捕捉到"可寫事件"，則程序應及時做send()操作，并準備好下一次的"可讀事件"檢測準備。
如下圖展示了基于事件驅動的工作模型，當不同的事件產生時handler將感應到并執行相應的事件，像一個多路開關似的。
IO多路復用是最常使用的IO模型，但是其異步程度還不夠“徹底”，因為它使用了會阻塞線程的select系統調用。因此IO多路復用只能稱為異步阻塞IO，而非真正的異步IO。
異步IO模型
“真正”的異步IO需要操作系統更強的支持。如下展示了異步 IO 模型的運行流程(Proactor設計模式)：
用戶進程發起read操作之后，立刻就可以開始去做其他的事;而另一方面，從內核的角度，當它收到一個異步的read請求操作之后，首先會立刻返回，所以不會對用戶進程產生任何阻塞。
然后，內核會等待數據準備完成，然后將數據拷貝到用戶內存中，當這一切都完成之后，內核會給用戶進程發送一個信號，返回read操作已完成的信息。
IO模型總結
調用阻塞IO會一直阻塞住對應的進程直到操作完成，而非阻塞IO在內核還在準備數據的情況下會立刻返回。
兩者的區別就在于同步IO進行IO操作時會阻塞進程。按照這個定義，之前所述的阻塞IO、非阻塞IO及多路IO復用都屬于同步IO。實際上，真實的IO操作，就是例子中的recvfrom這個系統調用。
非阻塞IO在執行recvfrom這個系統調用的時候，如果內核的數據沒有準備好，這時候不會阻塞進程。但是當內核中數據準備好時，recvfrom會將數據從內核拷貝到用戶內存中，這個時候進程則被阻塞。
而異步IO則不一樣，當進程發起IO操作之后，就直接返回，直到內核發送一個信號，告訴進程IO已完成，則在這整個過程中，進程完全沒有被阻塞。
各個IO模型的比較如下圖所示：
Redis中的應用
Redis服務器是一個事件驅動程序，服務器需要處理以下兩類事件：
- 文件事件：Redis服務端通過套接字與客戶端(或其他Redis服務器)進行連接，而文件事件就是服務器對套接字操作的抽象。服務器與客戶端(或者其他服務器)的通信會產生相應的文件事件，而服務器則通過監聽并處理這些事件來完成一系列網絡通信操作。
- 時間事件：Redis服務器中的一些操作(如serverCron)函數需要在給定的時間點執行，而時間事件就是服務器對這類定時操作的抽象。
I/O多路復用程序
Redis的 I/O 多路復用程序的所有功能都是通過包裝常見的select、epoll、evport、kqueue這些多路復用函數庫來實現的。
因為Redis 為每個 I/O 多路復用函數庫都實現了相同的API，所以I/O多路復用程序的底層實現是可以互換的。
Redis 在 I/O 多路復用程序的實現源碼中用 #include 宏定義了相應的規則，程序會在編譯時自動選擇系統中性能最高的 I/O 多路復用函數庫來作為 Redis 的 I/O 多路復用程序的底層實現(ae.c文件)：
- /* Include the best multiplexing layer supported by this system.
- * The following should be ordered by performances, descending. */
- #ifdef HAVE_EVPORT
- #include "ae_evport.c"
- #else
- #ifdef HAVE_EPOLL
- #include "ae_epoll.c"
- #else
- #ifdef HAVE_KQUEUE
- #include "ae_kqueue.c"
- #else
- #include "ae_select.c"
- #endif
- #endif
- #endif
文件事件處理器
Redis基于 Reactor 模式開發了自己的網絡事件處理器：這個處理器被稱為文件事件處理器：
- 文件事件處理器使用 I/O 多路復用程序來同時監聽多個套接字，并根據套接字目前執行的任務來為套接字關聯不同的事件處理器。
- 當被監聽的套接字準備好執行連接應答(accept)、讀取(read)、寫入(write)、關閉(close)等操作時，與操作相對應的文件事件就會產生，這時文件事件處理器就會調用套接字之前關聯好的事件處理器來處理這些事件。
下圖展示了文件事件處理器的四個組成部分：套接字、I/O多路復用程序、文件事件分派器(dispatcher)、事件處理器。
文件事件是對套接字操作的抽象，每當一個套接字準備好執行連接應答、寫入、讀取、關閉等操作時，就會產生一個文件事件。因為一個服務器通常會連接多個套接字，所以多個文件事件有可能會并發地出現。I/O 多路復用程序負責監聽多個套接字，并向文件事件分派器傳送那些產生了事件的套接字。
哪吒問的問題很棒，聯想一下，生活中一群人去食堂打飯，阿姨說的最多的一句話就是：排隊啦!排隊啦!一個都不會少!
沒錯，一切來源生活!Redis 的 I/O多路復用程序總是會將所有產生事件的套接字都放到一個隊列里面，然后通過這個隊列，以有序、同步、每次一個套接字的方式向文件事件分派器傳送套接字。當上一個套接字產生的事件被處理完畢之后，I/O 多路復用程序才會繼續向文件事件分派器傳送下一個套接字。
Redis為文件事件處理器編寫了多個處理器，這些事件處理器分別用于實現不同的網絡通信需求：
- 為了對連接服務器的各個客戶端進行應答，服務器要為監聽套接字關聯連接應答處理器;
- 為了接受客戶端傳來的命令請求，服務器要為客戶端套接字關聯命令請求處理器 ;
- 為了向客戶端返回命令的執行結果，服務器要為客戶端套接字關聯命令回復處理器 ;
- 當主服務器和從服務器進行復制操作時，主從服務器都需要關聯特別為復制功能編寫的復制處理器。
連接應答處理器
networking.c/acceptTcpHandler函數是Redis的連接應答處理器，這個處理器用于對連接服務器監聽套接字的客戶端進行應答，具體實現為sys/socket.h/acccept函數的包裝。
當Redis服務器進行初始化的時候，程序會將這個連接應答處理器和服務器監聽套接字的AE_READABLE時間關聯起來，當有客戶端用sys/socket.h/connect函數連接服務器監聽套接字的時候，套接字就會產生AE_READABLE事件，引發連接應答處理器執行，并執行相應的套接字應答操作。
命令請求處理器
networking.c/readQueryFromClient函數是Redis的命令請求處理器，這個處理器負責從套接字中讀入客戶端發送的命令請求內容，具體實現為unistd.h/read函數的包裝。
當一個客戶端通過連接應答處理器成功連接到服務器之后，服務器會將客戶端套接字的AE_READABLE事件和命令請求處理器關聯起來，當客戶端向服務器發送命令請求的時候，套接字就會產生AE_READABLE事件，引發命令請求處理器執行，并執行相應的套接字讀入操作。
在客戶端連接服務器的整個過程中，服務器都會一直為客戶端套接字AE_READABLE事件關聯命令請求處理器。
命令回復處理器
networking.c/sendReplyToClient函數是Redis的命令回復處理器，這個處理器負責從服務器執行命令后得到的命令回復通過套接字返回給客戶端，具體實現為unistd.h/write函數的包裝。
當服務器有命令回復需要傳送給客戶端的時候，服務器會將客戶端套接字的AE_WRITABLE事件和命令回復處理器關聯起來，當客戶端準備好接收服務器傳回的命令回復時，就會產生AE_WRITABLE事件，引發命令回復處理器執行，并執行相應的套接字寫入操作。
當命令回復發送完畢之后，服務器就會解除命令回復處理器與客戶端套接字的AE_WRITABLE事件之間的關聯。
小總結
一句話描述 IO 多路復用在 Redis 中的應用：Redis 將所有產生事件的套接字都放到一個隊列里面，以有序、同步、每次一個套接字的方式向文件事件分派器傳送套接字，文件事件分派器根據套接字對應的事件選擇響應的處理器進行處理，從而實現了高效的網絡請求。
Redis的自定義協議
Redis客戶端使用RESP(Redis的序列化協議)協議與Redis的服務器端進行通信。它實現簡單，解析快速并且人類可讀。
RESP 支持以下數據類型：簡單字符串、錯誤、整數、批量字符串和數組。
RESP 在 Redis 中用作請求-響應協議的方式如下：
- 客戶端將命令作為批量字符串的 RESP 數組發送到 Redis 服務器。
- 服務器根據命令實現以其中一種 RESP 類型進行回復。
在 RESP 中，某些數據的類型取決于第一個字節：
- 對于簡單字符串，回復的第一個字節是“+”
- 對于錯誤，回復的第一個字節是“-”
- 對于整數，回復的第一個字節是“:”
- 對于批量字符串，回復的第一個字節是“$”
- 對于數組，回復的第一個字節是“*”
此外，RESP 能夠使用稍后指定的批量字符串或數組的特殊變體來表示 Null 值。在 RESP 中，協議的不同部分總是以“\r\n”(CRLF)終止。
下面只簡單介紹字符串的編碼方式和錯誤的編碼方式，詳情可以查看 Redis 官網對 RESP 進行了詳細的說明。
簡單字符串
用如下方法編碼：一個“+”號后面跟字符串，最后是“\r\n”，字符串里不能包含"\r\n"。簡單字符串用來傳輸比較短的二進制安全的字符串。例如很多redis命令執行成功會返回“OK”，用RESP編碼就是5個字節：
- "+OK\r\n"
想要發送二進制安全的字符串，需要用RESP的塊字符串。當redis返回了一個簡單字符串的時候，客戶端庫需要給調用者返回“+”號(不含)之后CRLF之前(不含)的字符串。
RESP錯誤
RESP 有一種專門為錯誤設計的類型。實際上錯誤類型很像RESP簡單字符串類型，但是第一個字符是“-”。簡單字符串類型和錯誤類型的區別是客戶端把錯誤類型當成一個異常，錯誤類型包含的字符串是異常信息。格式是：
- "-Error message\r\n"
有錯誤發生的時候才會返回錯誤類型，例如你執行了一個對于某類型錯誤的操作，或者命令不存在等。當返回一個錯誤類型的時候客戶端庫應該發起一個異常。下面是一個錯誤類型的例子
- -ERR unknown command 'foobar' -WRONGTYPE Operation against a key holding the wrong kind of value
“-”號之后空格或者換行符之前的字符串代表返回的錯誤類型，這只是慣例，并不是RESP要求的格式。例如ERR是一般錯誤，WRONGTYPE是更具體的錯誤表示客戶端的試圖在錯誤的類型上執行某個操作。這個稱為錯誤前綴，能讓客戶端更方便的識別錯誤類型。
客戶端可能為不同的錯誤返回不同的異常，也可能只提供一個一般的方法來捕捉錯誤并提供錯誤名。但是不能依賴客戶端提供的這些特性，因為有的客戶端僅僅返回一般錯誤，比如false。
高性能 Redis 協議分析器
盡管 Redis 的協議非常利于人類閱讀， 定義也很簡單， 但這個協議的實現性能仍然可以和二進制協議一樣快。
因為 Redis 協議將數據的長度放在數據正文之前， 所以程序無須像 JSON 那樣， 為了尋找某個特殊字符而掃描整個 payload ， 也無須對發送至服務器的 payload 進行轉義(quote)。
程序可以在對協議文本中的各個字符進行處理的同時， 查找 CR 字符， 并計算出批量回復或多條批量回復的長度， 就像這樣：
- #include <stdio.h>
- int main(void) {
- unsigned char *p = "$123\r\n";
- int len = 0;
- p++;
- while(*p != '\r') {
- len = (len*10)+(*p - '0');
- p++;
- }
- /* Now p points at '\r', and the len is in bulk_len. */
- printf("%d\n", len);
- return 0;
- }
得到了批量回復或多條批量回復的長度之后， 程序只需調用一次 read 函數， 就可以將回復的正文數據全部讀入到內存中， 而無須對這些數據做任何的處理。在回復最末尾的 CR 和 LF 不作處理，丟棄它們。
Redis 協議的實現性能可以和二進制協議的實現性能相媲美， 并且由于 Redis 協議的簡單性， 大部分高級語言都可以輕易地實現這個協議， 這使得客戶端軟件的 bug 數量大大減少。
冷知識：redis到底有多快?
在成功安裝了Redis之后，Redis自帶一個可以用來進行性能測試的命令 redis-benchmark，通過運行這個命令，我們可以模擬N個客戶端同時發送請求的場景，并監測Redis處理這些請求所需的時間。
根據官方的文檔，Redis經過在60000多個連接中進行了基準測試，并且仍然能夠在這些條件下維持50000 q/s的效率，同樣的請求量如果打到MySQL上，那肯定扛不住，直接就崩掉了。也是因為這個原因，Redis經常作為緩存存在，能夠起到對數據庫的保護作用。
官方給的Redis效率測試統計圖[1](橫坐標是連接數量，縱坐標是QPS)
可以看出來啊，Redis號稱十萬吞吐量確實也沒吹牛，以后大家面試的時候也可以假裝不經意間提一嘴這個數量級，發現很多人對“十萬級“、”百萬級“這種量級經常亂用，能夠比較精準的說出來也是一個加分項呢。
我是敖丙，你知道的越多，你不知道的越多，我們下期見!
