轉載鏈接：https://cloud.tencent.com/developer/article/1120615
1）以前一直有個誤區，以為：高性能服務器 一定是多線程來實現的
原因很簡單因為誤區二導致的：多線程 一定比 單線程 效率高，其實不然！
在說這個事前希望大家都能對 CPU 、 內存 、 硬盤的速度都有了解了，這樣可能理解得更深刻一點，不了解的朋友點：CPU到底比內存跟硬盤快多少
2）redis 核心就是 如果我的數據全都在內存里，我單線程的去操作 就是效率最高的，為什么呢，因為多線程的本質就是 CPU 模擬出來多個線程的情況，這種模擬出來的情況就有一個代價，就是上下文的切換，對於一個內存的系統來說，它沒有上下文的切換就是效率最高的。redis 用 單個CPU 綁定一塊內存的數據，然后針對這塊內存的數據進行多次讀寫的時候，都是在一個CPU上完成的，所以它是單線程處理這個事。在內存的情況下，這個方案就是最佳方案 —— 阿里 沈詢
因為一次CPU上下文的切換大概在 1500ns 左右。
從內存中讀取 1MB 的連續數據，耗時大約為 250us，假設1MB的數據由多個線程讀取了1000次，那么就有1000次時間上下文的切換，
那么就有1500ns * 1000 = 1500us ，我單線程的讀完1MB數據才250us ,你光時間上下文的切換就用了1500us了，我還不算你每次讀一點數據 的時間，
3）那什么時候用多線程的方案呢？
【IOPS（Input/Output Operations Per Second）是一個用於計算機存儲設備（如硬盤（HDD）、固態硬盤（SSD）或存儲區域網絡（SAN））性能測試的量測方式】
【吞吐量是指對網絡、設備、端口、虛電路或其他設施，單位時間內成功地傳送數據的數量（以比特、字節、分組等測量）】
答案是：下層的存儲等慢速的情況。比如磁盤
內存是一個 IOPS 非常高的系統，因為我想申請一塊內存就申請一塊內存，銷毀一塊內存我就銷毀一塊內存，內存的申請和銷毀是很容易的。而且內存是可以動態的申請大小的。
磁盤的特性是：IPOS很低很低，但吞吐量很高。這就意味着，大量的讀寫操作都必須攢到一起，再提交到磁盤的時候，性能最高。為什么呢？
如果我有一個事務組的操作（就是幾個已經分開了的事務請求，比如寫讀寫讀寫，這么五個操作在一起），在內存中，因為IOPS非常高，我可以一個一個的完成，但是如果在磁盤中也有這種請求方式的話，
我第一個寫操作是這樣完成的：我先在硬盤中尋址，大概花費10ms，然后我讀一個數據可能花費1ms然后我再運算（忽略不計），再寫回硬盤又是10ms ，總共21ms
第二個操作去讀花了10ms, 第三個又是寫花費了21ms ,然后我再讀10ms, 寫21ms ，五個請求總共花費83ms，這還是最理想的情況下，這如果在內存中，大概1ms不到。
所以對於磁盤來說，它吞吐量這么大，那最好的方案肯定是我將N個請求一起放在一個buff里，然后一起去提交。
方法就是用異步：將請求和處理的線程不綁定，請求的線程將請求放在一個buff里，然后等buff快滿了，處理的線程再去處理這個buff。然后由這個buff 統一的去寫入磁盤，或者讀磁盤，這樣效率就是最高。java里的 IO不就是這么干的么~
對於慢速設備，這種處理方式就是最佳的，慢速設備有磁盤，網絡 ，SSD 等等，
多線程 ，異步的方式處理這些問題非常常見，大名鼎鼎的netty 就是這么干的。
終於把 redis 為什么是單線程說清楚了，把什么時候用單線程跟多線程也說清楚了，其實也是些很簡單的東西，只是基礎不好的時候，就真的尷尬。。。。
4）補一發大師語錄：來說說，為何單核cpu綁定一塊內存效率最高
“我們不能任由操作系統負載均衡，因為我們自己更了解自己的程序，所以我們可以手動地為其分配CPU核，而不會過多地占用CPU”，默認情況下單線程在進行系統調用的時候會隨機使用CPU內核，為了優化Redis，我們可以使用工具為單線程綁定固定的CPU內核，減少不必要的性能損耗！
redis作為單進程模型的程序，為了充分利用多核CPU，常常在一台server上會啟動多個實例。而為了減少切換的開銷，有必要為每個實例指定其所運行的CPU。
Linux 上 taskset 可以將某個進程綁定到一個特定的CPU。你比操作系統更了解自己的程序，為了避免調度器愚蠢的調度你的程序，或是為了在多線程程序中避免緩存失效造成的開銷。
順便再提一句：redis 的瓶頸在網絡上 。。。。