本文探究Redis最新特性--客戶端緩存在SpringBoot上的應用實戰。
Redis Tracking
Redis客戶端緩存機制基於Redis Tracking機制實現的。我們先了解一下Redis Tracking機制。
為什么需要Redis Tracking
Redis由於速度快、性能高，常常作為MySQL等傳統數據庫的緩存數據庫。但由於Redis是遠程服務，查詢Redis需要通過網絡請求，在高並發查詢情景中難免造成性能損耗。所以，高並發應用通常引入本地緩存，在查詢Redis前先檢查本地緩存是否存在數據。
假如使用MySQL存儲數據，那么數據查詢流程下圖所示。
引入多端緩存后，修改數據時，各數據緩存端如何保證數據一致是一個難題。通常的做法是修改MySQL數據，並刪除Redis緩存、本地緩存。當用戶發現緩存不存在時，會重新查詢MySQL數據，並設置Redis緩存、本地緩存。
在分布式系統中，某個節點修改數據后不僅要刪除當前節點的本地緩存，還需要發送請求給集群中的其他節點，要求它們刪除該數據的本地緩存，如下圖所示。如果分布式系統中節點很多，那么該操作會造成不少性能損耗。
為此，Redis 6提供了Redis Tracking機制，對該緩存方案進行了優化。開啟Redis Tracking后，Redis服務器會記錄客戶端查詢的所有鍵，並在這些鍵發生變更后，發送失效消息通知客戶端這些鍵已變更，這時客戶端需要將這些鍵的本地緩存刪除。基於Redis Tracking機制，某個節點修改數據后，不需要再在集群廣播“刪除本地緩存”的請求，從而降低了系統復雜度，並提高了性能。
Redis Tracking的應用
下表展示了Redis Tracking的基本使用
（1）為了支持Redis服務器推送消息，Redis在RESP2協議上進行了擴展，實現了RESP3協議。HELLO 3命令表示客戶端與Redis服務器之間使用RESP3協議通信。
注意：Redis 6.0提供了Redis Tracking機制，但該版本的redis-cli並不支持RESP3協議，所以這里需要使用Redis 6.2版本的redis-cli進行演示。
（2）CLIENT TRACKING on命令的作用是開啟Redis Tracking機制，此后Redis服務器會記錄客戶端查詢的鍵，並在這些鍵變更后推送失效消息通知客戶端。失效消息以invalidate開頭，后面是失效鍵數組。
上表中的客戶端 client1 查詢了鍵 score 后，客戶端 client2 修改了該鍵，這時 Redis 服務器會馬上推送失效消息給客戶端 client1，但 redis-cli 不會直接展示它收到的推送消息，而是在下一個請求返回后再展示該消息，所以 client1 重新發送了一個 PING請求。
上面使用的非廣播模式，另外，Redis Tracking還支持廣播模式。在廣播模式下，當變更的鍵以客戶端關注的前綴開頭時，Redis服務器會給所有關注了該前綴的客戶端發送失效消息，不管客戶端之前是否查詢過這些鍵。
下表展示了如何使用Redis Tracking的廣播模式。
說明一下CLIENT TRACKING命令中的兩個參數：
BCAST參數：啟用廣播模式。
PREFIX參數：聲明客戶端關注的前綴，即客戶端只關注cache開頭的鍵。
強調一下非廣播模式與廣播模式的區別：
非廣播模式：Redis服務器記錄客戶查詢過的鍵，當這些鍵發生變化時，Redis發送失效消息給客戶端。
廣播模式：Redis服務器不記錄客戶查詢過的鍵，當變更的鍵以客戶端關注的前綴開頭時，Redis就會發送失效消息給客戶端。
關於Redis Tracking的更多內容，我已經在新書《Redis核心原理與實踐》中詳細分析，這里不再贅述。
Redis客戶端緩存
既然Redis提供了Tracking機制，那么客戶端就可以基於該機制實現客戶端緩存了。
Lettuce實現
Lettuce（6.1.5版本）已經支持Redis客戶端緩存（單機模式下），使用CacheFrontend類可以實現客戶端緩存。
public static void main(String[] args) throws InterruptedException {
// [1]
RedisURI redisUri = RedisURI.builder()
.withHost("127.0.0.1")
.withPort(6379)
.build();
RedisClient redisClient = RedisClient.create(redisUri);
// [2]
StatefulRedisConnection<String, String> connect = redisClient.connect();
Map<String, String> clientCache = new ConcurrentHashMap<>();
CacheFrontend<String, String> frontend = ClientSideCaching.enable(CacheAccessor.forMap(clientCache), connect,
TrackingArgs.Builder.enabled());
// [3]
while (true) {
String cachedValue = frontend.get("k1");
System.out.println("k1 ---> " + cachedValue);
Thread.sleep(3000);
}
}
- 構建RedisClient。
- 構建CacheFrontend。
ClientSideCaching.enable開啟客戶端緩存，即發送“CLIENT TRACKING”命令給Redis服務器，要求Redis開啟Tracking機制。
最后一個參數指定了Redis Tracking的模式，這里用的是最簡單的非廣播模式。
這里可以看到，通過Map保存客戶端緩存的內容。 - 重復查詢同一個值，查看緩存是否生效。
我們可以通過Redis的Monitor命令監控Redis服務收到的命令，使用該命令就可以看到，開啟客戶端緩存后，Lettuce不會重復查詢同一個鍵。
而且我們修改這個鍵后，Lettuce會重新查詢這個鍵的最新值。
通過Redis的Client List命令可以查看連接的信息
> CLIENT LIST
id=4 addr=192.168.56.1:50402 fd=7 name= age=23 idle=22 flags=t ...
flags=t代表這個連接啟動了Tracking機制。
SpringBoot應用
那么如何在SpringBoot上使用呢？請看下面的例子
@Bean
public CacheFrontend<String, String> redisCacheFrontend(RedisConnectionFactory redisConnectionFactory) {
StatefulRedisConnection connect = getRedisConnect(redisConnectionFactory);
if (connect == null) {
return null;
}
CacheFrontend<String, String> frontend = ClientSideCaching.enable(
CacheAccessor.forMap(new ConcurrentHashMap<>()),
connect,
TrackingArgs.Builder.enabled());
return frontend;
}
private StatefulRedisConnection getRedisConnect(RedisConnectionFactory redisConnectionFactory) {
if(redisConnectionFactory instanceof LettuceConnectionFactory) {
AbstractRedisClient absClient = ((LettuceConnectionFactory) redisConnectionFactory).getNativeClient();
if (absClient instanceof RedisClient) {
return ((RedisClient) absClient).connect();
}
}
return null;
}
其實也簡單，通過RedisConnectionFactory獲取一個StatefulRedisConnection連接，就可以創建CacheFrontend了。
這里RedisClient#connect方法會創建一個新的連接，這樣可以將使用客戶端緩存、不使用客戶端緩存的連接區分。
結合Guava緩存
Lettuce的StatefulRedisConnection類還提供了addListener方法，可以設置回調方法處理Redis推送的消息。
利用該方法，我們可以將Guava的緩存與Redis客戶端緩存結合
@Bean
public LoadingCache<String, String> redisGuavaCache(RedisConnectionFactory redisConnectionFactory) {
// [1]
StatefulRedisConnection connect = getRedisConnect(redisConnectionFactory);
if (connect != null) {
// [2]
LoadingCache<String, String> redisCache = CacheBuilder.newBuilder()
.initialCapacity(5)
.maximumSize(100)
.expireAfterWrite(5, TimeUnit.MINUTES)
.build(new CacheLoader<String, String>() {
public String load(String key) {
String val = (String)connect.sync().get(key);
return val == null ? "" : val;
}
});
// [3]
connect.sync().clientTracking(TrackingArgs.Builder.enabled());
// [4]
connect.addListener(message -> {
if (message.getType().equals("invalidate")) {
List<Object> content = message.getContent(StringCodec.UTF8::decodeKey);
List<String> keys = (List<String>) content.get(1);
keys.forEach(key -> {
redisCache.invalidate(key);
});
}
});
return redisCache;
}
return null;
}
- 獲取Redis連接。
- 創建Guava緩存類LoadingCache，該緩存類如果發現數據不存在，則查詢Redis。
- 開啟Redis客戶端緩存。
- 添加回調函數，如果收到Redis發送的失效消息，則清除Guava緩存。
Redis Cluster模式
上面說的應用必須在Redis單機模式下（或者主從、Sentinel模式），遺憾的是，
目前發現Lettuce（6.1.5版本）還沒有支持Redis Cluster下的客戶端緩存，
簡單看了一下源碼，目前發現如下原因：
Cluster模式下，Redis命令需要根據命令的鍵，重定向到鍵的存儲節點執行。
而對於“CLIENT TRACKING”這個沒有鍵的命令，Lettuce並沒有將它發送給Cluster中所有的節點，而是將它發送給一個固定的默認的節點（可查看ClusterDistributionChannelWriter類），所以通過StatefulRedisClusterConnection調用RedisAdvancedClusterCommands.clientTracking方法並沒有開啟Redis服務的Tracking機制。
這個其實也可以修改，有時間再研究一下。
需要注意的問題
那么單機模式下，Lettuce的客戶端緩存就真的沒有問題了嗎？
仔細思考一下Redis Tracking的設計，發現使用Redis客戶端緩存有兩個點需要關注：
- 開啟客戶端緩存后，Redis連接不能斷開。
如果Redis連接斷了，並且客戶端自動重連，那么新的連接是沒有開啟Tracking機制的，該連接查詢的鍵不會受到失效消息，后果很嚴重。
同樣，開啟Tracking的連接和查詢緩存鍵的連接必須是同一個，不能使用A連接開啟Tracking機制，使用B連接去查詢緩存鍵（所以客戶端不能使用連接池）。
Redis服務器可以設置timeout配置，自動超過該配置沒有發送請求的連接。
而Lettuce有自動重連機制，重連后的連接將收不到失效消息。
有兩個解決思路：
（1）實現Lettuce心跳機制，定時發送PING命令以維持連接。
（2）即使使用心跳機制，Redis連接依然可能斷開（網絡跳動等原因），可以修改自動重連機制（ReconnectionHandler），增加如下邏輯：如果連接原來開啟了Tracking機制，則重連后需要自動開啟Tracking機制。
需要注意，如果使用的是非廣播模式，需要清空舊連接緩存的數據，因為連接已經變更，Redis服務器不會將舊連接的失效消息發送給新連接。
- 啟用緩存的連接與未啟動緩存的連接應該區分。
這點比較簡單，上例例子中都使用RedisClient#connect方法創建一個新的連接，專用於客戶端緩存。
客戶端緩存是一個強大的功能，需要我們去用好它。可惜當前暫時還沒有完善的Java客戶端支持，本書說了我的一些分析與思路，歡迎探討。我后續會關注繼續Lettuce的更新，如果Lettuce提供了完善的Redis客戶端緩存支持，再更新本文。
關於Redis Tracking的詳細使用與實現原理，我在新書《Redis核心原理與實踐》做了詳盡分析，文章最后，介紹一下這本書：
本書通過深入分析Redis 6.0源碼，總結了Redis核心功能的設計與實現。通過閱讀本書，讀者可以深入理解Redis內部機制及最新特性，並學習到Redis相關的數據結構與算法、Unix編程、存儲系統設計，分布式系統架構等一系列知識。
經過該書編輯同意，我會繼續在個人技術公眾號（binecy）發布書中部分章節內容，作為書的預覽內容，歡迎大家查閱，謝謝。
語雀平台預覽：《Redis核心原理與實踐》
京東鏈接