[[273908]]

Redis 是一種基于鍵值對 (Key-Value) 的 NoSQL 數據庫，Redis 的 Value 可以由 String，hash，list，set，zset，Bitmaps，HyperLogLog 等多種數據結構和算法組成。Redis 還提供了鍵過期，發布訂閱，事務，Lua腳本，哨兵，Cluster 等功能。Redis 執行命令的速度非常快，根據官方給的性能可以達到 10w+ QPS。那么本文主要介紹到底 Redis 快在哪里，主要有以下幾點：

開發語言現在我們都用高級語言來編程，比如 Java、Python 等。也許你會覺得 C 語言很古老，但是它真的很有用，畢竟 Unix 系統就是用 C 實現的。所以 C 語言是非常貼近操作系統的語言。Redis 就是用 C 語言開發的，所以執行會比較快。

另外多說一句，大學生們好好學 C，會讓你更好的理解計算機操作系統。別覺得學了高級語言就可以不用關注底層，欠的債總歸要還的。此處推薦一本比較難啃的書 《深入理解計算系統》。

純內存訪問Redis 將所有數據放在內存中，非數據同步正常工作中，是不需要從磁盤讀取數據的，0 次 IO。內存響應時間大約為 100 納秒，這是 Redis 速度快的重要基礎。先看看 CPU 的速度：

拿我的電腦來說，主頻是 3.1G，也就是說每秒可以執行 3.1*10^9 個指令。所以說 CPU 看世界是非常非常慢的，內存比它慢百倍，磁盤比他慢百萬倍，你說快不快?

借了一張 《深入理解計算機系統》 的圖，展示了一個典型的存儲器層次結構，在 L0 層，CPU 可以在一個時鐘周期訪問到，基于 SRAM 的高速緩存存續期，可以在幾個 CPU 時鐘周期訪問到，然后是基于 DRAM 的主存，可以在幾十到幾百個時鐘周期訪問到他們。

單線程單線程簡化算法的實現，并發的數據結構實現不但困難且測試也麻煩。

單線程避免了線程切換以及加鎖釋放鎖帶來的消耗，對于服務端開發來說，鎖和線程切換通常是性能殺手。當然了，單線程也會有它的缺點，也是 Redis 的噩夢：阻塞。如果執行一個命令過長，那么會造成其他命令的阻塞，對于 Redis 是十分致命的，所以 Redis 是面向快速執行場景的數據庫。

除了 Redis 之外，Node.js 也是單線程，Nginx 也是單線程，但他們都是服務器高性能的典范。

非阻塞多路 I/O 復用機制在這之前先要說一下傳統的阻塞 I/O 是如何工作的：當使用 Read 或者 Write 對某一文件描述符(File Descriptor FD)進行讀寫的時候，如果數據沒有收到，那么該線程會被掛起，直到收到數據。阻塞模型雖然易于理解，但是在需要處理多個客戶端任務的時候，不會使用阻塞模型。

I/O 多路復用實際上是指多個連接的管理可以在同一進程。多路是指網絡連接，復用只是同一個線程。在網絡服務中，I/O 多路復用起的作用是一次性把多個連接的事件通知業務代碼處理，處理的方式由業務代碼來決定。在 I/O 多路復用模型中，最重要的函數調用就是 I/O 多路復用函數，該方法能同時監控多個文件描述符(FD)的讀寫情況，當其中的某些 FD 可讀/寫時，該方法就會返回可讀/寫的 FD 個數。

Redis 使用 epoll 作為 I/O 多路復用技術的實現，再加上 Redis 自身的事件處理模型將 epoll 的 Read、Write、Close 等都轉換成事件，不在網絡 I/O 上浪費過多的時間。實現對多個 FD 讀寫的監控，提高性能。

舉個形象的例子吧，比如：一個 TCP 服務器處理 20 個客戶端 Socket。

A 方案：順序處理，如果第一個 Socket 因為網卡讀數據處理慢了，一阻塞后面都玩蛋去。

B 方案：每個 Socket 請求都創建一個分身子進程來處理，不說每個進程消耗大量系統資源，光是進程切換就夠操作系統累的了。

C 方案:(I/O 復用模型，epoll)：將用戶 Socket 對應的 FD 注冊進 epoll(實際上服務器和操作系統之間傳遞的不是 Socket 的 FD 而是 fd_set 的數據結構)，然后 epoll 只告訴哪些需要讀/寫的 Socket，需要處理那些活躍的有變化的 Socket FD 就好了。這樣，整個過程只在調用 epoll 的時候才會阻塞，收發客戶消息是不會阻塞的。