Redis6.0新特性：深入解析客户端缓存（Clientsidecaching）原理和性能，他的英文名字是：Redisserver-assistedclientsidecaching，能告诉我吗？我不是妓女，看完我会点赞、观看和分享。别装逼了，还用英文，你咋不上天啊，说话要守信用，不然半夜尿裤子。说到这里之前，马哥先给各位读者寄语一下。在开场白中不要吝啬你的赞美。如果有人做得好，给他积极的反馈，这也是一种利他主义。此外，少关注投票为“表扬”的事情，多关注投票为“交易”的事情。判断一个人牛不牛逼，不是有多少人在网上夸他，而是有多少人愿意和他交易、欣赏、支付、下单。因为夸奖太便宜了，愿意和他交易才是真正的信任。为什么需要客户端缓存Redis的TrackingFeature？实现代码在：https://github.com/antirez/redis/blob/unstable/src/tracking.c。很多公司使用Redis作为缓存系统，大大提高了数据访问的性能。为了进一步处理热点数据，Redis客户端会缓存一些热点数据，以应对“吃瓜事件”。比如《这该死的996祝福》、《吴亦凡慷慨入狱》、《时间管理大师》、《思聪不能舔我就打我》、《吴秀波的爱情，可以进监狱的那种》。..除了使用Redis缓存避免直接访问数据库外，还会增加更多的缓存层，比如使用Memcachced作为热点数据的本地缓存：首先在Memcachced中查询数据，命中后直接返回。如果Memcachced未命中，它会再次从Redis中查询，如果命中，它会返回数据并将这些数据保存在Memcachced中。如果Redis未命中，则去MySQL中查询，依次在Redis和Memcachced中设置。访问本地内存的性能势必会比通过网络访问Redis更快，所以这种模式可以大大降低获取数据的延迟，可以减轻Redis的负载，提高性能。访问Redis获取数据，服务器响应。使用客户端缓存，应用程序将在应用程序中获取的热点数据存储起来，而无需再次通过网络访问Redis。应该缓存什么我们不应该缓存不断变化的键。我们不应该缓存很少请求的键。我们希望缓存频繁请求并以合理的速率更改的键。对于没有稳定变化率的例子，比如一个不断被INCR修改的全局计数器，它不应该被缓存。客户端缓存实现原理代码又老又湿，Redis中的数据被修改或失效，如何及时同步通知客户端失效？自己做太麻烦了。Redis实现了一个称为跟踪的服务器辅助客户端缓存。客户端缓存的命令为：CLIENTTRACKINGON|OFF[REDIRECTclient-id][PREFIXprefix][BCAST][OPTIN][OPTOUT][NOLOOP]Redis6.0实现了Tracking功能，提供了两种模式来解决这个问题，即普通模式和广播模式使用RESP3协议版本，转发模式使用RESP2协议版本。*普通模式开启跟踪后，Redis会“记住”每个客户端请求的key，当key的值发生变化时，会向客户端发送失效消息。失效信息可以通过RESP3协议发送给发出请求的客户端，或者转发给不同连接上的客户端（支持RESP2+Pub/Sub）。服务器端将客户端访问的key和key对应的clientID列表信息保存在一个全局唯一的表（TrackingTable）中。当表已满时，它将删除最旧的记录并触发通知客户端该记录已过期结束。每个Redis客户端都有一个唯一的数字ID。TrackingTable存储每个ClientID。当连接断开时，该ID对应的记录被清除。TrackingTable表中记录的Key信息不考虑属于哪个数据库。虽然访问了db1的key，但是当db2中的同名key被修改时，客户端会收到过期提示，但是这样会降低系统的复杂度和表数量的存储数据。代码又老又湿，能说说这个TrackingTable的原理吗？Redis服务器使用TrackingTable以普通模式存储客户端数据，其数据类型为radixtree。基数树是一种用于稀疏长整数数据搜索的多叉搜索树，可以快速完成映射，节省空间。Redis使用它来存储键指针和客户端ID之间的映射。因为key对象的指针是内存地址，也就是长整型数据。客户端缓存的相关操作是对数据进行增删改查：注意服务端只会对记录的key上报invalidate消息，即服务端向客户端发送invalidate消息后，如果key被再次删除修改，此时服务端不会再向客户端发送invalidate报文。只有下次客户端再次执行只读命令并被跟踪时，才会发送下一条消息通知。客户端默认不开启跟踪模式。获取执行命令前我们需要先执行enable命令：CLIENTTRACKINGON|OFF+OKGETuser:211$3公众号:Broadcastmode(BCAST)当广播模式（broadcasting）开启时，服务器不记得哪些键被给定的客户端访问，所以这种模式在服务器端根本不消耗内存。在这种模式下，服务器会将所有密钥的失效广播给客户端。如果频繁修改密钥，服务器会发送大量的失效广播报文，消耗大量的网络带宽资源。因此，在实际应用中，我们设置客户端进行注册，只跟踪指定前缀的key。当注册跟踪的键前缀匹配被修改时，服务器将向所有与该键前缀相关的客户端广播失效消息。clienttrackingonbcastprefixuser，一种使用前缀监视密钥的广播模式，非常符合我们对密钥的命名约定。在实际应用中，我们会为同一个服务下的key设置相同的服务名前缀，这样我们就可以很方便的使用广播方式。广播模式类似于普通模式。Redis使用PrefixTable以广播方式存储客户端数据，其中存储了前缀字符串指针与（要通知的key和客户端ID）的映射关系。转发模式，普通模式和广播模式，需要客户端使用RESP3协议，RESP3协议是Redis6.0新启用的协议。对于使用RESP2协议的客户端，实现客户端缓存需要另一种模式：重定向模式（redirect）。RESP2不能直接PUSH失效消息，所以需要另外一个支持RESP3协议的客户端告诉服务器通过Pus/Sub通知RESP2客户端失效消息。在重定向模式下，想要收到失效消息通知的客户端需要执行订阅命令SUBSCRIBE专门订阅通道_redis_:invalidate来发送失效消息。同时，使用另一个客户端，执行CLIENTTRACKING命令，设置服务器使用RESP2协议将失效报文转发给客户端。假设客户端B想要获取失效消息，但是客户端B只支持RESP2协议，客户端A支持RESP3协议。我们可以分别在客户端B和A上执行SUBSCRIBE和CLIENTTRACKING，如下：//客户端B执行，客户端B的ID号为606SUBSCRIBE_redis_:invalidate//客户端A执行CLIENTTRACKINGONBCASTREDIRECT606B客户端可以拿到失效消息通过_redis_:invalidate通道。热门推荐Redis新特性：多线程模型解读Redis实战：利用geo类型实现附近人偶遇女神Redis面霸：从高频问题看核心原理
