性能为王：微服务架构中的多级缓存设计

微服务架构中的多级缓存设计

提到缓存，想必每一位软件工程师都不陌生，它是目前架构设计中提高性能最直接的方式。这里举个例子：

X 缓存多级缓存架构纵览

这张图从上到下包含四层，分别为：客户端、应用层、服务层以及数据层。

客户端缓存

X 商城客户端为浏览器，在浏览器层面我们主要是对 HTML 中的图片、CSS、JS、字体这些静态资源进行缓存。

CDN 内容分发 络

中国幅员辽阔，从北京到上海就有上千公里，如果大量的上海用户同时要访问千里之外的北京服务器的资源，这么长的通信必然带来高延迟与更多不可控因素影响数据传输，如果有某种机制允许将北京的静态文件缓存到上海的服务器，上海用户自动就近访问服务器获取资源，这样便可很大程度降低 络延迟，进而提高系统的可用性。而刚才提到的分布式缓存技术就是我们常提到的CDN（内容分发 络）。

对于广域的互联 应用，CDN 几乎是必需的基础设施，它有效解决了带宽集中占用以及数据分发的问题。像 Web 页面中的图片、音视频、CSS、JS 这些静态资源，都可以通过 CDN 服务器就近获取。

CDN 技术的核心是“智能 DNS”，智能 DNS 会根据用户的 IP 地址自动确定就近访问 CDN 节点，以下图为例：

阿里云自定义响应头

Nginx 缓存管理

Nginx 是一款开源的、跨平台的高性能 Web 服务器，它有着高性能，稳定性好，配置简单，模块结构化，资源消耗低的优点。同时支持反向代理、负载均衡、缓存的功能。Nginx 是 Web 应用架构中的常客，例如后端 Tomcat 集群便可通过增加 Nginx 前置做软负载均衡，为应用提供高可用特性。

Nginx 本地缓存

服务层缓存

在前面无论是 CDN 还是 Nginx，都是对 Web 应用中的静态资源文件进行缓存。但后端应用与服务更多的是访问接口与数据，对于这些对象我们如何利用缓存技术进行性能优化呢于后端应用与服务的缓存可以按部署方式分为进程内缓存与分布式缓存服务。

进程内缓存

所谓进程内缓存，就是在应用中开辟的一块内存空间，数据在运行时被载入这块内存，通过本地内存的低延迟、高吞吐的特性提高程序的访问速度。进程内缓存在众多 Java 框架内都有广泛应用，例如 Hibernate、Mybatis 框架的一二级缓存、Spring MVC 的页面缓存都是进程内缓存的经典应用场景，这些进程内缓存在 Java 中也有着非常多优秀的开源实现，如 EhCache、Caffeine 都是代表性产品。

分布式缓存服务

与进程内相对的，就是需要独立部署的分布式缓存服务。最常用的是基于 Redis 这种内存型 NoSQL 数据库，对整体架构中的应用数据进行集中缓存。

Redis 缓存服务集群

因此在 Java 的应用端也要设计多级缓存，将进程内缓存与分布式缓存服务结合，有效分摊应用压力。在 Java 应用层面，只有 EhCache 的缓存不存在时，再去 Redis 分布式缓存获取，如果 Redis 也没有此数据再去数据库查询，数据查询成功后对 Redis 与 EhCahce 同时进行双写更新。这样 Java 应用下一次再查询相同数据时便直接从本地 EhCache 缓存提取，不再产生新的 络通信，应用查询性能得到显著提高。

缓存一致性问题

都知道作为数据库写操作，是不通过缓存的。假设商品服务实例 1 将 1 商品价格调整为 80 元，这会衍生一个新问题：如何主动向应用程序推送数据变更的消息来保证它们也能同步更新缓存呢/p>

相信此时你已经有了答案。没错，需要在当前架构中引入 MQ 消息队列，利用 RocketMQ 的主动推送功能来向其他服务实例以及 Redis 缓存服务发起变更通知。

通过 RocketMQ 解决保证消息一致性

如上图所示，在商品服务实例 1 对商品调价后，主动向 RocketMQ Broker 发送变更消息，Broker 将变更信息推送至其他实例与 Redis 集群，这些服务实例在收到变更消息后，在缓存中先删除过期缓存，再创建新的数据，以此保证各实例数据一致。

对于缓存来说，并没有终极的解决方案。虽然多级缓存设计带来了更好的应用性能，但也为了缓存一致性必须引入 MQ 增加了架构的复杂度。那到底多级缓存设计该如何取舍呢三种情况特别适合引入多级缓存。

第一种情况，缓存的数据是稳定的。例如邮政编码、地域区块、归档的历史数据这些信息适合通过多级缓存减小 Redis 与数据库的压力。

第二种情况，瞬时可能会产生极高并发的场景。例如春运购票、双 11 零点秒杀、股市开盘交易等，瞬间的流量洪峰可能击穿 Redis 缓存，产生流量雪崩。这时利用预热的进程内缓存分摊流量，减少后端压力是非常有必要的。

第三种情况，一定程度上允许数据不一致。例如某博客平台中你修改了自我介绍这样的非关键信息，此时在应用集群中其他节点缓存不一致也并不会带来严重影响，对于这种情况我们采用T+1的方式在日终处理时保证缓存最终一致就可以了。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树使用JDBC操作数据库数据库操作91318 人正在系统学习中