redis實現多級緩存同步方案詳解
前言
前陣子參加業(yè)務部門的技術方案評審,故事的背景是這樣:業(yè)務部門上線一個專為公司高管使用的系統(tǒng)。這個系統(tǒng)技術架構形如下圖

按理來說這個系統(tǒng)因為受眾很小,可以說基本上沒并發(fā),業(yè)務也沒很復雜,但就是這么一個系統(tǒng),連續(xù)2次出現數據庫宕機,而導致系統(tǒng)無法正常運行。因為這幾次事故,業(yè)務部門負責人組織這次技術方案評審,主題如何避免再次出現類似這種故障?
當時有個比較資深的技術,他提出當數據庫出現宕機時,可以切換到redis,redis里面緩存熱點數據,另外一個技術說他贊同這個方案,但他提出不需要用到redis,直接用本地緩存即可。因為tomcat是集群部署,就等于本地緩存也具備了集群能力。而如果切換成redis,redis也可能會掛現象。
然后那個說用redis的技術又說,用本地緩存,如果數據變更,其他集群的本地緩存如何感知數據已經發(fā)生變化,他覺得還是用redis靠譜,首先redis容量肯定是比本地緩存高,而且redis也可以部署集群,可用性可以得到保障,利用redis集中存儲,當數據發(fā)生變更,其他集群也可以感知到。
在他們爭論不休的情況下,有人提出不然就同時使用,當數據庫掛了,切換到redis,redis掛了,使用本地緩存。這個方案得到不少人的同意,包括這兩個爭論不休的技術。但使用這種方案,就得考慮多級緩存數據如何同步。
鋪墊了那么多,才剛要說今天的主題,多級緩存數據如何進行同步
多級緩存數據同步
1、方案一:使用MQ或者canal進行同步
方案如下圖

如果是使用MQ來同步,實現方案大致如下,數據發(fā)生變更,業(yè)務系統(tǒng)發(fā)送變更數據到MQ,其他系統(tǒng)從MQ消費。
如果是使用canal,實現方案大致如下,數據發(fā)生變更,canal會接到到變更的binlog,業(yè)務系統(tǒng)編寫canal tcp客戶端,和canal進行交互獲取變更數據
2、方案二:利用redis6提供的客戶端緩存機制
方案如下圖

redis6客戶端緩存實現機制原理,官方有詳細文檔介紹,感興趣大家可以查看如下鏈接
https://redis.io/docs/manual/client-side-caching/
這邊就講下如何使用
如何使用redis6客戶端緩存
前置條件:redis服務端版本必須是>=6。lettuce版本>=6 目前java的redis客戶端找了一圈,貌似只有l(wèi)ettuce 6支持,其他客戶端估計后期會支持
1、項目中pom引入lettuce GAV
<dependency>
<groupId>io.lettuce</groupId>
<artifactId>lettuce-core</artifactId>
<version>6.1.8.RELEASE</version>
</dependency>2、利用lettuce6提供的ClientSideCaching進行實現
/**
* 客戶端緩存同步
*
*/
public String getClientCacheValue(Map<String,String> clientCache,String key){
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().noloop());
return frontend.get(key);
}3、測試
@Override
public void run(ApplicationArguments args) throws Exception {
while(true){
System.out.println(lettuceRedisTemplate.getClientCacheValue("zhangsan"));
TimeUnit.SECONDS.sleep(1);
}
}redis里面的zhangsan數據未發(fā)生變更時,

控制臺輸出的數據為

我們將redis zhangsan的密碼改成9999,

看本地緩存能否立馬捕捉到

控制臺發(fā)現密碼已經改成9999
總結
由示例我們可以看出redis6提供了一個很好的多級緩存同步的實現方案。
我們再聊下那個技術評審的后續(xù),后面業(yè)務部門并沒有采用當mysql宕機,使用redis作為兜底,也沒采用本地緩存,更沒采用兩者結合的方案。
不知道大家開會的時候,有沒有這樣的體會,有時候我們在聊一個東西,后面聊著聊著就發(fā)散出去,把方向搞丟了。業(yè)務部門他們需要數據庫宕機的解決方案嗎,看著像是,其實他們更核心的需要,是業(yè)務系統(tǒng)不宕機。
奧卡姆剃刀定律:如無必要,勿增實體。其實不管加redis或者本地緩存,額外都增加系統(tǒng)維護成本。因為系統(tǒng)本身不復雜,加了緩存,就要額外考慮緩存數據一致性等
后面業(yè)務部門的處理方式,是將自己搭建的mysql,切換成云廠商的mysql。這樣的好處是,云廠商的mysql會更穩(wěn)定,其次當出現問題,可以找云廠商進行解決,畢竟云廠商的運維能力是比較強的,花錢買心安
這次事故會讓業(yè)務部門那么重視,主要是使用方是高管,如果是一般使用者,掛就掛吧,大不了重啟,使用對象不一樣,應急處理方式就不一樣
demo鏈接
https://github.com/lyb-geek/springboot-learning/tree/master/springboot-localcache-redis-sync
到此這篇關于redis實現多級緩存同步的文章就介紹到這了,更多相關redis 多級緩存同步內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!

