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

缓存模式是指用于管理缓存数据的策略和方式。常见的缓存模式包括Cache Aside、Read Through、Write Through、Write Back等。

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

Read Through缓存模式中，缓存与数据库是连接的。当缓存未命中时，会从数据库中加载数据，填充缓存并返回给应用程序。

虽然Read Through和Cache Aside非常相似，但至少有两个关键区别：在Cache Aside中，应用程序负责从数据库获取数据并填充缓存；而在Read Through中，通常由库或独立缓存提供程序来实现这一逻辑。此外，Read Through缓存中的数据模型不能与数据库的数据模型不同。

另一种缓存模式是Write Through，在这种模式下，当应用程序需要更新数据时，会先更新到缓存，同时更新到数据源，这两个操作在同一个事务中完成，保持缓存和数据源之间的数据一致性。

在Write Through模式中，当应用程序想要写入数据或更新值时，会先将数据直接写入缓存，然后更新主数据库中的数据。当写入完成后，缓存和数据库都具有相同的值，保持一致。

另一种缓存模式是Write Back，当写入数据时，只写入缓存。当缓存过期时才会被刷新到数据库。然而，这种模式的最大问题是如果缓存突然宕机，尚未刷新到数据库的数据就会彻底丢失。

严格来说，现在的缓存工作模式都可以归属于旁路缓存。如果在代码中的缓存层进行了封装，那么在业务代码中调用缓存层方法进行操作，可以认为实现了不同的缓存模式。因此，缓存模式的界限并不是那么明显。

在开发中，可以使用代理模式和装饰者模式来优雅地实现缓存层的封装。代理模式主要用于提供一种代理，以控制对对象的访问。而装饰者模式则指在不改变现有对象结构的情况下，动态增加对象的职责。

举例来说，代理模式可以用于控制对象的访问，比如在一个双机房部署的RPC接口提供方和调用方中，通过代理模式实现跨机房调用。而装饰者模式则常用于增加对象的额外功能，例如对不同缓存模式的实现，可以使用装饰者模式。

我之前工作中做过一个RPC读接口性能优化的案例。系统架构简单，是一个常规的Java Web应用，对外提供RPC服务，底层数据采用MySQL，缓存使用Redis。该查询接口涉及多张MySQL表和多个外部RPC接口的查询。

在接口性能优化过程中，对于多张表查询，进行了慢SQL检查并进行索引优化。而对于多外部RPC接口调用，改为并行调用。后续又使用了Redis缓存进行缓存数据。

当时我想展示一些个人技术，因此使用了装饰者模式来实现Read Through缓存模式，并尝试了一种较为高级的方案：当缓存未命中时，从数据库加载数据返回业务层，并将写入缓存改为异步写入。

以上是我在文章中提到的内容，希望可以对大家的学习和工作有所帮助。欢迎大家在评论区或私信中与我交流讨论，也欢迎关注我的博客园、公众号（码上暴富），支持我的工作。

参考资料

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