当装饰者模式遇上Read Through缓存,一场技术的浪漫邂逅

在**《经验之谈:我为什么选择了这样一个激进的缓存大Key治理方案》** 一文中,我提到在系统中使用的缓存是旁路缓存模式,有读者朋友问,有没有用到过其他的缓存模式,本文将结合一个我曾经工作中的案例,使用装饰者模式实现Read Through缓存模式,助你轻松掌握设计模式和缓存。

一、缓存模式

不说废话,直入主题。缓存模式是指用于管理缓存数据的策略和方式。常见的有这几种:Cache Aside、Read Through、Write Through、Write Back等

Cache Aside

在平时的开发工作中,旁路缓存是最常用的一种缓存模式,"旁路"二字意味着读取缓存、读取数据、更新缓存和操作都是在应用程序中完成的,缓存和数据库之间是没有连接的

Read Through

在这种模式下,缓存与数据库是连接起来的。当缓存未命中的时候,缓存中数据库中加载数据,填充缓存并返回给应用程序。

虽然Read Through和Cache Aside非常相似,但至少有两个关键区别:

  1. 在Cache Aside中,应用程序负责从数据库获取数据并填充缓存。在Read Through中,此逻辑通常由库或独立缓存提供程序来实现。
  2. 与Cache Aside不同,Read Through缓存中的数据模型不能与数据库的数据模型不同。

Write Through

在穿透写入模式下,当应用程序需要更新数据时,它会先更新到缓存,同时更新到数据源,这两个操作在共一个事务中完成。因此只有2个都写成功了才会最终写成功,有助于保持缓存和数据源之间的数据一致性。

当应用程序想要写入数据或更新值时,会发生以下情况:

  1. 应用程序将数据直接写入缓存。
  2. 缓存更新主数据库中的数据。当写入完成后,缓存和数据库都具有相同的值,并且缓存始终保持一致。

Write Back

在这个模式下,当写入数据的时候,只是写到了缓存。当缓存过期的时候,才会被刷新到数据库。这个模式最大的一个问题就是如果缓存突然宕机,那么还没有刷新到数据库的数据就彻底丢失了。

说明

我认为严格来说,现在的缓存工作模式都归属于旁路缓存。如果在代码中的缓存层(类似于Mapper层)进行了封装的话;那么在业务代码中调用缓存层方法进行操作,这里屏蔽了缓存的实现细节,站在业务代码层面来看,可以暂且认为是实现了不同的缓存模式吧。

二、代理模式和装饰者模式

那如何优雅实现上述缓存层的封装,在开发中可以丝滑接入呢?接着看,这里需要使用一些设计模式。

这是代理模式、装饰者模式的代码结构示例:二者结构完全一致。

java 复制代码
// 装饰者模式代码结构
public interface AInterface {
    void run();
}

public class A implements AInterface {
    @Override
    public void run() {
         // run
        System.out.println("A run...");
    }
}

public class ADercorator implements AInterface {

    private AInterface a;

    public ADercorator(AInterface a) {
        this.a = a;
    }

    @Override
    public void run() {
        // doSomething
        System.out.println("ADerocator do something...");
        a.run();
        // doSomething
    }
}

当然代理模式和装饰者模式还是有区别的,主要是看应用的场景。

代理模式主要是为其他对象提供一种代理,以控制对这个对象的访问

例如有一个案例这样的,一个RPC接口的提供方和调用方都是双机房部署的,原本的远程调用也是机房垂直调用(机房A只调用机房A,机房B只调用机房B)的;由于接口提供方接口性能原因,希望调用方改为跨机房调用(机房A同时调用机房A和机房B,机房B同时调用机房A和机房B)。我的实现方式是使用代理模式,在代码中新增一个接口调用的代理层,在代理层中注入机房A和机房B的RPC Consumer配置,根据时间戳的奇偶来判断调用哪个机房,从而实现跨机房调用。

而装饰者模式则指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)的模式 。在《Head First 设计模式》一书中,更是将装饰者模式称为"给爱用继承的人一个全新的设计眼界"。例如对于不同缓存模式的实现,可以使用装饰者模式。

三、装饰者模式实现Read Through缓存模式

这是我之前做过的一个RPC读接口性能优化的案例。系统架构比较简单,就是一个常规的Java Web应用,对外提供RPC服务,底层数据采用的是MySQL,缓存使用的是Redis。

该查询接口涉及数据库多张MySQL表和多个外部RPC接口的查询

在接口性能优化过程中,

对于多张表查询,检查慢SQL并进行了索引优化;

对于多外部RPC接口调用改为并行调用;

后续又使用了Redis缓存进行缓存数据。

当时刚进入职场不久,作为一个职场新人,年轻气盛,还想着彰显一下个人的技术,所以我打算使用装饰者模式来实现Read Through缓存模式 ;并且实现了一个当时认为稍微"展示一点技术 "的方案:当缓存未命中时,从数据库加载数据,返回业务层,将写入缓存改为异步写入

大概代码如下,大家参考:

java 复制代码
public interface CacheInterface {
    String get(String key);
    String set(String key, String value);
}

public class Cache implements CacheInterface {

    private Jedis jedis;

    @Override
    public String get(String key) {
         // run
        System.out.println("Cache get...");
        return jedis.get(key);
    }

    @Override
    public String set(String key, String value) {
        return jedis.set(key, value);
    }
}

public class CacheDecorator implements CacheInterface {

    private Repository myRepositoty = new MyRepository();

    private CacheInterface cache;

    public CacheDecorator(CacheInterface a) {
        this.cache = cache;
    }

    @Override
    public String get(String key) {
        // doSomething
        System.out.println("CacheDecorator do something...");
        String cacheResult = cache.get(key);
        if (!StringUtils.isEmpty(cacheResult)) {
            return cacheResult;
        }
        String result = myRepositoty.get(key);
        CompletableFuture.runAsync(() -> cache.set(key, result));
        return result;
    }

    @Override
    public String set(String key, String value) {
        return cache.set(key, value);
    }
}

public class Test {

    public static void main(String[] args) {
        Cache cache = new Cache();
        CacheDecorator derocator = new CacheDecorator(cache);
        derocator.get("a");
    }

}  

一起学习

欢迎各位在评论区或者私信我一起交流讨论,或者加我主页weixin,备注技术渠道(如博客园),进入技术交流群,我们一起讨论和交流,共同进步!

也欢迎大家关注我的博客园、公众号(码上暴富) ,点赞、留言、转发。你的支持,是我更文的最大动力!

参考资料

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/