為什麼redis 是單線程的？__redis為什麼是單線程的

以前一直有個誤區，以為：高效能伺服器 一定是 多線程來實現的

原因很簡單因為誤區二導致的： 多線程 一定比 單線程 效率高。其實不然。

在說這個事前希望大家都能對 CPU 、 記憶體 、 硬碟的速度都有瞭解了，這樣可能理解得更深刻一點，不瞭解的朋友點：CPU到底比記憶體跟硬碟快多少

redis 核心就是 如果我的資料全都在記憶體裡，我單線程的去操作 就是效率最高的，為什麼呢，因為多線程的本質就是 CPU 類比出來多個線程的情況，這種類比出來的情況就有一個代價，就是內容相關的切換，對於一個記憶體的系統來說，它沒有內容相關的切換就是效率最高的。redis 用 單個CPU 綁定一塊記憶體的資料，然後針對這塊記憶體的資料進行多次讀寫的時候，都是在一個CPU上完成的，所以它是單線程處理這個事。在記憶體的情況下，這個方案就是最佳方案  —— 阿里 沈詢 

因為一次CPU內容相關的切換大概在 1500ns 左右。

從記憶體中讀取 1MB 的連續資料，耗時大約為 250us，假設1MB的資料由多個線程讀取了1000次，那麼就有1000次時間內容相關的切換，

那麼就有1500ns * 1000 = 1500us ，我單線程的讀完1MB資料才250us ,你光時間內容相關的切換就用了1500us了，我還不算你每次讀一點資料 的時間，

那什麼時候用多線程的方案呢。

答案是：下層的儲存等慢速的情況。比如磁碟

記憶體是一個 IOPS 非常高的系統，因為我想申請一塊記憶體就申請一塊記憶體，銷毀一塊記憶體我就銷毀一塊記憶體，記憶體的申請和銷毀是很容易的。而且記憶體是可以動態申請大小的。

磁碟的特性是：IPOS很低很低，但輸送量很高。這就意味著，大量的讀寫操作都必須攢到一起，再提交到磁碟的時候，效能最高。為什麼呢。

如果我有一個事務組的操作（就是幾個已經分開了的事務請求，比如寫讀寫讀寫，這麼五個操作在一起），在記憶體中，因為IOPS非常高，我可以一個一個的完成，但是如果在磁碟中也有這種請求方式的話，

我第一個寫操作是這樣完成的：我先在硬碟中定址，大概花費10ms，然後我讀一個資料可能花費1ms然後我再運算（忽略不計），再寫回硬碟又是10ms ，總共21ms

第二個操作去讀花了10ms, 第三個又是寫花費了21ms ,然後我再讀10ms, 寫21ms ，五個請求總共花費83ms，這還是最理想的情況下，這如果在記憶體中，大概1ms不到。

所以對於磁碟來說，它輸送量這麼大，那最好的方案肯定是我將N個請求一起放在一個buff裡，然後一起去提交。

方法就是用非同步：將請求和處理的線程不綁定，請求的線程將請求放在一個buff裡，然後等buff快滿了，處理的線程再去處理這個buff。然後由這個buff 統一的去寫入磁碟，或者讀磁碟，這樣效率就是最高。 java裡的 IO不就是這麼乾的麼~

對於慢速裝置，這種處理方式就是最佳的，慢速裝置有磁碟，網路 ，SSD 等等，

 多線程 ，非同步方式處理這些問題非常常見，大名鼎鼎的netty 就是這麼乾的。

終於把 redis 為什麼是單線程說清楚了，把什麼時候用單線程跟多線程也說清楚了，其實也是些很簡單的東西，只是基礎不好的時候，就真的尷尬。。。。 

補一發大師語錄：來說說，為何單核cpu綁定一塊記憶體效率最高

“我們不能任由作業系統負載平衡，因為我們自己更瞭解自己的程式，所以我們可以手動地為其分配CPU核，而不會過多地佔用CPU”，預設情況下單線程在進行系統調用的時候會隨機使用CPU核心，為了最佳化Redis，我們可以使用工具為單線程綁定固定的CPU核心，減少不必要的效能損耗。

redis作為單進程模型的程式，為了充分利用多核CPU，常常在一台server上會啟動多個執行個體。而為了減少切換的開銷，有必要為每個執行個體指定其所啟動並執行CPU。

Linux 上  taskset 可以將某個進程綁定到一個特定的CPU。你比作業系統更瞭解自己的程式，為了避免調度器愚蠢的調度你的程式，或是為了在多線程程式中避免緩衝失效造成的開銷。

順便再提一句：redis 的瓶頸在網路上 。。。。