本文原始碼：GitHub·點這里 || GitEE·點這里

一、快取設計

1、快取的作用

在業務系統中，查詢時最容易出現性能問題的模塊，查詢面對的資料量大，篩選條件復雜，所以在系統架構中引入快取層，則是非常必要的，用來快取熱點資料，達到快速回應的目的，

快取使用的基本原則：

• 所有快取資料，必須設定過期時間；
• 核心業務流程不通過快取層；
• 快取層移除，不影響現有流程；
• 系統各個端首頁資料不實時查詢；
• 報表資料不實時查詢加載；
• 歸檔資料(定時統計的結果資料)不實時查詢；

這里是業務架構中常用的快取策略，快取通過犧牲強一致性來提高性能，所以并不是所有的業務都適合用快取，實際考量都會針對具體的業務，比如用戶相關維度的資料修改頻率低，會使用快取，但是用戶權限資料(比如：免費次數)會考慮實時校驗，快取層使用的相對較少，

2、快取設計模式

Cache-Aside模式

業務中最常用的快取層設計模式，基本實作邏輯和相關概念如下：

• 快取命中：直接查詢快取且命中，回傳資料；
• 快取加載：查詢快取未命中，從資料庫中查詢資料，獲取資料后并加載到快取；
• 快取失效：資料更新寫到資料庫，操作成功后，讓快取失效，查詢時候再重新加載；
• 快取穿透：查詢資料庫不存在的物件，也就不存在快取層的命中；
• 快取擊穿：熱點key在失效的瞬間，高并發查詢這個key，擊穿快取，直接請求資料庫；
• 快取雪崩：快取Key大批量到過期時間，導致資料庫壓力過大；
• 命中率：快取設計的是否合理要看命中率，命中率高說明快取有效抗住了大部分請求，命中率可以通過Redis監控資訊計算，一般來說命中率在(70-80)%都算合理，
  并發問題

執行讀操作未命中快取，然后查詢資料庫中取資料，資料已經查詢到還沒放入快取，同時一個更新寫操作讓快取失效，然后讀操作再把查詢到資料加載快取，導致快取的臟資料，

在遵守快取使用原則下出現該情況概率非常低，可以通過復雜的Paxos協議保證一致性，一般情況是不考量該場景的處理，如果快取管理過于復雜，會和快取層核心理念相悖，

基本描述代碼：

@Service
public class KeyValueServiceImpl extends ServiceImpl<KeyValueMapper, KeyValueEntity> implements KeyValueService {

    @Resource
    private RedisService redisService ;

    @Override
    public KeyValueEntity select(Integer id) {
        // 查詢快取
        String redisKey = RedisKeyUtil.getObectKey(id) ;
        String value = https://www.cnblogs.com/cicada-smile/p/redisService.get(redisKey) ;
        if (!StringUtils.isEmpty(value) && !value.equals("null")){
            return JSON.parseObject(value,KeyValueEntity.class);
        }
        // 查詢庫
        KeyValueEntity keyValueEntity = this.getById(id) ;
        if (keyValueEntity != null){
            // 快取寫入
            redisService.set(redisKey,JSON.toJSONString(keyValueEntity)) ;
        }
        // 回傳值
        return keyValueEntity ;
    }

    @Override
    public boolean update(KeyValueEntity keyValueEntity) {
        // 更新資料
        boolean updateFlag = this.updateById(keyValueEntity) ;
        // 清除快取
        if (updateFlag){
            redisService.delete(RedisKeyUtil.getObectKey(keyValueEntity.getId()));
        }
        return updateFlag ;
    }
}

Read-Throug模式

當應用系統向快取系統請求資料時，如果快取中并沒有對應的資料存在，快取系統將向底層資料源的讀取資料，如果資料在快取中存在，則直接回傳快取中存在的資料，把更新資料庫的操作由快取層代勞了，

Write-Through模式

更新寫資料時，如果沒有命中快取，則直接更新資料庫，如果命中了快取，則先更新快取，然后由快取系統自行更新資料庫，

Write-Behind模式

應用系統對快取中的資料進行更新時，只更新快取，不更新資料庫，快取系統會異步批量向底層資料源更新資料，

二、資料一致問題

業務開發模式中，會涉及到一個問題：如何最大限度保證資料庫和Redis快取的資料一致性？

首先說明一下：資料庫和快取強一致性同步成本太高，如果追求強一致，快取層存在的價值就會很低，如上快取模式一中幾乎可以解決大部分業務場景問題，

解決這個問題的方式很多：

方案一說明：

• 資料庫更新寫入資料成功；
• 準備一個先進先出模式的訊息佇列；
• 把更新的資料包裝為一個訊息放入佇列；
• 基于訊息消費服務更新Redis快取；

分析：訊息佇列的穩定和可靠性，操作層面資料庫和快取層解耦，

方案二說明：

• 提供一個資料庫Binlog訂閱服務，并決議修改日志；
• 服務獲取修改資料，并向Redis服務發送訊息；
• Redis資料進行修改，類似MySQL的主從同步機制；

分析：系統架構層面多出一個服務，且需要決議MySQL日志，操作難度較大，但流程上更為合理，

總結描述

分布式架構中，快取層面的基本需求就是提高回應速度，不斷優化，追求資料庫和Redis快取的資料快速一致性，從提供的各種方案中都可以看出，這也在增加快取層面處理的復雜性，架構邏輯復雜，就容易導致程式錯誤，所以針對業務選擇合理的處理邏輯，這點很關鍵，

三、快取監控

1、Redis服務監控

通過info命令查看Redis服務的引數資訊，可以通過傳參查看指定分類配置，通過config..set設定具體配置引數，例如：

@Override
public Properties info(String var) {
    if (StringUtils.isEmpty(var)){
        return redisTemplate.getRequiredConnectionFactory().getConnection().info();
    }
    return redisTemplate.getRequiredConnectionFactory().getConnection().info(var);
}

傳參說明：

• memory：記憶體消耗相關資訊
• server：有關Redis服務器的常規資訊
• clients：客戶端連接部分
• stats：一般統計
• cpu：CPU消耗統計資訊

應用案例:

@RestController
public class MonitorController {

    @Resource
    private RedisService redisService ;

    private static final String[] monitorParam = new String[]{"memory","server","clients","stats","cpu"} ;

    @GetMapping("/monitor")
    public List<MonitorEntity> monitor (){
        List<MonitorEntity> monitorEntityList = new ArrayList<>() ;
        for (String param:monitorParam){
            Properties properties = redisService.info(param) ;
            MonitorEntity monitorEntity = new MonitorEntity () ;
            monitorEntity.setMonitorParam(param);
            monitorEntity.setProperties(properties);
            monitorEntityList.add(monitorEntity);
        }
        return monitorEntityList ;
    }

}

通過上述引陣列合，把Redis相關配置引數列印出來，然后可視化輸出，儼然一副高端的感覺，

配置引數說明：

這里只對兩個引數說明一下，計算命中率的關鍵資訊：

• keyspace_misses：查找快取Key失敗的次數；
• keyspace_hits：查找快取Key命中的次數；

公式：命中率=命中次數/（hits+misses）查找總次數，

2、LRU演算法說明

Redis的資料是放在記憶體中的，所以速度快，自然也就受到記憶體大小的限制，如果記憶體使用超過配置，Redis有不同的回收處理策略，

記憶體模塊引數：maxmemory_policy

• noenviction：不回收資料，查詢直接回傳錯誤，但可以執行洗掉；
• allkeys-lru：從所有的資料中挑選最近最少使用的資料淘汰；
• volatile-lru：已設定過期時間的資料中挑選最近最少使用的資料淘汰；
• allkeys-random：從所有資料中任意選擇資料淘汰；
• volatile-random：從已設定過期時間的資料中任意選擇資料淘汰；
• volatile-ttl：從已設定過期時間的資料中挑選將要過期的資料淘汰；

大部分情況下，業務都是希望最熱點資料可以被快取，所以相對使用allkeys-lru策略偏多，這里要根據業務模式特點衡量，

四、源代碼地址

GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent

推薦閱讀：《架構設計系列》，蘿卜青菜，各有所需

標籤：Java

上一篇：SpringBoot2.3整合RabbitMQ實作延遲消費訊息

下一篇：MapperReduce序列化作業(二)——排序