核心知識點：
1.單執行緒機制：所有命令放在乙個佇列中
2.為什麼redis單執行緒這麼快？記憶體中執行、非io阻塞、避免執行緒切換和競態產生的消耗。
3.單執行緒的問題？乙個命令不能執行太長時間，不然會阻塞其他命令的執行。
redis使用單執行緒架構和i/o多路復用模型來實現高效能的記憶體資料服務。
下面嘗試說明redis單執行緒命令處理機制，接著分析redis單執行緒模型為什麼效能如此之高。
1.單執行緒命令的處理機制
redis客戶端與服務端的模型可以簡化成下圖：
每次客戶端呼叫都經歷了傳送命令、執行命令、返回結果三個過程。
因為redis是單執行緒來處理命令，所以一條命令從客戶端到達服務端不會立即被執行，所有的命令都會進入乙個佇列，然後逐個被執行。
所有即使是有先後順序的幾個命令到達服務端的執行順序也是不確定的，因為中間有網路傳輸。
但是可以肯定的是，不會有兩條命令被同時執行。
這樣就不會產生併發問題，這就是redis單執行緒的基本模型。
2.為什麼單執行緒還能這麼快？
通常來將，單執行緒的處理能力要比多執行緒差，因為10個人幹活肯定要比1個人幹活快。
那麼為什麼redis使用單執行緒模型會達到每秒萬級別的處理能力了？可以將其歸結為三點：
第一，純記憶體訪問，redis將所有資料放在記憶體中，記憶體的響應時長大約為100納秒，這是redis達到每秒萬級別訪問的重要基礎。
第二，非阻塞i/o，redis使用epoll作為i/o多路復用技術的實現，
再加上redis自身的事件處理模型將epoll中連線、讀寫、關閉都轉換為事件，不在網路i/o上浪費過多時間。
第三，單執行緒避免了執行緒切換和競態產生的消耗。
既然單執行緒就能達到如此高的效能，那麼也不失為一種不錯的選擇，因為單執行緒能帶來幾個好處：
首先，單執行緒可以簡化資料結果和演算法的實現。在高階語言中，併發資料結構不但實現很難而且開發測試比較麻煩。
其次，單執行緒避免了執行緒切換和競態產生的消耗，對於服務端開發來所，鎖和執行緒切換通常是效能殺手。
但是，單執行緒會有乙個問題：對於每個命令的執行事件是有要求的。如果某個命令執行過長，會造成其他命令的阻塞，
對於redis這種高效能的服務來說是致命的，所以redis是面向快速執行場景的資料庫。
Redis的單執行緒架構
redis使用了單執行緒架構 和 i o多路復用模型來實現高效能的記憶體資料庫服務。這裡通過 多個客戶端 命令呼叫的例子說明 redis單執行緒命令處理機制，接著分析 redis單執行緒模型為什麼效能如此之高，最終給出為什麼 理解單執行緒模型是使用和運維redis的關鍵。開啟三個redis cli客...
redis的單執行緒架構
redis很快，官網給出的資料是10萬 秒，當然是跟機器的配置有關係的，redis是使用單執行緒架構和io多路復用來實現高效能 redis單執行緒處理命令的機制 redis客戶端和服務端的通訊大致可分為三個步驟 1.傳送命令 2.執行命令 3返回結果 當多個redis命令同時到達伺服器端時，redi...
Redis單執行緒理解
簡介 從接觸redis到現在，一直被它的單執行緒問題困擾，這對於乙個苛求原理的我來說是種折磨，今天吃飯途中看了幾篇部落格，茅塞頓開。個人理解 redis分客戶端和服務端，一次完整的redis請求事件有多個階段 客戶端到伺服器的網路連線 redis讀寫事件發生 redis服務端的資料處理 單執行緒 資...