https://www.imooc.com/article/313200
https://redis.io/topics/client-side-caching
我们应该都知道，redis作为缓存中间件，目的是为了减少热点数据对数据库的压力，并且提供更快的访问速度，redis的性能要比普通数据库快很多。
但是redis也有瓶颈上线，因为请求到redis一定会有网络io的损耗，并且也有数据的序列化以及反序列化的等等的一些开销，所以如果在本地把热数据再做一次缓存的话（Guava Cache 进程缓存，可能会有不一致的情况），那么可以使得请求性能更好，加速访问，提升客户端的响应速度了，因为数据延迟就降低并且减少了很多嘛。
大家可以想一下，什么场景下可以使用？
其实只要满足大量的请求，不怎么更改的数据，都可以。比如数据字典，我们的项目中涉及到一些超大型物流车的参数信息，这些基本上不会变动的，除非有相关的一些政策改变，那么有些参数信息就要变更，要不然直接存本地缓存是非常舒服的。
可以看一下这图，他本质上就是基于redis-server服务端来维系和应用后端的关系，用的pub/sub发布订阅的通知机制，如果服务端缓存发生更改，那么可以向应用后端来推送，让其更新本地缓存。
其中应用是指的我们的部署的项目，调用端。
了解一下：在Reds6之前的版本，使用的是RESP2协议，现在是RESP3，这个是REdisSerializationProtocol，是 Redis 服务端与客户端之间通信的协议。
实现客户端缓存的方式 - 默认模式
Redis-server 服务端会记录客户端访问了哪些key，这客户端id与key有唯一的映射关系，当其中的key发生变更时给客户端发送失效信息。这种模式会占用服务端所在服务器的内存。
实现客户端缓存的方式 - 广播机制
客户端订阅访问过的key的前缀，当符合的key发生变更就会被redis-server通知（如果变更的key没有被客户端缓存，也会通知），由于服务器端不记录客户端访问的key，所以不会过多占用redis-server端的服务器内存；
在这种模式下，服务端维护的是前缀key，而不是默认模式的所有key，所以这样对于内存的占用不会很高，只要修改匹配的前缀key，那么订阅的客户端都会收到失效key的通知。只不过由于定订阅的是前缀，他会收到很多的无效通知。
在广播模式下，只要符合客户端设置的key前缀的key发生新增、修改、删除、还有过期、淘汰等动作，即使该key没有被该客户端缓存，也会收到key的失效消息；
多级缓存
直播过程中提到了多级缓存架构，可以通过这图了解一下，更具体的可以做到4层，nginx可以做两层：
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/3263/viewspace-2826919/ ，如需转载，请注明出处，否则将追究法律责任。
