前言

前陣子參加業務部門的技術方案評審，故事的背景是這樣：業務部門上線一個專為公司高管使用的系統。這個系統技術架構形如下圖

按理來說這個系統因為受眾很小，可以說基本上沒并發，業務也沒很復雜，但就是這么一個系統，連續2次出現數據庫宕機，而導致系統無法正常運行。因為這幾次事故，業務部門負責人組織這次技術方案評審，主題如何避免再次出現類似這種故障？

當時有個比較資深的技術，他提出當數據庫出現宕機時，可以切換到redis，redis里面緩存熱點數據，另外一個技術說他贊同這個方案，但他提出不需要用到redis，直接用本地緩存即可。因為tomcat是集群部署，就等于本地緩存也具備了集群能力。而如果切換成redis，redis也可能會掛現象。

然后那個說用redis的技術又說，用本地緩存，如果數據變更，其他集群的本地緩存如何感知數據已經發生變化，他覺得還是用redis靠譜，首先redis容量肯定是比本地緩存高，而且redis也可以部署集群，可用性可以得到保障，利用redis集中存儲，當數據發生變更，其他集群也可以感知到。

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

鋪墊了那么多，才剛要說今天的主題，多級緩存數據如何進行同步

多級緩存數據同步

1、方案一：使用MQ或者canal進行同步

方案如下圖

如果是使用MQ來同步，實現方案大致如下，數據發生變更，業務系統發送變更數據到MQ，其他系統從MQ消費。

如果是使用canal，實現方案大致如下，數據發生變更，canal會接到到變更的binlog，業務系統編寫canal tcp客戶端，和canal進行交互獲取變更數據

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

方案如下圖

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

這邊就講下如何使用

如何使用redis6客戶端緩存

前置條件：redis服務端版本必須是>=6。lettuce版本>=6 目前java的redis客戶端找了一圈，貌似只有lettuce 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數據未發生變更時，

控制臺輸出的數據為

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

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

控制臺發現密碼已經改成9999

總結

由示例我們可以看出redis6提供了一個很好的多級緩存同步的實現方案。

我們再聊下那個技術評審的后續，后面業務部門并沒有采用當mysql宕機，使用redis作為兜底，也沒采用本地緩存，更沒采用兩者結合的方案。

不知道大家開會的時候，有沒有這樣的體會，有時候我們在聊一個東西，后面聊著聊著就發散出去，把方向搞丟了。業務部門他們需要數據庫宕機的解決方案嗎，看著像是，其實他們更核心的需要，是業務系統不宕機。

奧卡姆剃刀定律：如無必要，勿增實體。其實不管加redis或者本地緩存，額外都增加系統維護成本。因為系統本身不復雜，加了緩存，就要額外考慮緩存數據一致性等

后面業務部門的處理方式，是將自己搭建的mysql，切換成云廠商的mysql。這樣的好處是，云廠商的mysql會更穩定，其次當出現問題，可以找云廠商進行解決，畢竟云廠商的運維能力是比較強的，花錢買心安

這次事故會讓業務部門那么重視，主要是使用方是高管，如果是一般使用者，掛就掛吧，大不了重啟，使用對象不一樣，應急處理方式就不一樣

demo鏈接

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