内容简介:Redis 6.0Redis 6.0的新特性也是在一步步的讨论和优化中确定的。很多的特性已经在之前的RC等版本中介绍过了。
Redis 6.0 发布 了。
Redis 6.0的新特性也是在一步步的讨论和优化中确定的。
很多的特性已经在之前的RC等版本中介绍过了。
但是正式GA版中也有一些新的变化:
- SSL
- ACL : 更好,命令支持
- RESP3
- Client side caching :重新设计
- Threaded I/O
- Diskless replication on replicas
- Cluster support in Redis-benchmark and improved redis-cli cluster support
- Disque in beta as a module of Redis : 开始侵入消息队列领域
- Redis Cluster Proxy
- 支持RDB不再使用时可立即删除,针对不落盘的场景
- PSYNC2: 优化的复制协议
- 超时设置支持更友好
- 更快的RDB加载,20% ~ 30%的提升
- STRALGO,新的字符串命令,目前只有一个实现LCS (longest common subsequence)
@antirez 提到只是 Redis 历史上最大的一次版本更新,所以谨慎建议在应用的产品中还是多多测试评估,并且承诺一旦遇到大的bug就会紧急发布6.0.1版。果不其然,一天后就发布了 6.0.1版,修复了一个allocator的bug,这个bug是为了优化而引入的,现在暂时去掉了。
I just released Redis 6.0.1. Unfortunately there was a bug in Redis 6.0.0 introduced just a few days before the release, that only happens when using the non-default allocator (libc malloc in this case triggers it). Optimization reverted, 6.0.1 released. Sorry for the issue.
本文主要关注 Client side caching (客户端缓存)这一特性。
一年前,当 @antirez 参加完纽约Redis大会后,5:30就在旅店中醒来了,面对曼哈顿街头的美丽景色,在芸芸众生中思索Redis的未来。,包括客户端缓存。
其实,客户端缓存特性是收到Redis Conf 2018的Ben Malec的影响,一下子打开了 @antirez 思路。 我们知道, 很多公司使用Redis做缓存系统,并且很好的提高了数据访问的性能,但是很多企业为了进一步应对热点数据,还是会在redis的client端缓存一部分热点数据,用来应对吃瓜事件。比如在微博我们经常遇到的是明星出轨、明星分分合合、突发事件等等,每年都会有几次突发的事件,微博除了使用Redis做缓存避免直接访问数据库,还会在前面加更多的cache层,比如 L1 cache
等,采用 memcached 等产品作为热数据的缓存。那么就有一个问题,如何能够 及时
的同步这些cache和redis的数据呢?Ben提供了非常有意思的想法。
伫立在曼哈顿的街头,@antirez 陷入了沉思,后来回到旅馆他开始实现初版的客户端的缓存。当然,最终Redis 6.0中实现和这个初版的实现差别很大,但是还显然,从客户端的演化过程中我们还是能看到@antirez对这个特性所在的权衡(tradeoff)。关于这个历史本文不做太多的介绍,因为我们更关注于这个特性最终是什么样子的。
Redis实现的是一个服务端协助的客户端缓存,叫做 tracking
。客户端缓存的命令是:
CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN] [OPTOUT] [NOLOOP]
当 tracking
开启时, Redis会"记住"每个客户端请求的key,当key的值发现变化时会发送失效信息给客户端(invalidation message)。失效信息可以通过RESP3协议发送给请求的客户端,或者转发给一个不同的连接(支持RESP2+ Pub/Sub)。
当广播模式(broadcasting)开启时,参与 tracking
的客户端会收到它通过前缀订阅的key的相关的通知,即使它没请求过对应的key。同时还提供了 OPTIN
、 OPTOUT
等模式。
失效消息:当一个key的数据有修改的时候,需要告诉客户端它以前缓存的数据失效了,这时redis会主动发送一条失效消息
-
REDIRECT
: 将失效消息转发给另外一个客户端。当我们不使用RESP3而是使用老的RESP2和Redis通讯时,client本身不支持处理失效消息,所以可以开启一个支持Pub/Sub客户端处理失效消息。当然如果客户端支持RESP3也可以将失效消息转发给另外一个客户端。这个cace我们放在最后演示。 -
BCAST
: 使用广播模式开始
tracking
。在这种模式下客户端需要设置将track的key的前缀,这些key的失效消息会广播给所有参与的客户端,不管这些客户端是否请求/缓存额这些key。不开始广播模式时,Redis只会track那些只读命令请求的key,并且只会报告一次失效消息。 -
PREFIX
: 只应用了广播模式,注册一个key的前缀。所有以这个前缀开始的key有修改时,都会发送失效消息。可以注册多个前缀。如果不设置前缀,那么广播模式会track每一个key。 -
OPTIN
: 当广播模式没有激活时,正常 不会
track只读命令的key,除非它们在
CLIENT CACHING yes
之后被调用。 -
OPTOUT
: 当广播模式没有激活时,正常 会
track只读命令的key,除非它们在
CLIENT CACHING off
之后被调用。 - NOLOOP : 不发送client自己修改的key。
下面让我们一一介绍每个选项。
测试环境搭建
首先让我们介绍RESP3协议相关的选项, REDIRECT <id>
放在最后介绍。
在尝试之前,你首先需要安装一个redis 6.x的版本,目前时6.0.1。在官方网站上有源代码的下载,编译安装也很简单:
make distclean make make test sudo make install
相信很快就有编译好的二进制包可以下载。
启动server, 它会在6379端口启动一个服务:
redis-server
使用 redis-cli
访问,默认访问本机的6379实例:
redis-cli
当然你可以通过 -h
查看额外的参数配置,比如使用其它端口等等,这里我们使用最简单的例子,重点是了解客户端缓存的特性。
有时候为了更好的观察redis的返回结果,我们使用 telnet
而不是 redis-cli
作为client连接redis,因为redis-cli对结果做了处理,尤其是失效消息,你可能无法观测到。
BCAST 广播模式 ( client tracking on
)
启动redis server:
启动redis-cli:
当然,我们使用telnet来测试,方便观察redis的返回结果,刚才redis-cli用来更新key值,辅助测试。
连接上之后发送 hello 3
开启RESP3协议:
➜ ~ telnet localhost 6379 Trying ::1... Connected to localhost. Escape character is '^]'. hello 3 %7 $6 server $5 redis $7 version $5 6.0.1 ...... |
之后尝试开启 tracking
并读取 a
的值:
client tracking on +OK set a 1 +OK get a $1 1 |
这个时候如果使用redis-cli作为另外一个client更新 a
的值,telnet这个client应该能获得通知:
1 2 |
127.0.0.1:6379> set a 2 OK |
观察telnet,它收到了一个失效消息:
>2 $10 invalidate *1 $1 a |
注意它采用RESP3中的PUSH类型( >
)。
如果这个使用你再使用redis-cli更新 a
的值,telnet不会再收到失效消息。 除非telnet client再 get a
一次,重新 tracking
a的值。
可以随时取消 tracking
:
1 |
client tracking off |
tracking特定前缀的key ( client tracking on
)
上面的方式会tracking所有的key,如果你只想跟踪特定的key, 目前redis提供了一种方式,也就是前缀匹配的方式。你可以只tracking特定前缀的key。
它值应用了广播模式。
使用telnet client设定前缀和开启tracking:
hello 3 ....... client tracking on prefix a bcast +OK client tracking on prefix user bcast +OK |
我们tracking两个前缀,以 a
开头的所有的key和以 user
开头的所有的key,所有 a
开头的所有的key和以 user
开头的所有的key(包括 a
和 user
)的key变动时它应该都收到消息。
然后我们使用redis-cli更新三个key: abc
、 user:32432723213
和 feed:6532343243432
:
127.0.0.1:6379> set abc 100 OK 127.0.0.1:6379> set user:32432723213 good OK 127.0.0.1:6379> set feed:6532343243432 abc OK |
telnet client收到 abc
和 user:32432723213
的失效消息,而不会收到 feed:6532343243432
的失效消息:
>2 $10 invalidate *1 $3 abc >2 $10 invalidate *1 $16 user:32432723213 |
你可以通过 client tracking off
停止客户端缓存。目前貌似不能只停止对单个的前缀的 tracking
。 即使你使用 client tracking off prefix user
也是取消对所有的key的 tracking
。
...... } else if (!strcasecmp(c->argv[2]->ptr,"off")) { disableTracking(c); } else { ...... |
选择加入
如果使用 OPTIN
,可以有选择的开启 tracking
。 只有你发送 client caching yes
之后的下一条的只读命令的key才会 tracking
, 否则 其它的只读命令中的key不会tracking
。
首先我们开始 optin
,读取a的指,这个时候使用redis-cli client修改a的值为1000,我们并没有收到 a
的失效消息。
client tracking on optin +OK get a $1 2 |
接下来我们发送 client caching yes
,紧接着获取a的值,这个时候如果再修改a的值,你就可以收到一条a的失效消息:
client caching yes +OK get a $4 1000 >2 $10 invalidate *1 $1 a |
必须是紧跟着 client caching yes
吗?是的,比如发送下面的命令,只会 tracking
b,而不是a:
client caching yes +OK get b _ get a $4 2000 |
选择退出
如果使用 OPTOUT
,你也可以有选择的退出 tracking
。 只有你发送 client caching off
之后的下一条的只读命令的key才会停止 tracking
, 否则 其它的只读命令中的key都会被tracking
。
可以看到它和 OPTIN
正好相反,你可以根据你的场景来选择。
比如下面的例子,开启 OPTOUT
之后,对任意的key的变动都收到失效消息:
client tracking on optout +OK get a $4 3000 >2 $10 invalidate *1 $1 a |
这个时候如果我们想排除 b
这个key,可以只针对它进行设置:
client caching no +OK get b $1 3 |
之后对b的变动并不会收到b的失效消息。
注意: OPTIN
和 OPTOUT
是针对的非BCAST场景,也就是只有你发送了key的只读命令后,才会跟踪相应的key。而广播模式是无论你是否发送过key的只读命令,只要redis修改了key,都会发送相应key(或者匹配前缀的key)的失效消息。
NOLOOP
正常设置时,失效消息是发给所有参与的client,但是如果设置了 NOLOOP
,则不会发送给更新这个key的client。
client tracking on bcast noloop +OK set a 1 +OK client tracking off +OK client tracking on bcast +OK set a 1 +OK >2 $10 invalidate *1 $1 a |
注意,取消tracking只需调用 client tracking off
即可。
REDIRECT
最后,让我们看一下转发消息的处理。这是为了兼容RESP2协议一个处理方式,将失效消息转发给另外一个client。
首先我们查看redis-cli的client id:
1 2 |
127.0.0.1:6379> client list id=4 addr=127.0.0.1:61017 fd=8 name= age=33103 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client user=default |
使用telnet连接redis,查看client id:
1 2 |
client id :12 |
telnet 客户端开启订阅失效消息:
SUBSCRIBE __redis__:invalidate *3 $9 subscribe $20 __redis__:invalidate :1 |
然后我们就可以将redis-cli的失效消息转发给telnet client:
client tracking on bcast redirect 12 127.0.0.1:6379> set a 1000 OK |
可以看到telnet客户端收到了失效消息:
*3 $7 message $20 __redis__:invalidate *1 $1 a |
如果你要转发的目的client开启了RESP3协议,你就不需要RESP3 Pub/Sub了,因为RESP3原生支持Push消息。
redis的tracking feature的实现代码在: tracking.c 。
参考文档
以上所述就是小编给大家介绍的《Redis 6.0 客户端缓存特性及实践》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 客户端HTTP缓存
- 使用传统前端技术增强客户端缓存能力
- Redis 6.0 客户端缓存特性及实践
- Redis 6.0:客户端侧缓存特性,有点意思!
- [译] antirez:Redis 6 将支持客户端缓存
- 带你 100% 地了解 Redis 6.0 的客户端缓存
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Algorithms Unlocked
Thomas H. Cormen / The MIT Press / 2013-3-1 / USD 25.00
Have you ever wondered how your GPS can find the fastest way to your destination, selecting one route from seemingly countless possibilities in mere seconds? How your credit card account number is pro......一起来看看 《Algorithms Unlocked》 这本书的介绍吧!
在线进制转换器
各进制数互转换器
HSV CMYK 转换工具
HSV CMYK互换工具