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