OneCache :: 多线程后端Pipeline功能,显著提升单个Redis节点的处理能力

Redis是一款极其优秀的缓存服务器,但其单进程结构,不仅使其性能受限,也使其管理内存的能力受限。Twemproxy虽然具有后端Pipeline功能,担仍然是单进程结构,需要随应用布署许多实例才行。可以说,如果应用程序客户端或业务逻辑不能支持批量操作(Pipeline),构建一个数十万至上百万QPS的缓存还是一件技术含量级高的事情,而这一切将会因为OneCache而变得简单。先来看一下最新的OneCache架构图:

onecache_backend_pipeline

OneCache的以下几个特点,使其成为高性能的缓存分布式中间件:

  • OneCache支持管理多个后端Redis节点。
  • OneCache自身是多线程的,采且Listener + Worker的模式,垂直扩展能力极好。
  • OneCache支持后端请求的透明合并(Pipeline),将应用的请求合并发往后端,提升性能。
  • OneCache维持到Redis的长连接,提升Redis的CPU处理能力。
  • OneCache支持前端批量操作的并行执行,以极快的时间响应客户端请求。
  • OneCache采用C & C++语言编写。

即使后端只接一个Redis,也可以提升缓存处理能力,下面是我们的一个测试,环境如下所示:

  • 客户端:服务器A,运行redis-benchmark程序,5个进程并发,每个进程配置200个连接。
  • 服务端:OneCache + 单个Redis节点,共中OneCache配置6个Worker线程,并配置8个到Redis的连接。

第一次不使用客户端合并功能,压测用的shell脚本如下所示:

/bin/rm -fr ?.log
for i in {0..4}
do
 nohup ./redis-benchmark -h 172.30.12.15 -p 8221 -t set,get \
      -r 10000 -n 1000000 -d 50 -c 200 -q > ${i}.log 2>&1 &
done

直连Redis的压测结果如下:

[root@osd12 redis]# cat *.log
SET: 42789.90 requests per second
GET: 46324.18 requests per second

SET: 44308.56 requests per second
GET: 48792.39 requests per second

SET: 44585.13 requests per second
GET: 48820.97 requests per second

SET: 45142.65 requests per second
GET: 48737.70 requests per second

SET: 43650.96 requests per second
GET: 47678.07 requests per second

连接OneCache的压测结果如下所示:

[root@osd12 redis]# cat *.log
SET: 77118.84 requests per second
GET: 81987.38 requests per second

SET: 76452.60 requests per second
GET: 80411.71 requests per second

SET: 76051.41 requests per second
GET: 80418.17 requests per second

SET: 76097.71 requests per second
GET: 81168.84 requests per second

SET: 75046.91 requests per second
GET: 78696.78 requests per second

可以看到,单个Redis的QPS能力被提升到接近35-40万,与直连相比性能提升高达80%。接下来测试一下客户端开启合并功能的情况,压测脚本如下所示:

/bin/rm -fr ?.log
for i in {0..4}
do
 nohup ./redis-benchmark -h 172.30.12.15 -p 8221 -t set,get \
      -r 10000 -n 1000000 -d 50 -c 200 -P 5 -q > ${i}.log 2>&1 &
done

批量操作直连Redis的压测结果如下所示:

[root@osd12 redis]# cat *.log
SET: 122414.01 requests per second
GET: 159897.66 requests per second

SET: 122699.39 requests per second
GET: 160102.47 requests per second

SET: 125015.62 requests per second
GET: 161969.56 requests per second

SET: 121270.91 requests per second
GET: 152369.34 requests per second

SET: 122129.95 requests per second
GET: 158102.77 requests per second

批量操作连接OneCache的压测结果如下所示:

SET: 127194.10 requests per second
GET: 171703.30 requests per second

SET: 129065.56 requests per second
GET: 172354.36 requests per second

SET: 125281.88 requests per second
GET: 165727.55 requests per second

SET: 125281.88 requests per second
GET: 169692.86 requests per second

SET: 125801.99 requests per second
GET: 169348.00 requests per second

在批量操作模式下,QPS比直连要略高一些。可以看到不管是否使用客户端批量操作,加入OneCache都不会降低性能。考虑到绝大多数客户端都不适合使用批量合并功能(受业务模式限制),布署OneCache是非常有意义的。我们内部的压测环境是千兆网络,并且是单个Redis后端,如果后端是多个Redis组成的集群,性能将更高。前面所讲OneCache的特性,将使它成为单实例支持百万QPS的高效缓存中间件,并且我们已经开源全部代码