标签:实例 流水线 通过 存在 增加 mil ica ping mem
Redis客户端执行一条命令分为如下四个过程:
(1)发送命令 (2)命令排队 (3)命令执行 (4)返回结果
其中(1)和(4)称为Round Trip Time(RTT,往返时间)。
Redis提供了批量操作命令( 例如mget、mset等) ,可以有效地节约RTT。但大部分命令是不支持批量操作的,例如要执行n次hgetall命令,并没有mhgetall命令存在,需要消耗n次RTT。Redis的客户端和服务端可能部署在不同的机器上。例如客户端在北京,Redis服务端在上海,两地直线距离约为1300公里,那么1次RTT时间=1300x2/ (300000x2/3) =13毫秒(光在真空中传输速度为每秒30万公里,这里假设光纤为光速的2/3),那么客户端在1秒内大约只能执行80次左右的命令,这个和Redis的高并发高吞吐特性背道而驰。
Pipeline (流水线)机制能改善上面这类问题,它能将一组Redis命令进行组装,通过一次RTT传输给Redis,再将这组Redis命令的执行结果按顺序返回给客户端,图3-5为没有使用Pipeline执行了n条命令,整个过程需要n次RTT。
图3-6为使用Pipeline 执行了n次命令,整个过程只需要1次RTT。
Pipeline 并不是什么新的技术或者机制,很多技术上都是用过。而且RTT在不同的网络环境下是有所不同的,同机房和同机器会比较快,跨机房或者跨地区会比较慢。Redis命令真正执行的时间通常都是在微秒级别的,所以才会有Redis性能瓶颈是网络这样的说法。
redis-cli的--pipe选项实际上就是使用Pipeline 机制,例如下面操作将set hello world和incr counter两条命令组装:
但是大部分开发人员更倾向于使用高级语言客户端中的Pipeline,目前大部分Redis客户端都是支持Pipeline,例如java的Redis客户端Jedis。
表3-1给出了在不同的网络环境下非Pipeline和Pipeline执行10000次set操作的效果,可以得出如下2个结论:
可以使用Pipeline模拟出批量操作的效果,但是在使用时要注意它与原生批量命令的区别,具体包含以下几点:
Pipeline虽然好用,但是每次Pipeline组装的命令个数不能没有节制,否则一次组装Pipeline数据量过大,一方面会增加客户端的等待时间,另一方面会造成一定的网络阻塞,可以将一次包含大量命令的Pipeline拆分成多次较小的Pipeline来完成。
Pipeline只能操作1个Redis实例,但是即使在分布式Redis场景中,也可以作为批量操作的重要优化手段,后序博客还会对此进行介绍。
为了保证多条命令组合的原子性,Redis提供了简单的事务功能以及集成Lua脚本来解决这个问题。
首先这里简要说明一下Redis关于事务处理部分的4个常用命令:
Redis提供了简单的事务功能,将一组需要一起执行的命令放到multi和exec两个命令之间。multi命令代表事务开始,exec命令代表事务结束,它们之间的命令是原子顺序执行的,例如下面操作实现了上述用户关注问题。
可以看到sadd命令此时返回结果是QUEUED,代表命令并没有真正执行,而是暂时保存在Redis中。如果此时另一个客户端执行sismember user:a:follow user:b 返回结果为0。(即判断value是否在key的集合中)
当执行exec后,用户A关注用户B的行为才算是完成,如下所示返回的两个结果对应sadd命令。
如果要停止事务的执行,可以使用discard命令替代exec命令即可。
【redis 学习系列08】Redis小功能大用处02 Pipeline、事务与Lua
标签:实例 流水线 通过 存在 增加 mil ica ping mem
原文地址:https://www.cnblogs.com/xuelisheng/p/10805695.html