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

技术分享 2个月前 (05-21) 0 999+

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

一、缓存模式

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

Cache Aside

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

Read Through

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

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

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

Write Through

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

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

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

Write Back

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

说明

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

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

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

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

// 装饰者模式代码结构 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缓存模式；并且实现了一个当时认为稍微“展示一点技术”的方案：当缓存未命中时，从数据库加载数据，返回业务层，将写入缓存改为异步写入。

大概代码如下，大家参考：

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");     }  }