純記憶體資料庫，如果只是簡單的 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
純記憶體資料庫，如果只是簡單的 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