redis為什麼那麼快？結論有三點，大家都知道，這裡主要是分析。
首先第一點
redis是記憶體訪問的，所以快
當然這個大家都知道，所以不是重點
一般我們把任務分為io密集型和cpu密集型
redis基本都在進行記憶體io，那它的瓶頸在io上嗎？
redis在網路io上使用epoll實現了乙個io多路復用的reactor模型，epoll是非阻塞io，所以避免了cpu阻塞在io上，所以它不是io密集型，瓶頸不在於等待io導致cpu利用率不高，不需要多個執行緒來遮蔽等待io執行完成的時間。當然redis的io利用率很高，但是io利用率高並不代表它是io密集型，因為它瓶頸不在等待io上。
所以第二點
redis在網路io上使用epoll實現了乙個io多路復用的reactor模型使得cpu利用率更高，浪費在io上的時間更少
redis並不需要多執行緒來提高cpu利用率減少io等待時間，並且單執行緒架構也比較容易實現，所以順理成章就採用了單執行緒架構。
第三點由於採用了單執行緒架構，避免了執行緒與執行緒之間切換產生的消耗
因為一次cpu上下文的切換大概在 1500ns 左右。那麼redis是cpu密集型嗎？答案是否定的。從記憶體中讀取 1mb 的連續資料，耗時大約為 250us，假設1mb的資料由多個執行緒讀取了1000次，那麼就有1000次時間上下文的切換，
那麼就有1500ns * 1000 = 1500us ，我單執行緒的讀完1mb資料才250us ,你光時間上下文的切換就用了1500us了，我還不算你每次讀一點資料 的時間
redis也不是cpu密集型。大多數情況下redis機器上的cpu是很夠用的。
redis的瓶頸在於記憶體大小和網路頻寬。
如果想要更充分的利用多核cpu，可以採用多個redis例項的方法，同時為了減少執行緒爭用，可以將例項和cpu繫結的方法。
但是如果做了cpu繫結，在rdb和aof時子程序會與父程序共享使用乙個cpu。子程序重寫時對單核cpu使用率通常在90%以上，父程序與子程序將產生激烈cpu競爭，極大影響redis穩定性。（解決方法不清楚，也許多繫結乙個cpu會好點？）
dma 傳輸將資料從乙個位址空間複製到另外乙個位址空間。當cpu 初始化這個傳輸動作，傳輸動作本身是由 dma 控制器來實行和完成。
典型的例子就是移動乙個外部記憶體的區塊到晶元內部更快的記憶體區。例如磁碟移到記憶體。
最後慣例附一圖：
Redis單執行緒
redis 的單執行緒主要是指 redis 的網路 io 和鍵值對讀寫是由乙個執行緒來完成的，這也是 redis 對外提供鍵值儲存服務的主要流程。當多個客戶端發起命令，這些命令併發執行時，在redis內部，會排隊逐個執行，也就是執行命令的那個操作是由乙個執行緒執行的。但 redis 的其他功能，比如...
redis的單執行緒
1 完全基於記憶體，絕大部分請求是純粹的記憶體操作，非常快速。資料存在記憶體中，類似於hashmap，hashmap的優勢就是查詢和操作的時間複雜度都是o 1 2 資料結構簡單，對資料操作也簡單，redis中的資料結構是專門進行設計的 3 採用單執行緒，避免了不必要的上下文切換和競爭條件，也不存在多...
Redis單執行緒理解
簡介 從接觸redis到現在，一直被它的單執行緒問題困擾，這對於乙個苛求原理的我來說是種折磨，今天吃飯途中看了幾篇部落格，茅塞頓開。個人理解 redis分客戶端和服務端，一次完整的redis請求事件有多個階段 客戶端到伺服器的網路連線 redis讀寫事件發生 redis服務端的資料處理 單執行緒 資...