一、请求应答协议和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,教程,管线详解
免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
更新日志
- 张琍敏1978-雪中莲[台湾复刻版][WAV+CUE]
- 叶蕴仪1993-睡美人[日本版][WAV+CUE]
- 夜晚助兴音乐-群星《新时代床头音乐-性能量》2CD[WAV]
- 24K德国HD金碟《历届奥斯卡获奖金曲》3CD[WAV整轨]
- 邰正宵《重燃爱恋 贰 Walk On》[FLAC/分轨][431.72MB]
- 苏文劭《雨停出来走走》[320K/MP3][81.11MB]
- 苏文劭《雨停出来走走》[FLAC/分轨][210.76MB]
- 群星《2024好听新歌04》十倍音质WAV分轨
- 陈宁《弹指之间HQ》头版限量[低速原抓WAV+CUE]
- 陈宁《故人还》HQCDII限量签名版[低速原抓WAV+CUE]
- 苏文劭《春曲(Lessons)》[320K/MP3][39.8MB]
- 苏文劭《春曲(Lessons)》[FLAC/分轨][97.78MB]
- 群星《2006香港高级视听展原音精选 SACD》[ISO][2G]
- 张琍敏1977-枫林小雨[台湾复刻版][WAV+CUE]
- 林一峰2014-COOKINGMUSIC[香港首版][WAV+CUE]