單線程的REDIS為什麼這麼快？

標籤：速度   平台   切換   應該   lock   mem   apache   epoll   memcache   

REDIS是單線程處理所有請求，和一般經典實際上推薦的方式相反，那麼單線程串列處理，為什麼依然能夠做到很快呢？知乎上的一個答案如下， 其中線程切換和鎖不是效能主要影響因素的觀點和一般的答案都不同：楊海坡
連結：https://www.zhihu.com/question/19764056/answer/20241839
來源：知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。

純記憶體資料庫，如果只是簡單的 key-value，記憶體不是瓶頸。一般情況下，hash 尋找可以達到每秒數百萬次的數量級。

瓶頸在於網路 IO 上。

根據你測的的 10000/s 來看，用戶端和 redis 應該是部署在兩台不同的機器，並且是使用同步的方式請求 redis. 每次請求需要通過網路把請求發送到 redis 所在的機器，然後等待 redis 返回資料。時間大部分消耗在網路傳輸中。

如果把 redis 和用戶端放在同一台機器，網路延遲會更小，一般情況下可以打到 60000 次每秒甚至更高，取決於機器效能。

鎖不是影響效能的主要因素。線程鎖 (mutex_lock) 只有在遇到衝突的情況下效能會下降，而正常情況下，遇到衝突的機率很低。如果只是簡單的加鎖、釋放鎖速度是非常快的，每秒鐘上千萬次沒問題。memcache 內部用到了大量的鎖，並沒有見到效能降低。

線程也不是影響輸送量的重要因素。如第一點來說，一般情況下，程式處理記憶體資料的速度遠高於網卡接收的速度。使用線程好處是可以同時處理多條串連，在極端情況下，可能會提高響應速度。

使用 epoll 或 libevent 等因為非同步非阻塞 IO 編程只能這麼做。與之對應的是同步阻塞 IO 編程，使用多進程或多線程實現多條串連的處理，比如 apache。一般情況下，非同步非阻塞 IO 模型效能是遠高於同步阻塞 IO 模型的，可以參考 nginx 與 apache 效能的對比。

libevent 並不比 redis 自己實現的 ae_event 慢，代碼多是應為 ae_event 只實現了 redis 需要的功能，而 libevent 則具有更多的功能，比如更快的定時器、buffer event 模型，甚至內建了 DNS、HTTP 協議的處理。並且 libevent 更通用，而 redis 只專註於 linux 平台。

最後回答題主問題，快在哪？
1、純記憶體操作
2、非同步非阻塞 IO

單線程的REDIS為什麼這麼快？