多级缓存

传统的缓存策略一般是请求到达Tomcat后，先查询Redis，如果未命中则查询数据库，如图：

存在下面的问题：

•请求要经过Tomcat处理，Tomcat的性能成为整个系统的瓶颈

•Redis缓存失效时，会对数据库产生冲击

多级缓存就是充分利用请求处理的每个环节，分别添加缓存，减轻Tomcat压力，提升服务性能：

• 浏览器访问静态资源时，优先读取浏览器本地缓存
• 访问非静态资源（ajax查询数据）时，访问服务端
• 请求到达Nginx后，优先读取Nginx本地缓存
• 如果Nginx本地缓存未命中，则去直接查询Redis（不经过Tomcat）
• 如果Redis查询未命中，则查询Tomcat
• 请求进入Tomcat后，优先查询JVM进程缓存
• 如果JVM进程缓存未命中，则查询数据库

反正前面一堆缓存，数据库就是个宝宝

JVM进程缓存

OpenResty多级缓存

缓存同步

大多数情况下，浏览器查询到的都是缓存数据，如果缓存数据与数据库数据存在较大差异，可能会产生比较严重的后果。

所以我们必须保证数据库数据、缓存数据的一致性，这就是缓存与数据库的同步。

数据同步策略

缓存数据同步的常见方式有三种：

设置有效期：给缓存设置有效期，到期后自动删除。再次查询时更新

• 优势：简单、方便
• 缺点：时效性差，缓存过期之前可能不一致
• 场景：更新频率较低，时效性要求低的业务

同步双写：在修改数据库的同时，直接修改缓存

• 优势：时效性强，缓存与数据库强一致
• 缺点：有代码侵入，耦合度高；
• 场景：对一致性、时效性要求较高的缓存数据

**异步通知：**修改数据库时发送事件通知，相关服务监听到通知后修改缓存数据

• 优势：低耦合，可以同时通知多个缓存服务
• 缺点：时效性一般，可能存在中间不一致状态
• 场景：时效性要求一般，有多个服务需要同步

而异步实现又可以基于MQ或者Canal来实现：

1）基于MQ的异步通知：

解读：

• 商品服务完成对数据的修改后，只需要发送一条消息到MQ中。
• 缓存服务监听MQ消息，然后完成对缓存的更新

依然有少量的代码侵入。

2）基于Canal的通知

解读：

• 商品服务完成商品修改后，业务直接结束，没有任何代码侵入
• Canal监听MySQL变化，当发现变化后，立即通知缓存服务
• 缓存服务接收到canal通知，更新缓存

代码零侵入