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

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

在說這個事前希望大家都能對 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 的瓶頸在網路上 。。。。