2レベルキャッシュに関する前回の記事では、合計4つの実装スキームを示しました。ローカルキャッシュCaffeineとリモートキャッシュがプロジェクトに統合されRedis、唯一のリモートキャッシュだけでアプリケーションのパフォーマンスが向上しました。
現在、Hydraが共有したいテクノロジーは、上記の2レベルのキャッシュと概念が似ていますがRedis、他のローカルキャッシュミドルウェアを使用せずに、独自のサーバーとクライアントを使用することによってのみ実装できます。これはRedis6クライアント側のキャッシュの新機能であり、アプリケーションサーバーとリモートキャッシュClient-side cachingの両方にデータをキャッシュできます。
序章
クライアント側のキャッシュは、Redis6の多くの新機能の中で、より実用的な新機能です。公式ドキュメントを見て、その役割を理解しましょう。
クライアント側のキャッシュは、アプリケーションサーバー（通常はデータベースサーバー以外のノード）で使用可能なメモリを利用して、データベースの情報の一部を直接格納する高性能サービスを作成するための手法です。
データベースなどのネットワークサービスにアクセスする場合と比較して、ローカルメモリにアクセスするのにかかる時間が大幅に短縮されるため、このモードでは、アプリケーションがデータを取得するための遅延を大幅に減らし、データベースの負荷を軽減できます。
これを見て、私は自分自身に思いました。これは、グアバやカフェインのような他のローカルキャッシュと同じではありませんか？それは、スープを変更するために使用されるアプリケーションサービスのメモリにすぎません。何かメリットがあれば、プロジェクトにミドルウェアを1つ減らすことができるかもしれません。
しかし、クライアント側のキャッシングの特定のアプリケーションモードを読んだ後、私の浅い推測は完全に覆されました。
2つのモード
クライアント側のキャッシングの基本的な機能を理解した後、その2つの基本的なアプリケーションモードを見てみましょう。Redisのクライアント側キャッシュサポートはと呼ばれ、トラッキングtrackingキーに変換されると簡単に理解できます。2つのモードがあります。
- デフォルトモードでは、サーバーはクライアントがアクセスしたものを記録します
key。これらのkey対応する値が変更されると、サーバーはこれらのクライアントに無効化メッセージを送信します。このモードはサーバー上のメモリを消費しますが、無効化メッセージを送信する範囲は、クライアントによって保存されkeyたセットに制限されます - ブロードキャストモードでは、サーバーはクライアントがアクセスした内容を記録しなくなる
keyため、このモードはサーバーのメモリを消費しません。代わりに、クライアントはkey特定のプレフィックスをサブスクライブする必要があり、keyこのプレフィックスに一致する対応する値が変更されるたびに、クライアントは通知メッセージを受信します
これを見て、それと以前に使用した2レベルのキャッシュとの違いはすでに現れ始めていますか？2レベルのキャッシュのアーキテクチャに慣れていない場合は、最初に次の図を参照してください。
このアーキテクチャは理論的には見栄えがしますが、実際には注意が必要な点がたくさんあります。特に分散モードでは、各ホストの下で第1レベルのキャッシュの整合性を確保する必要があります。元のソリューションを思い出してください。 redis自体のパブリッシュ/サブスクライブ機能を使用して実装されます：
クライアント側のキャッシングの出現により、このプロセスが大幅に簡素化されます。例としてデフォルトモードを取り上げて、クライアント側のキャッシュを使用した後の操作プロセスを確認しましょう。
元のパブリッシュ/サブスクライブモデルと比較すると、明らかな利点があります。クライアント側のキャッシュ機能を使用した後は、redisでデータを変更するだけで済み、パブリッシュ/サブスクライブメッセージを手動で処理するプロセスを完全に省略できます。 。
アドバンテージ
この時点で、クライアント側キャッシングの基本機能と2つのモードを理解した後、クライアント側キャッシュが、redisと統合された2レベルキャッシュのみを使用する従来のリモートキャッシングと比較してみましょう。利点。
- アプリケーションのサーバー側にキャッシュがある場合、ローカルキャッシュが直接読み取られるため、ネットワークアクセスによる遅延が減少し、アクセス速度が向上します。
- 同時に、redisサーバーへのアクセス回数を減らし、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。
これを見ると、この転送モードは少し味がないように感じます。結局のところ、実際のビジネスシナリオでは複数のクライアントが存在する可能性があり、1つだけを転送するのは少し不合理です。ただし、作成者がこのように設計し、すべての人がより速くそれを受け入れることができるようにいくつかの欠陥を残している可能性もありますRESP3...
要約する
さて、クライアントサイドキャッシングの基本的な理論と使用法はここでほとんど紹介されています。Redis6のこの新機能は本当に私たちに明るい気持ちを与えてくれると言わざるを得ません。この新機能から、Redisには、サーバーの制限からキャッシュを解放し、それをクライアントにポイントして、川や湖を統一された方法でキャッシュするという意味があることもわかります。
ただし、前に述べたように、このプロセスは単純ではありません。結局のところ、Redisサーバーだけでは不十分であり、優れたクライアントサポートも必要です。
client-side caching次に、次の記事では、クライアントをプロジェクトで繁栄させるために、実用的な観点からクライアントを変換する方法を見てみましょう。
今回の共有はここにあります、私はハイドラです、次の記事でお会いしましょう。
公式ドキュメント：
著者のプロフィール、Code Farmer's Referenceは、テクノロジーについてあなたとチャットする、興味深く、詳細で、直接的な共有が大好きな公開アカウントです。個人的なWeChatDrHydra9、さらなるコミュニケーションのために友達を追加することを歓迎します。
ナゲッツテクノロジーコミュニティのクリエイター署名プログラムの募集に参加しています。リンクをクリックして登録し、送信してください。