redis6.0 客户端缓存(Client side caching)及实践
1. 什么是客户端缓存(Client side caching)
通常的缓存会放在应用和DB之间，比如redis。客户端缓存是指在应用服务内部再加一层缓存，也就是内存缓存，从而进一步提升访问速度。
2. redis 6.0为此做了什么
2.1 client cache的问题
client cache的问题是缓存应该何时失效，更确切的说是如何保持与远端数据的一致性。
为client cache设置过期时间是一个选择，但时间设置多久是一个问题。太长会有时效性问题，太短缓存的效果会打折扣。
2.2 redis 6.0 的解决方式
2.2.1 整体思想
redis在服务端记录访问的连接和相关的key， 当key有变化时，通知相应的连接(应用)。应用收到请求后自行处理有变化的key, 进而实现client cache与redis的一致。
redis对客户端缓存的支持方式被称为Tracking，分为两种模式：默认模式，广播模式。
2.2.2 默认模式
Server 端记录每个Client访问的Key，当发生变更时，向client推送数据过期消息。
- 优点：只对Client发送其访问过的被修改的数据
- 缺点：Server端需要额外存储较大的数据量。
2.2.3 广播模式
客户端订阅key前缀的广播(空串表示订阅所有失效广播)，服务端记录key前缀与client的对应关系。当相匹配的key发生变化时，通知client。
- 优点：服务端记录信息比较少
- 缺点：client会收到自己未访问过的key的失效通知。
2.2.4 RESP3协议
redis6.0开始使用新的协议RESP3。该协议增加了很多数据类型。新协议目的之一是支持客户端缓存。想对新协议有更多了解可以参看如下两篇文章：
- RESP3 specification
- 读写 Redis RESP3 协议以及Redis 6.0客户端缓存
这里，我们只关注与客户端缓存相关的部分
- hello命令: client告知服务端使用的协议版本，服务端返回一些简要的版本。发送hello 2, 表示使用RESP2， hello 3表明使用RESP3协议。默认开始的是RESP2。
- client tracking on/off: 开启/关闭tracking
- push数据：带外数据，它是redis主动推送的数据。向client推送的数据过期消息即是通过此协议实现的。
注意: 只有开启hello 3的端，才能接收push数据(key失效数据)
2.2.5 redirect
使用Redis 6支持的新版Redis协议RESP3，可以在同一个连接中运行数据的查询和接收失效消息。不过，许多客户端实现可能倾向于使用两个单独的连接来实现客户端缓存：一个用于数据，另一个用于失效消息。redis通过redirect支持这一功能。
当一个客户端开启tracking后，它可以通过设置另一连接的“client id ”将失效的消息重定向(redirect)到另一个连接。多个数据连接可以将失效消息重定向到同一连接，这对于实现了连接池的客户端会很有用。
2.2.6 RESP2怎么办？
结合redirect和sub/pub，对于只支持resp2协议的client也可以实现对失效数据的接收。redis官方有介绍，这里不着重讲述了。有兴趣可以点击这里查看。
3. 演示
使用之前，你需要安装redis6.0。 注意，编译时需要gcc 6.0或以上版本。遗憾的是，6.0自带的redis-cli对RESP3的支持也不好，解析不了push数据>_<|||, 所以，想看push的真面目，用telnet吧！
3.1 默认模式
telnet 1.1.1.1 6379
//开启RESP3
hello 3
%7
$6
server
$5
redis
$7
version
$5
6.0.6
$5
proto
:3
$2
id
:514
$4
mode
$10
standalone
$4
role
$6
master
$7
modules
*0
//开启tracking
client tracking on
+OK
get name
$4
ball
//在另一个client上改变name值, 当前连接收到push数据， name invalidate
>2
$10
invalidate
*1
$4
name
说明:
- client tracking on之后get的key才会收到相应的失效通知。
- 所谓key值的改变需要理解两点
- 不一定是真的变，只要另一端对key执行了set操作，无论set的是否是原值，服务端都会向相应tracking发送失效通知。
- 不仅是set操作，del, 或者redis中的key因为过期而被删除，相应的tracking端都会收到失效通知。
- 将client上收到某个key的失效通知后，只有该client再次get此key后才会继续收到此key的失效通知。
比如上例中，只有再次执行get name, 后续name值被改变，该端才会再收到失效通知。
3.2 广播模式
telnet 1.1.1.1 6379
//开启REPS3
hello 3
//节省篇幅，省略输出
... ...
//未加prefix, 接收所有失效广播
client tracking on bcast
+OK
//在另一个client上改变name值, 当前连接收到push数据， name invalidate
>2
$10
invalidate
*1
$4
name
3.3 redirect
我们构造如下场景
- client 1开启hello 3
- client 2开启tracking并将失效通知重定向到client 1
- client 3改变client 2关注的key值
相关命令及输出如下：
说明：
- 只有需要接收push消息的端，才必须开启resp3, 所以上例中只有client1执行了hello 3， client2未执行。
- 若N个client将失效通知重定向到client 1, 且这N个client都关注了name(执行过get name), 那么当client 3执行del name时，client 1将收到N条name invalidate消息。
- 无论是默认模式或redirect模式，若tracking端断开连接，对应的失效消息都不会发出。
4. 工程中的实现思路
那么在web应用中该如何结合redis实现客户端缓存呢，我们有如下考量：
- 1)进程内使用hash map做为localcache。这意味着，服务进程要常驻内存。
- 2)为了节省redis内存，同时减少redis与client的失效(push)通信。在进程内使用单独的线程或协程接通过广播模式接收所有失效通知似乎是比较划算的选择。另外实现起来也会比较容易，不需要在同一个连接中即处理push，又处理普通消息。
- 3)基于2, 即使某种编程语言暂时没有实现resp3的库或扩展，那么自己用tcp写一个也不麻烦。只要发hello和收push就行。
5. go中的实现
基于4的考量，感觉用go实现一个client side caching的demo是比较方便的。
我们找一个支持resp3的包。
go get github.com/stfnmllr/go-resp3/client
以下代码模拟了一个http服务，处理search请求。
- 全局变量localCache为进程内缓存
- 主协程协建立一个redis连接，用于接收所有广播的失效通知。收到某key的失效通知后，清理localCache。
- search为业务处理方法，它会先查localCache是否有业务数据，如果没有，则查redis，查到后将其写入localCache.
package main
import (
"fmt"
"log"
"net/http"
"strings"
"github.com/stfnmllr/go-resp3/client"
)
//本地缓存
var localCache = make(map[string]string)
//请求处理函数
func search(w http.ResponseWriter, r *http.Request) {
tmp, ok := r.URL.Query()["key"]
if !ok || len(tmp) == 0 {
w.Write([]byte("param key err"))
return
}
key := strings.Join(tmp, "")
val, ok := localCache[key]
//localCache中无数据
if !ok {
dialer := new(client.Dialer)
conn, err := dialer.Dial("10.160.75.237:6379")
if err != nil {
w.Write([]byte(err.Error()))
}
defer conn.Close()
val, err = conn.Get(key).ToString()
if err != nil {
w.Write([]byte("no val"))
fmt.Printf("no val for key:%s\n", key)
return
}
//写localCache
localCache[key] = val
fmt.Printf("get from redis key:%s v:%s\n", key, val)
} else {
fmt.Printf("get from localcache key:%s v:%s\n", key, val)
}
w.Write([]byte(val))
}
func main() {
// Create connetion providing key invalidation callback.
dialer := new(client.Dialer)
//失效通知回调
dialer.InvalidateCallback = func(keys []string) {
for _, key := range keys {
delete(localCache, key)
fmt.Printf("clear localCache %s\n", key)
}
}
conn, err := dialer.Dial("10.160.75.237:6379")
if err != nil {
log.Fatal(err)
}
broadcast := true
if err := conn.ClientTracking(true, nil, nil, broadcast, false, false, false).Err(); err != nil {
log.Fatal(err)
}
http.HandleFunc("/search", search)
http.ListenAndServe(":8000", nil)
}
只是为了演示思路，所以代码是有不完善之处的, 比如
- localcache没有时数据，可以控制只有一个协程去redis取数据，而不诸多协程时同穿透。
- 单一协程接收所有失效通知时，有可能产race condition的。代码中关没有处理。处理的方法，在redis官方有所提及，可以点这里查看。
6. php怎么办
php-fpm的方式，不容易实现4中的思路。但想了想，似乎也有变通的方式。
- 进程内缓存我们可以使用共享内存来模拟，比如apcu
- 单独在fpm外启动一个常驻的php进程，监听失效请求，当接到失效请求后，删除共享内存中的key。
- php暂时没有找到支持resp3的扩展，只能用tcp方式实现hello和push解析。
7. 参考
-
官方Redis server-assisted client side caching
-
Redis系列(十四)、Redis6新特性之RESP3与客户端缓存(Client side caching)
-
go-resp3 doc