今天下午，煙哥吃飽了撐著沒事幹，上班時間到處工(zhuang)作(bi)！只見同事小劉的桌上擺了一本redis相關的書籍，內心嘿嘿一笑：「終於，又有機會勾搭小劉了！」
於是有了如下對話
"嗯，不要方，跟著我思路來想！"煙哥道。
"假設，此刻有任務a和任務b，現在有如下兩種執行方式"
方式一:兩個執行緒，乙個執行緒執行a，另乙個執行緒執行b方式二:乙個執行緒，先執行a，執行完以後繼續執行b
"請問，哪種方式執行更快？"
只見煙哥眉頭微微一皺，說道:"我夜觀天象，掐指一算，小劉你大學在上《計算機組成原理》這門課的時候，一定逃課了！"
"應該是方式二更快，因為方式一中，cpu在切換執行緒的時候，有乙個上下文切換時間，而這個上下文切換時間是非常耗時的！打個比方，乙個cpu主頻是 2.6ghz，這意味著每秒可以執行：2.6*10^9 個指令，那麼每個指令的時間大概是0.38ns！而一次上下文切換，將近需要耗時2000ns！而這個時間內，cpu什麼都幹不了，只是做了儲存上下文都動作！"
"ok，就是在i/o操作都時候，例如磁碟i/o，網路i/o等！為什麼一般是在i/o操作都時候，要用多執行緒呢(面試高頻題，必背)？因為i/o操作一般可以分為兩個階段:即等待i/o準備就緒和真正操作i/o資源！"
"以磁碟操作為例，磁碟的結構如下"
"在磁碟上資料是分磁軌、分簇儲存的，而資料往往並不是連續排列在同一磁軌上，所以磁頭在讀取資料時往往需要在磁軌之間反覆移動，因此這裡就有乙個尋道耗時！另外，盤面旋轉將請求資料所在扇區移至讀寫頭下方也是需要時間，這裡還存在乙個旋轉耗時！"
"那麼，在這一時間段（即"i/o等待"）內，執行緒是在「阻塞」著等待磁碟，此時作業系統可以將那個空閒的cpu核心用於服務其他執行緒。因此在i/o操作的情況下，使用多執行緒，效率會更高！"
"ok,現在回到我們的問題！redis讀寫資料有涉及到i/o操作麼？"
"所以啊，redis不涉及i/o操作，因此設計為單執行緒是效率最高的！那麼，既然你知道既然redis的效能和cpu無關，那你知道redis的效能瓶頸在哪麼？"
小劉無奈的搖了搖頭！
一般在兩個地方
其一是機器記憶體大小，記憶體大小關係到redis儲存的資料量其二是網路頻寬，這點我仔細說一下redis客戶端執行一條命令分為四個過程：傳送命令、命令排隊、命令執行、返回結果
而其中傳送命令+返回結果這一過程被稱為round trip time（rtt，往返時間）
redis的客戶端和服務端可能部署在不同的機器上。例如客戶端在北京，redis服務端在上海，兩地直線距離約為1300公里，那麼1次rtt時間=1300×2/（300000×2/3）=13毫秒（光在真空中傳輸速度為每秒30萬公里，這裡假設光纖為光速的2/3），那麼客戶端在1秒內大約只能執行80次左右的命令，這就和redis的高併發高吞吐特性背道而馳啦！所以一般情況下，都是就近部署
Redis為什麼是單執行緒
經過多方資料收集 總結 思考，結論如下 準確地來說，該問題是 為什麼redis採用單程序單執行緒模型 我們從兩個層次去理解 第乙個層次 我們多執行緒的使用情景是io密集型，目的是為了充分利用cpu資源。也就是說當乙個執行緒io等待的時候，另乙個執行緒可以進行執行，達到充分利用cpu資源的效果，不要讓...
面試 為什麼Redis是單執行緒
先給下官網回答 分析 多執行緒使用場景 a充分利用多核cpu b 檔案或者網路io密集型 任務排程 1 redis在linux上 使用管道每秒可以處理百萬請求 如果都是時間複雜度o n 或o log n 命令 單核足以支撐 所以a不滿足 2 redis是針對記憶體操作 所以檔案io不滿足 redis...
為什麼Redis選擇單執行緒模型？
redis從一開始就使用單執行緒模型處理來自客戶端的絕大多數的網路請求，即redis可以支援io多路復用。除此之外還有其他原因 1 使用單執行緒模型能帶來更好的維護性，方便開發和除錯。2 使用單執行緒模型也能併發的處理客戶端的請求。3 redis服務中執行的絕大多數操作的效能瓶頸都不是cpu。雖然多...