En el artículo anterior sobre el caché de dos niveles , dimos un total de 4 esquemas de implementación. El caché local Caffeiney el caché remoto se integraron en el proyecto, Redislo que mejoró el rendimiento de la aplicación desde el único caché remoto solo. .
Hoy en día, la tecnología que Hydra quiere compartir con usted es similar en concepto al caché de dos niveles anterior, pero Redissolo puede implementarse utilizando su propio servidor y cliente sin la ayuda de otro middleware de caché local. Esta es una característica nueva Redis6en el almacenamiento en caché del lado del cliente Client-side caching, que permite que los datos se almacenen en caché tanto en el servidor de aplicaciones como en el caché remoto .
Introducción
El almacenamiento en caché del lado del cliente es una característica nueva más práctica entre las muchas características nuevas de Redis 6. Echemos un vistazo a la documentación oficial para comprender su función:
El almacenamiento en caché del lado del cliente es una técnica para crear servicios de alto rendimiento que utilizan la memoria disponible en los servidores de aplicaciones (que generalmente son nodos que no son servidores de bases de datos) para almacenar directamente parte de la información de la base de datos.
En comparación con el acceso a servicios de red como las bases de datos, se necesita mucho menos tiempo para acceder a la memoria local, por lo que este modo puede reducir en gran medida la demora de las aplicaciones para obtener datos y también reducir la presión de carga en la base de datos.
Al ver esto, pensé, ¿no es lo mismo que otros cachés locales como Guava y Caffeine? Es solo la memoria del servicio de la aplicación que se usa para cambiar la sopa o no. Si hay algún beneficio, puede ser que pueda introducir un middleware menos en el proyecto.
Sin embargo, mi conjetura superficial se anuló por completo después de leer el modo de aplicación específico del almacenamiento en caché del lado del cliente.
dos modos
Después de comprender las funciones básicas del almacenamiento en caché del lado del cliente, echemos un vistazo a sus dos modos básicos de aplicación. El soporte de caché del lado del cliente de Redis se llama , y es fácil de entender cuando se trackingtraduce en claves de seguimiento . Tiene dos modos:
- En el modo predeterminado, el servidor registrará a cuáles ha accedido un cliente,
keycuando estoskeyvalores correspondientes cambien, enviará un mensaje de invalidación a estos clientes.keyEste modo consumirá algo de memoria en el servidor, pero el alcance del envío de mensajes de invalidación se limita al conjunto almacenado por el cliente . - En el modo de difusión, el servidor ya no registrará a qué ha accedido un cliente
key, por lo que este modo no consume memoria del servidor. En cambio, el cliente debe suscribirsekeya un prefijo específico, y cada vezkeyque cambie el valor correspondiente que coincida con este prefijo, el cliente recibirá un mensaje de notificación.
Al ver esto, ¿ya ha comenzado a surgir la diferencia entre este y el caché de dos niveles que usamos antes? Si no está familiarizado con la arquitectura del caché de dos niveles, primero puede echar un vistazo a la siguiente imagen:
Esta arquitectura se ve bien en teoría, pero hay muchos puntos a los que prestar atención en la práctica, especialmente en el modo distribuido, es necesario garantizar la consistencia del caché de primer nivel debajo de cada host, recuerde nuestra solución original , que puede ser implementado usando la función de publicación/suscripción de redis en sí :
La aparición del almacenamiento en caché del lado del cliente simplifica enormemente este proceso. Tomemos el modo predeterminado como ejemplo para ver el proceso de operación después de usar el almacenamiento en caché del lado del cliente:
En comparación con el modelo original de publicación/suscripción, podemos ver ventajas obvias. Después de usar la función de almacenamiento en caché del lado del cliente, solo necesitamos modificar los datos en redis, y el proceso de procesamiento manual de mensajes de publicación/suscripción se puede omitir por completo. .
Ventaja
En este punto, después de comprender las funciones básicas y los dos modos de almacenamiento en caché del lado del cliente, comparemos lo que tiene el caché del lado del cliente con el almacenamiento en caché remoto tradicional que solo usa redis y el caché integrado de dos niveles.
- Cuando hay un caché en el lado del servidor de la aplicación, el caché local se leerá directamente, lo que puede reducir la demora causada por el acceso a la red y, por lo tanto, acelerar la velocidad de acceso.
- Al mismo tiempo, también puede reducir la cantidad de visitas al servidor redis y reducir la presión de carga de redis.
- 在分布式环境下，不再需要通过发布订阅来通知其他主机更新本地缓存，来保证数据的一致性。使用客户端缓存后，它所具有的原生的消息通知功能，能很好地支持作废本地缓存，保证之后访问时能取到更新后的新数据
误区
在开始演示客户端缓存的使用之前，我们先来纠正一个误区。
虽然这个新特性被称为客户端缓存，但是redis本身不提供在应用服务端缓存数据的功能，这个功能要由访问redis的客户端自己去实现。
说白了，也就是redis服务端只负责通知你，你缓存在应用服务本地的这个key已经作废了，至于你本地如何缓存的这些数据，redis并不关心，也不负责。
功能演示
下面将通过一些实例来进行演示，本文代码的运行前提条件是你已经装好了Redis6.x版本，linux环境下可以直接从官网下载后编译安装，windows环境下的安装可以参考 手摸手教你在Windows环境下运行Redis6.x 这篇文章。
概念上的东西我们也大体了解了，下面我们分别来看一下客户端缓存具体实现的三种模式（至于为什么多了一种，后面再来细说）。在正式开始前，强烈建议大家先花个十几分钟了解一下 Redis6底层的通信协议RESP3，否则在看到具体的通信内容时可能会存在一些疑问。
首先做一下准备工作，通过telnet连接redis服务，并切换到resp3协议模式：
telnet 127.0.0.1 6379
hello 3
复制代码1、默认模式
在使用客户端连接到redis服务后，需要先通过指令开启tracking模式的功能，因为在客户端连接后这个选项是默认关闭的，会无法收到失效类型的push消息：
#开启
client tracking on
#关闭
client tracking off
复制代码当开启tracking后的默认模式下，redis服务端会记录每个客户端请求过的key，当key对应的值发生变化时，会发送失效信息给客户端。简单总结一下，也就是说这个模式能够生效的必要前提条件有两个：
- 开启
tracking - 客户端访问过某个key
下面我们还是在telnet中来模拟一下这个过程，分别启动两个redis客户端，在client1中先执行get命令后，再在client2对相同的key执行set操作修改它的值，之后就会在client1中收到push类型的消息。
push类型的消息我们在RESP3中介绍过了，这里简单再唠叨两句：
>2
$10
invalidate
*1
$4
user
复制代码起始的第一字节>表示该消息为push类型，后面消息体中包含了两部分内容，第一部分表示收到的消息类型为invalidate，也就是作废类型的信息，第二部分则是需要作废的key是user。
除此之外，当一个缓存的key到达失效时间导致过期，或是因为到达最大内存，要使用驱逐策略进行驱逐时，也会对客户端发送PUSH的消息。下面以缓存的key过期为例：
另外，对于单个key来说，这个tracking消息只会对客户端发送一次，当第二次修改该key所对应的值后，客户端不会再收到tracking的消息。只有对这个key再执行一次get命令，之后才会再次收到tracking消息。
默认模式虽然使用起来简单，但是需要在服务端存储客户端的访问数据，记录哪些key被哪些客户端访问过。如果访问的不是少量的热点数据的话，可能会占用大量redis服务端的内存空间。应对这种情况，可以试一试下面要介绍的广播模式。
2、广播模式
在广播模式BCAST下，redis服务端不再记录key的访问情况，而是无差别地向所有开启tracking广播的客户端发送消息。这样一来，好处就是不需要浪费redis服务端的内存进行记录，但是坏处就是客户端可能会收到过多的消息，其中可能还会包含自己不需要的一些key。
在使用前，需要先通过命令开启广播模式：
client tracking on bcast
复制代码下面，我们通过一个例子来进行广播模式的使用演示：
可以看到在开启广播模式后，只要在client2中修改了key对应的值，在client1中都会收到作废消息，而不管client1之前在本地是否进行过缓存。
并且，另外一点和默认模式不同的是，广播模式是能够重复多次收到一个key的失效消息的，因为服务端没有记录，所以只要有key发生了修改，客户端就会收到失效消息。
这时候，有的小伙伴可能就要问了，如果我不想收到这么多没用的冗余消息，有没有什么办法进行一下过滤或精简呢？
答案是可以的，在广播模式下，客户端可以只关注一些特定前缀的key，表示我只需要接收这些前缀的key，其他的就不要发给我了。命令格式如下：
client tracking on bcast prefix myprefix
复制代码再来看一下使用过程的示例：
可以看到，在设置了只关注以order:作为前缀的key后，成功过滤掉了user的失效消息。从这个角度来看，也要求了我们在缓存一个类型的数据时，都以相同的单词作为前缀，规范了我们在使用缓存中对key的命名规则。
至于在业务中具体要使用哪种模式，可能更多的需要进行一下权衡。看一下你究竟是能忍受占用更多redis服务端的内存，还是能够忍受收到大量不需要的失效消息。
3、转发模式
默认模式和广播模式的生效，都要在开启RESP3协议的前提下，具体原因看过上面的例子大家应该也都清楚了，因为要使用tracking的话，就必须要借助到RESP3协议中的新的push消息类型。
那么如果客户端还是使用的旧版本RESP V2的话，也想要体验这一功能，应该如何进行改造呢？
不得不说redis6的开发者想的还是蛮全面的，为了适配RESP V2，专门设计了一种新的转发模式，允许使用旧版本协议的客户端通过Pub/Sub发布订阅功能来接收key的失效信息。
从上面这张图可以看到，转发模式的核心就是redis服务端会将原先push类型的tracking信息，转发到订阅了_redis_:invalidate这一信道的被指定的客户端上。
我们来梳理一下上面的流程，首先在client1需要使用指令开启转发模式：
client tracking on bcast redirect [client-id]
复制代码相对广播模式，多了两个参数，redirect表示为转发模式，后面的client-id表示消息要发送给哪一个客户端，客户端的id可以在client2上通过client id指令获取。
在client2中，则需要订阅指定的信道：
subscribe _redis_:invalidate
复制代码其实说白了，转发模式还是使用的发布订阅功能罢了，只不过redis帮我们解放了双手，把发送消息的工作由自己完成了。整个操作的流程如下图所示：
可以看到，client2中收到的消息格式与之前的push类型消息不同，是一条RESP V2中多条批量回复格式的消息，表示的含义同样是收到的key已经作废掉了。
需要注意的是，虽然说开启转发模式的指令中也带了一个bcast，但是它和广播模式有着非常大的区别。在转发模式下，key的作废消息只能被转发到一个客户端上，如果先后执行两条指定转发指令，那么后执行的指令会覆盖前一指令中转发的client-id。
Al ver esto, siento que este modo de reenvío es un poco insípido. Después de todo, puede haber múltiples clientes en el escenario comercial real, y es un poco irrazonable reenviar solo uno. Sin embargo, también es posible que el autor lo haya diseñado así, dejando algunos defectos para que todos puedan abrazarlo más rápido RESP3...
Resumir
Bueno, aquí casi se presenta la teoría básica y el uso del almacenamiento en caché del lado del cliente. Tengo que decir que esta nueva característica de Redis6 realmente nos da una sensación brillante. También se puede ver en esta nueva característica que Redis tiene el significado de liberar el caché de las limitaciones del servidor y apuntarlo al cliente, para almacenar en caché los ríos y lagos de manera unificada.
Sin embargo, este proceso no debería ser simple, como dijimos antes, después de todo, solo el servidor Redis no es suficiente y también necesita una excelente atención al cliente.
Luego, en el próximo artículo, echemos un vistazo a cómo transformar al cliente desde un punto de vista práctico, para que client-side cachingpueda florecer en el proyecto.
Esta vez el compartir está aquí, soy Hydra, nos vemos en el próximo artículo.
Documentación oficial:
El perfil del autor, Code Farmer's Reference, una cuenta pública que le encanta compartir, interesante, profunda y directa, conversando contigo sobre tecnología. Personal WeChat DrHydra9, bienvenido a agregar amigos para una mayor comunicación.
Estoy participando en el reclutamiento del programa de firma de creadores de la Comunidad Tecnológica de Nuggets, haga clic en el enlace para registrarse y enviar .