請求30次redis和請求30次數據庫哪個更快？

純內存數據庫，如果只是簡單的 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