综述

        客户端缓存是指在客户端缓存服务器返回的结果，例如谷歌浏览器中会保存页面请求等其他类型请求的缓存。

优点：

        客户端角度，避免了再次请求，直接从本地缓存中获取响应内容，速度更快。

        服务器角度，减少了请求次数，减轻了服务器的压力。

缺点：

        客户端与服务器的数据同步，客户端的数据不能是脏数据。难点的解决方案有两种，默认方案，广播方案。

适用场景：

        当key值改动较少，以查询为主。

        遵循现实情况中的2,8定律，当前key值频繁的被访问。

默认方案

In the default mode, the server remembers what keys a given client accessed, and sends invalidation messages when the same keys are modified. This costs memory in the server side, but sends invalidation messages only for the set of keys that the client might have in memory.

        在服务器端，记录客户端访问key值的历史，当这些key修改后，给客户端发送一条key invalid的消息。

流程： 

        第一步，客户端开启本地缓存，命令为：CLIENT TRACKING ON

        第二步，客户端随意访问某个key。

        第三步，服务端发现该key被修改后，例如移除，修改key的值等，发送一条key invalid的消息。

        第四步，客户端接收到消息，在本地缓存中删除该key值。

原理：

        在服务器端保存一个invalidation table，记录客户端ID，访问的key值记录等信息。

缺点：

        当客户端较多或者是key值较多时，会占用服务器端较大的内存空间。解决方案是，在服务器端设置这部分功能的最大内存，设置客户端的最大值，设置每个客户端的key值历史最大值。

指定key:

// 添加OPTIN选项，此时服务器端默认不缓存
CLIENT TRACKING on OPTIN
// 客户端指定缓存，下一条指令中的key值被缓存。必须紧跟下一条指令
CLIENT CACHING YES
// 缓存test
get test

广播方案

        In the broadcasting mode, the server does not attempt to remember what keys a given client accessed, so this mode costs no memory at all in the server side. Instead clients subscribe to key prefixes such as object: or user:, and receive a notification message every time a key matching a subscribed prefix is touched

        客户端订阅某些key值的变化信息。服务端不在记录客户端访问key值的历史信息。

流程： 

        第一步，客户端开启本地缓存，指定广播方案。CLIENT TRACKING on BCAST PREFIX user:

        第二步，服务器端修改了user:为前缀的key值。发布了一条消息。

        第三步，客户端收到该条消息，清空本地缓存。

原理：

        为每个前缀建立一张表，记录前缀信息，订阅该前缀的客户端ID列表。

重定向

        redis可以指定其他客户端接收服务器端key无效的消息，假设客户端创建两个连接A，B。在A上执行指令，在B上专门接收服务器端key无效的消息。

示例：

        在A连接上指定B连接，接收消息

        CLIENT TRACKING ON REDIRECT CLIENTID(例如B的client ID)