其中,第一步+第四步称为Round Trip Time(RTT,往返时间).
Pipeline并不是什么新的技术和机制,很多技术上都使用过.而且RTT在不同网络环境下会有不同,例如同机房和同机器会比较快,跨机房跨地区会比较慢.Redis命令真正执行的时间通常在微秒级别,所以才会有Redis性能瓶颈是网络这样的说法.
可以使用Pipeline模拟出批量操作的效果,但是在使用时需要质疑它与原生批量命令的区别,具体包含几点:
原生批量命令是原子性,Pipeline是非原子性的.
原生批量命令是一个命令对应多个key,Pipeline支持多个命令.
Pipeline只能操作一个Redis实例,但即使在分布式Redis场景中,也可以作为批量操作的重要优化方法.
为了保证多条命令组合的原子性,Redis提供了简单的事务以及集成Lua脚本来解决这个问题.
熟悉关系型数据库的开发者应该对事务比较了解,简单地说,事务表示一组动作,要么全部成功,要不全部不成功.例如在在电商网站中用户购买商品A那么需要将商品A的库存-1,并创建一个订单.这两个操作要么远不执行成功,要么全部执行不成功,否则会出现数据不一致的情况.
Redis提供了简单的功能,将一组需要一起执行的命令放到multi和exec两个命令之间.multi命令代表事务的开始,exec命令代表事务结束,他们之间的命令是原子顺序执行的.例如上述的用户购买商品问题:
12⑦0.0.1:6379> multi
12⑦0.0.1:6379> hincrby commodity:a:detail stock -1
12⑦0.0.1:6379> rpush user:1:orders {"commodity":'a',..}
QUEUE
127.0.0.1:6379> llen user:1:orders
(integer) 0
只有当exec执行后,用户购买商品的行为才算完成,如下两个结果对应hincrby和rpush命令.
127.0.0.1:6379> exec
1) (integer) 4 # 商品原库存为5
2) (integer) 1
127.0.0.1:6379> llen user:1:orders
(integer) 1
如果要停止事务的执行,可以使用discard命令替代exec命令即可.
127.0.0.1:6379> discard
OK
127.0.0.1:6379> llen user:1:orders
(integer) 0
如果事务中的命令出现错误,Redis的处理机制也不尽相同.
①命令错误例如下面操作错将set写成了sett,属于语法错误,会造成整个事务无法执行,key和counter的值未发生变化:
12⑦0.0.1:6379> mget key counter
1) "hello"
2) "100"
(error) ERR unknown command 'sett'
12⑦0.0.1:6379> exec
1) "hello"
2) "100"
12⑦0.0.1:6379> multi
12⑦0.0.1:6379> hincrby commodity:a:detail stock -1
12⑦0.0.1:6379> zadd user:1:orders {"commodity":'a',..}
12⑦0.0.1:6379> exec
1) (integer) 1
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value.
12⑦0.0.1:6379> hget commodity:a:detail stack
(integer) 3
可以看到Redis并不支持回滚功能,hincrby commodity:a:detail stock -1命令已经执行成功,开发者需要自己修改这类问题.
以上就是土嘎嘎小编大虾米为大家整理的相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用，就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！