纯内存数据库,如果只是简单的 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