当装饰者模式遇上Read Through缓存，一场技术的浪漫邂逅
在《经验之谈：我为什么选择了这样一个激进的缓存大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");
}
}
一起学习
欢迎各位在评论区或者私信我一起交流讨论，或者加我主页weixin，备注技术渠道（如博客园），进入技术交流群，我们一起讨论和交流，共同进步！
也欢迎大家关注我的博客园、公众号（码上暴富），点赞、留言、转发。你的支持，是我更文的最大动力！
参考资料
https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
