内容简介:Redis客户端执行一条命令:其中发送命令和返回结果可以称为 Round Trip Time (RTT,往返时间)。在Redis中提供了批量操作命令,例如mget、mset等,有效地节约了RTT。但是大部分命令是不支持批量操作的。为此Redis提供了一个称为
Redis客户端执行一条命令:
- 发送命令
- 命令排队
- 执行命令
- 返回结果
其中发送命令和返回结果可以称为 Round Trip Time (RTT,往返时间)。在 Redis 中提供了批量操作命令,例如mget、mset等,有效地节约了RTT。但是大部分命令是不支持批量操作的。
为此Redis提供了一个称为 管道(Pipeline) 的机制将一组Redis命令进行组装,通过一次 RTT 传输给 Redis,再将这些 Redis 命令的执行结果按顺序传递给客户端。即使用pipeline执行了n次命令,整个过程就只需要一次 RTT。
对Pipeline进行性能测试
我们使用 redis-benchmark 对Pipeline进行性能测试,该 工具 提供了 -P 的选项,此选项表示使用管道机制处理 n 条Redis请求,默认值为1。测试如下:
# 不使用管道执行get set 100000次请求 [root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -t get,set -q -n 100000 SET: 55710.31 requests per second GET: 54914.88 requests per second # 每次pipeline组织的命令个数 为 100 [root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -P 100 -t get,set -q -n 100000 SET: 1020408.19 requests per second GET: 1176470.62 requests per second # 每次pipeline组织的命令个数 为 10000 [root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -P 10000 -t get,set -q -n 100000 SET: 321543.41 requests per second GET: 241545.89 requests per second 复制代码
从上面测试可以看出,使用pipeline的情况下 Redis 每秒处理的请求数远大于 不使用 pipeline的情况。
当然每次pipeline组织的命令个数不能没有节制,否则一次组装Pipeline数据量过大,一方面会增加 客户端等待时间,另一方面会造成一定的网络阻塞。
从上面的测试中也可以看出,如果一次pipeline组织的命令个数为 10000,但是它对应的QPS 却小于 一次pipeline命令个数为 100的。所以每次组织 Pipeline的命令个数不是越多越好,可以将一次包含大量命令的 Pipeline 拆分为 多个较小的 Pipeline 来完成。
Pipeline关于RTT的说明
在官网上有一段这样的描述:
大致意思就是 :
Pipeline管道机制不单单是为了减少RTT的一种方式,它实际上大大提高了Redis的QPS。原因是,在没有使用管道机制的情况下,从访问数据结构和产生回复的角度来看,为每个命令提供服务是非常便宜的。但是从底层套接字的角度来看,这是非常昂贵的,这涉及read()和write()系统调用,从用户态切换到内核态,这种上下文切换开销是巨大。而使用Pipeline的情况下,通常使用单个read()系统调用读取许多命令,然后使用单个write()系统调用传递多个回复,这样就提高了QPS
批量命令与Pipeline对比
- 批量命令是原子的,Pipeline 是非原子的
- 批量命令是一个命令多个 key,Pipeline支持多个命令
- 批量命令是 Redis服务端实现的,而Pipeline需要服务端和客户端共同实现
使用jedis执行 pipeline
public class JedisUtils { private static final JedisUtils jedisutils = new JedisUtils(); public static JedisUtils getInstance() { return jedisutils; } public JedisPool getPool(String ip, Integer port) { JedisPoolConfig jedisPoolConfig = new JedisPoolConfig(); jedisPoolConfig.setMaxIdle(RedisConfig.MAX_IDLE); jedisPoolConfig.setMaxTotal(RedisConfig.MAX_ACTIVE); jedisPoolConfig.setMaxWaitMillis(RedisConfig.MAX_WAIT); jedisPoolConfig.setTestOnBorrow(true); jedisPoolConfig.setTestOnReturn(true); JedisPool pool = new JedisPool(jedisPoolConfig, ip, port,RedisConfig.TIMEOUT,RedisConfig.PASSWORD); return pool; } public Jedis getJedis(String ip, Integer port) { Jedis jedis = null; int count = 0; while (jedis == null && count < RedisConfig.RETRY_NUM) { try { jedis = getInstance().getPool(ip, port).getResource(); } catch (Exception e) { System.out.println("get redis failed"); } count++; } return jedis; } public void closeJedis(Jedis jedis) { if (jedis != null) { jedis.close(); } } public static void main(String[] args) throws InterruptedException { Jedis jedis = JedisUtils.getInstance().getJedis("127.0.0.1", 6379); Pipeline pipeline = jedis.pipelined(); pipeline.set("hello", "world"); pipeline.incr("counter"); System.out.println("还没执行命令"); Thread.sleep(100000); System.out.println("这里才开始执行"); pipeline.sync(); } } 复制代码
在睡眠100s的时候查看 Redis,可以看到此时在pipeline中的命令并没有执行,命令都被放在一个队列中等待执行:
127.0.0.1:6379> get hello (nil) 127.0.0.1:6379> get counter (nil) 复制代码
睡眠结束后,使用 pipeline.sync()完成此次pipeline对象的调用。
127.0.0.1:6379> get hello "world" 127.0.0.1:6379> get counter "1" 复制代码
必须要执行pipeline.sync()才能最终执行命令,当然可以使用 pipeline.syncANdReturnAll
回调机制将pipeline响应命令进行返回。
参考资料 & 鸣谢
以上所述就是小编给大家介绍的《Redis学习之管道机制》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 速度不够,管道来凑——Redis管道技术
- Golang pipline泛型管道和类型管道的性能差距
- Linux 管道那些事儿
- mongodb 聚合管道
- Redis管道
- Clojure 集合管道函数练习
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
零售的哲学:7-Eleven便利店创始人自述
[日] 铃木敏文 / 顾晓琳 / 江苏文艺出版社 / 2014-12-1 / 36
全球最大的便利店连锁公司创始人——铃木敏文,结合40多年零售经验,为你讲述击中消费心理的零售哲学。铃木敏文的很多创新,现在已经成为商界常识,本书把那些不可思议的零售创新娓娓道来。关于零售的一切:选址、订货、销售、物流、管理……他一次又一次地在一片反对声中创造出零售界的新纪录。 翻开本书,看铃木敏文如何领导7-11冲破层层阻碍,成为世界第一的零售哲学。一起来看看 《零售的哲学:7-Eleven便利店创始人自述》 这本书的介绍吧!