前言

前陣子參加業(yè)務(wù)部門(mén)的技術(shù)方案評(píng)審，故事的背景是這樣：業(yè)務(wù)部門(mén)上線一個(gè)專(zhuān)為公司高管使用的系統(tǒng)。這個(gè)系統(tǒng)技術(shù)架構(gòu)形如下圖

按理來(lái)說(shuō)這個(gè)系統(tǒng)因?yàn)槭鼙姾苄?，可以說(shuō)基本上沒(méi)并發(fā)，業(yè)務(wù)也沒(méi)很復(fù)雜，但就是這么一個(gè)系統(tǒng)，連續(xù)2次出現(xiàn)數(shù)據(jù)庫(kù)宕機(jī)，而導(dǎo)致系統(tǒng)無(wú)法正常運(yùn)行。因?yàn)檫@幾次事故，業(yè)務(wù)部門(mén)負(fù)責(zé)人組織這次技術(shù)方案評(píng)審，主題如何避免再次出現(xiàn)類(lèi)似這種故障？

當(dāng)時(shí)有個(gè)比較資深的技術(shù)，他提出當(dāng)數(shù)據(jù)庫(kù)出現(xiàn)宕機(jī)時(shí)，可以切換到redis，redis里面緩存熱點(diǎn)數(shù)據(jù)，另外一個(gè)技術(shù)說(shuō)他贊同這個(gè)方案，但他提出不需要用到redis，直接用本地緩存即可。因?yàn)閠omcat是集群部署，就等于本地緩存也具備了集群能力。而如果切換成redis，redis也可能會(huì)掛現(xiàn)象。

然后那個(gè)說(shuō)用redis的技術(shù)又說(shuō)，用本地緩存，如果數(shù)據(jù)變更，其他集群的本地緩存如何感知數(shù)據(jù)已經(jīng)發(fā)生變化，他覺(jué)得還是用redis靠譜，首先redis容量肯定是比本地緩存高，而且redis也可以部署集群，可用性可以得到保障，利用redis集中存儲(chǔ)，當(dāng)數(shù)據(jù)發(fā)生變更，其他集群也可以感知到。

在他們爭(zhēng)論不休的情況下，有人提出不然就同時(shí)使用，當(dāng)數(shù)據(jù)庫(kù)掛了，切換到redis，redis掛了，使用本地緩存。這個(gè)方案得到不少人的同意，包括這兩個(gè)爭(zhēng)論不休的技術(shù)。但使用這種方案，就得考慮多級(jí)緩存數(shù)據(jù)如何同步。

鋪墊了那么多，才剛要說(shuō)今天的主題，多級(jí)緩存數(shù)據(jù)如何進(jìn)行同步

多級(jí)緩存數(shù)據(jù)同步

1、方案一：使用MQ或者canal進(jìn)行同步

方案如下圖

如果是使用MQ來(lái)同步，實(shí)現(xiàn)方案大致如下，數(shù)據(jù)發(fā)生變更，業(yè)務(wù)系統(tǒng)發(fā)送變更數(shù)據(jù)到MQ，其他系統(tǒng)從MQ消費(fèi)。

如果是使用canal，實(shí)現(xiàn)方案大致如下，數(shù)據(jù)發(fā)生變更，canal會(huì)接到到變更的binlog，業(yè)務(wù)系統(tǒng)編寫(xiě)canal tcp客戶端，和canal進(jìn)行交互獲取變更數(shù)據(jù)

2、方案二：利用redis6提供的客戶端緩存機(jī)制

方案如下圖

redis6客戶端緩存實(shí)現(xiàn)機(jī)制原理，官方有詳細(xì)文檔介紹，感興趣大家可以查看如下鏈接
https://redis.io/docs/manual/client-side-caching/

這邊就講下如何使用

如何使用redis6客戶端緩存

前置條件：redis服務(wù)端版本必須是>=6。lettuce版本>=6 目前java的redis客戶端找了一圈，貌似只有l(wèi)ettuce 6支持，其他客戶端估計(jì)后期會(huì)支持

1、項(xiàng)目中pom引入lettuce GAV

  <dependency>
            <groupId>io.lettuce</groupId>
            <artifactId>lettuce-core</artifactId>
            <version>6.1.8.RELEASE</version>
        </dependency>

2、利用lettuce6提供的ClientSideCaching進(jìn)行實(shí)現(xiàn)

    /**
     * 客戶端緩存同步
     *
     */
    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、測(cè)試

    @Override
    public void run(ApplicationArguments args) throws Exception {
        while(true){
            System.out.println(lettuceRedisTemplate.getClientCacheValue("zhangsan"));
            TimeUnit.SECONDS.sleep(1);
        }


    }

redis里面的zhangsan數(shù)據(jù)未發(fā)生變更時(shí)，

控制臺(tái)輸出的數(shù)據(jù)為

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

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

控制臺(tái)發(fā)現(xiàn)密碼已經(jīng)改成9999

總結(jié)

由示例我們可以看出redis6提供了一個(gè)很好的多級(jí)緩存同步的實(shí)現(xiàn)方案。

我們?cè)倭南履莻€(gè)技術(shù)評(píng)審的后續(xù)，后面業(yè)務(wù)部門(mén)并沒(méi)有采用當(dāng)mysql宕機(jī)，使用redis作為兜底，也沒(méi)采用本地緩存，更沒(méi)采用兩者結(jié)合的方案。

不知道大家開(kāi)會(huì)的時(shí)候，有沒(méi)有這樣的體會(huì)，有時(shí)候我們?cè)诹囊粋€(gè)東西，后面聊著聊著就發(fā)散出去，把方向搞丟了。業(yè)務(wù)部門(mén)他們需要數(shù)據(jù)庫(kù)宕機(jī)的解決方案嗎，看著像是，其實(shí)他們更核心的需要，是業(yè)務(wù)系統(tǒng)不宕機(jī)。

奧卡姆剃刀定律：如無(wú)必要，勿增實(shí)體。其實(shí)不管加redis或者本地緩存，額外都增加系統(tǒng)維護(hù)成本。因?yàn)橄到y(tǒng)本身不復(fù)雜，加了緩存，就要額外考慮緩存數(shù)據(jù)一致性等

后面業(yè)務(wù)部門(mén)的處理方式，是將自己搭建的mysql，切換成云廠商的mysql。這樣的好處是，云廠商的mysql會(huì)更穩(wěn)定，其次當(dāng)出現(xiàn)問(wèn)題，可以找云廠商進(jìn)行解決，畢竟云廠商的運(yùn)維能力是比較強(qiáng)的，花錢(qián)買(mǎi)心安

這次事故會(huì)讓業(yè)務(wù)部門(mén)那么重視，主要是使用方是高管，如果是一般使用者，掛就掛吧，大不了重啟，使用對(duì)象不一樣，應(yīng)急處理方式就不一樣

demo鏈接

https://github.com/lyb-geek/springboot-learning/tree/master/springboot-localcache-redis-sync

到此這篇關(guān)于redis實(shí)現(xiàn)多級(jí)緩存同步的文章就介紹到這了,更多相關(guān)redis 多級(jí)緩存同步內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論