一、请求应答协议和RTT:
Redis是一种典型的基于C/S模型的TCP服务器。在客户端与服务器的通讯过程中,通常都是客户端率先发起请求,服务器在接收到请求后执行相应的任务,最后再将获取的数据或处理结果以应答的方式发送给客户端。在此过程中,客户端都会以阻塞的方式等待服务器返回的结果。见如下命令序列:
复制代码 代码如下:
Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4
在每一对请求与应答的过程中,我们都不得不承受网络传输所带来的额外开销。我们通常将这种开销称为RTT(Round Trip Time)。现在我们假设每一次请求与应答的RTT为250毫秒,而我们的服务器可以在一秒内处理100k的数据,可结果则是我们的服务器每秒至多处理4条请求。要想解决这一性能问题,我们该如何进行优化呢?
二、管线(pipelining):
Redis在很早的版本中就已经提供了对命令管线的支持。在给出具体解释之前,我们先将上面的同步应答方式的例子改造为基于命令管线的异步应答方式,这样可以让大家有一个更好的感性认识。
复制代码 代码如下:
Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4
从以上示例可以看出,客户端在发送命令之后,不用立刻等待来自服务器的应答,而是可以继续发送后面的命令。在命令发送完毕后,再一次性的读取之前所有命令的应答。这样便节省了同步方式中RTT的开销。
最后需要说明的是,如果Redis服务器发现客户端的请求是基于管线的,那么服务器端在接受到请求并处理之后,会将每条命令的应答数据存入队列,之后再发送到客户端。
三、Benchmark:
以下是来自Redis官网的测试用例和测试结果。需要说明的是,该测试是基于loopback(127.0.0.1)的,因此RTT所占用的时间相对较少,如果是基于实际网络接口,那么管线机制所带来的性能提升就更为显著了。
复制代码 代码如下:
require 'rubygems'
require 'redis'
def bench(descr)
start = Time.now
yield
puts "#{descr} #{Time.now-start} seconds"
end
def without_pipelining
r = Redis.new
10000.times {
r.ping
}
end
def with_pipelining
r = Redis.new
r.pipelined {
10000.times {
r.ping
}
}
end
bench("without pipelining") {
without_pipelining
}
bench("with pipelining") {
with_pipelining
}
//without pipelining 1.185238 seconds
//with pipelining 0.250783 seconds
Redis,教程,管线详解
更新日志
- 刘欢.2004-经典20年珍藏锦集【新索】【WAV+CUE】
- 中唱唱片群星《好歌珍藏-游子情深》2CDWAV
- CD圣经上榜天碟1995-乌仁娜-《蒙古草原之歌》[WAV+CUE].
- 【电影原声】武满彻《旭日东升》1993[WAV+CUE整轨]
- Taylor Swift《THE TORTURED POETS DEPARTMENT》[320K/MP3][148.54MB]
- Taylor Swift《THE TORTURED POETS DEPARTMENT》[FLAC/分轨][405.72MB]
- Joyce Jonathan《法式松弛感 漫步香榭丽舍》[320K/MP3][80.8MB]
- 女神异闻录5佐仓双叶coop攻略 p5r佐仓双叶对话选项攻略
- 【民谣】张智《尼勒克小镇》[FLAC]
- 林一峰2018-TRAVELOGUE4ESCAPE[香港首版][WAV+CUE]
- MollyLewis《OnTheLips》(2024)[Hi-Res96kHz_24bitFLAC]
- Joyce Jonathan《法式松弛感 漫步香榭丽舍》[FLAC/分轨][230.77MB]
- 群星《影视剧 春色寄情人 原声带》[320K/MP3][394.18MB]
- 吴牧野《强者独白II 李斯特巅峰作品选》[320K/MP3][216.01MB]
- 女神异闻录5御船千早coop攻略 p5r御船千早对话选项攻略