在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
3.1 Pipeline概念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.2 性能测试表3-1给出了在不同的网络环境下非Pipeline和Pipeline执行10000次set操作的效果,可以得出如下2个结论:
3.3 原生批量处理命令与Pipeline对比以及注意事项(1)比较可以使用Pipeline模拟出批量操作的效果,但是在使用时要注意它与原生批量命令的区别,具体包含以下几点:
(2)注意事项Pipeline虽然好用,但是每次Pipeline组装的命令个数不能没有节制,否则一次组装Pipeline数据量过大,一方面会增加客户端的等待时间,另一方面会造成一定的网络阻塞,可以将一次包含大量命令的Pipeline拆分成多次较小的Pipeline来完成。 Pipeline只能操作1个Redis实例,但是即使在分布式Redis场景中,也可以作为批量操作的重要优化手段,后序博客还会对此进行介绍。
4、事务与Lua为了保证多条命令组合的原子性,Redis提供了简单的事务功能以及集成Lua脚本来解决这个问题。 4.1 事务所谓的事务就是一组动作,要么全部执行,要么全不执行。例如在社交网站上用户A关注了用户B,那么需要在用户A的关注表中加入用户B,并且在用户B的粉丝表中添加用户A,这两个行为要么全部执行,要么全部不执行,否则会出现数据不一致的情况。首先这里简要说明一下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命令即可。
|
请发表评论