1、完全基於記憶體，絕大部分請求是純粹的記憶體操作，非常快速。資料存在記憶體中，類似於hashmap，hashmap的優勢就是查詢和操作的時間複雜度都是o(1)；
2、資料結構簡單，對資料操作也簡單，redis中的資料結構是專門進行設計的；
3、採用單執行緒，避免了不必要的上下文切換和競爭條件，也不存在多程序或者多執行緒導致的切換而消耗 cpu，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的效能消耗；
4、使用多路i/o復用模型，非阻塞io；
這裡「多路」指的是多個網路連線，「復用」指的是復用同乙個執行緒。採用多路 i/o 復用技術可以讓單個執行緒高效的處理多個連線請求（儘量減少網路 io 的時間消耗），且 redis 在記憶體中運算元據的速度非常快，也就是說記憶體內的操作不會成為影響redis效能的瓶頸，主要由以上幾點造就了 redis 具有很高的吞吐量。
5. 還有一點，redis採用自己實現的事件分離器，效率比較高，內部採用非阻塞的執行方式，吞吐能力比較大。
官方faq表示，因為redis是基於記憶體的操作，cpu不是redis的瓶頸，redis的瓶頸最有可能是機器記憶體的大小或者網路頻寬。既然單執行緒容易實現，而且cpu不會成為瓶頸，那就順理成章地採用單執行緒的方案了（畢竟採用多執行緒會有很多麻煩！）。
但是，我們使用單執行緒的方式是無法發揮多核cpu 效能，不過我們可以通過在單機開多個redis 例項來完善！
警告1：這裡我們一直在強調的單執行緒，只是在處理我們的網路請求的時候只有乙個執行緒來處理，乙個正式的redis server執行的時候肯定是不止乙個執行緒的，這裡需要大家明確的注意一下！
警告2：從redis 4.0版本開始會支援多執行緒的方式，但是，只是在某一些操作上進行多執行緒的操作！
redis客戶端對服務端的每次呼叫都經歷了傳送命令，執行命令，返回結果三個過程。其中執行命令階段，由於redis是單執行緒來處理命令的，所有每一條到達服務端的命令不會立刻執行，所有的命令都會進入乙個佇列中，然後逐個被執行。並且多個客戶端傳送的命令的執行順序是不確定的。但是可以確定的是不會有兩條命令被同時執行，不會產生併發問題，這就是redis的單執行緒基本模型。
在io方面由於是單執行緒，所以為了提高io的效率，使用了多路復用的io模型，redis 基於 reactor 模式開發了自己的網路事件處理器： 這個處理器被稱為檔案事件處理器（file event handler）：
檔案事件處理器使用 i/o 多路復用（multiplexing）程式來同時監聽多個套接字， 並根據套接字目前執行的任務來為套接字關聯不同的事件處理器。
當被監聽的套接字準備好執行連線應答（accept）、讀取（read）、寫入（write）、關閉（close）等操作時， 與操作相對應的檔案事件就會產生， 這時檔案事件處理器就會呼叫套接字之前關聯好的事件處理器來處理這些事件。
Redis單執行緒
redis 的單執行緒主要是指 redis 的網路 io 和鍵值對讀寫是由乙個執行緒來完成的，這也是 redis 對外提供鍵值儲存服務的主要流程。當多個客戶端發起命令，這些命令併發執行時，在redis內部，會排隊逐個執行，也就是執行命令的那個操作是由乙個執行緒執行的。但 redis 的其他功能，比如...
Redis單執行緒理解
簡介 從接觸redis到現在，一直被它的單執行緒問題困擾，這對於乙個苛求原理的我來說是種折磨，今天吃飯途中看了幾篇部落格，茅塞頓開。個人理解 redis分客戶端和服務端，一次完整的redis請求事件有多個階段 客戶端到伺服器的網路連線 redis讀寫事件發生 redis服務端的資料處理 單執行緒 資...
redis單執行緒模型
redis基於reactor模式開發了自己的網路事件處理器，稱之為檔案事件處理器 file event hanlder 檔案事件處理器由socket io多路復用程式 檔案事件分派器 dispather 事件處理器 handler 四部分組成。io多路復用程式會同時監聽多個socket，當被監聽的s...