面试官：如何保证缓存和数据库的一致性？

你好呀，我是苍何！

办公室里鸦雀无声，我木然的看着窗外射进来的阳光，它照在光滑的地板上，又反射到天花板上，再从天花板上反射下来时，就变成一片弥散的白光。

我在白光里偷偷放了一个恶毒的臭屁，如果是以前，同事们会偷偷捂住鼻子，然后目光看向旁边的人，没有人看向我，我也捂住鼻子，附和的来了句"谁又放毒了？"。

其实我却在心里偷偷笑，反正谁也猜不到是我。

如今办公室除了我再无一人，我还要在自己的臭屁下写文章，可能因此我的文章多少有些被「污染」。

但我依旧希望我的文章不是屁，最起码不能是臭屁。

那接下来，苍何给大家分享一个大厂面试常见问题：

如何保证缓存和数据库的一致性？，也即是既要又要怎么做？

缓存的重要性

缓存大家都并不陌生，说白了就是一种存储机制，用于暂时保存数据，以加速数据的读取和访问。

数据库好好的为什么要用缓存？关键点在于缓存快啊！

比如微信中的很大消息都是缓存在你本地手机的，（看到有自媒体博主发视频说能找回你 10 年前的微信聊天记录，大哥，前提是你 10 年不换手机？或者每次换手机你都能把所有聊天记录导出来？）

微信手机中的缓存是一种常见的本地缓存，对于开发来说本地缓存常用有以下这些：

JDK 自带的 HashMap 和 ConcurrentHashMap
Ehcache、Guava Cache、Spring Cache、Caffeine 等常见的本地缓存框架

除了本地缓存，还有常见的分布式缓存如常用的 Redis。本地缓存和分布式缓存很好区别，本地缓存和应用在同一个地方，而分布式缓存是可以独立部署在不同的服务器上的，比如 Redis 可以单机或者集群部署在不同的服务器上。

不管是本地缓存还是分布式缓存，都只有一个目的，那就是用空间换时间，用更多的存储空间来存储一些可能重复使用或计算的数据，从而减少数据的重新获取或计算的时间。

缓存介绍.png

缓存一致性问题

你有没有想过一个问题，既然一份数据同时在缓存中和数据库中都有，那这两者到底哪个是最新数据呢？如何保证其数据一致性呢？

那么导致不一致的原因主要有：

缓存过期：缓存中的数据有一个生命周期，当数据过期后，如果没有及时更新，就会出现不一致的情况。
写操作延迟：在执行写操作时，数据库更新和缓存更新的时间不同步，可能会导致缓存中的数据不一致。
并发操作：多个并发操作同时进行，可能会导致数据更新时出现竞态条件，从而导致缓存和数据库数据不一致。
缓存失效策略不当：使用不当的缓存失效策略，可能导致缓存中的数据无法及时更新，导致不一致。
网络延迟或故障：由于网络延迟或故障，缓存服务器和数据库之间的通信出现问题，导致数据不一致。

常见的解决不一致问题有如下解决方案：

Cache Aside 模式：在读写操作中使用 Cache Aside 模式，确保在写操作后及时失效缓存中的数据。
分布式锁：在并发写操作时使用分布式锁，确保同时只有一个操作能够更新缓存和数据库，避免竞态条件。
双写一致性：在写操作时同时更新数据库和缓存，确保数据的一致性。
延迟双删：在写操作时，先删除缓存中的数据，更新数据库后，再次删除缓存中的数据，确保缓存中数据的一致性。
版本控制：在缓存和数据库中使用版本号或时间戳，确保数据更新时的一致性检查。
监控和告警：对缓存和数据库中的数据进行监控，发现不一致时及时告警并处理。

而 PmHub 中主要围绕 Cache Aside 模式、分布式锁、监控和告警来解决一致性问题，之前章节有介绍分布式锁以及监控告警相关的能力，本节主要针对的 Cache Aside 模式。

常见缓存更新策略

先直接看苍何给做的汇总表吧：


模式名称	描述	优点	缺点	使用场景
Cache Aside Pattern (旁路缓存模式)	读取数据时先检查缓存，缓存未命中则从数据库读取并更新缓存。写入数据时先更新数据库，然后使缓存失效。	- 读取性能高 - 实现简单	- 首次请求数据一定不在缓存问题 - 写操作较频繁的话会导致缓存中数据被频繁删除，会影响缓存命中率	- 数据读取频率高，写入频率较低的场景
Read/Write Through Pattern (读写穿透模式)	所有的读写操作都通过缓存进行，缓存负责同步数据库。	- 数据一致性好 - 实现了读写操作的统一	- 实现复杂 - 依赖缓存的高可用性	- 数据读取和写入频率均较高的场景
Write Behind Pattern (异步缓存写入)	写操作首先更新缓存，然后异步地将数据写入数据库。	- 写操作性能高 - 减少数据库压力	- 存在数据丢失的风险 - 数据一致性较差	- 写操作频繁，且对实时一致性要求不高的场景

Cache Aside 模式概述

数据不一致的主要原因还是先写缓存还是先更新数据库的问题，不正确的方案我们就不阐述了，省的增加同学们的负担。那么 PmHub 采用的就是 Cache Aside 模式来保证缓存和数据库的一致性。

Cache Aside 模式其实就是读取数据时先检查缓存，缓存未命中则从数据库读取并更新缓存。写入数据时先更新数据库，然后使缓存失效。用一张图或许你更好理解一些：

Cache Aside时序图.png

Cache Aside 模式优点和局限

优点

读取性能高：
- 缓存命中时可以直接从缓存中读取数据，速度非常快，显著减少了数据库的访问压力。
实现简单：
- 该模式逻辑清晰，容易理解和实现，只需在读取和写入操作时分别处理缓存和数据库即可。使用的也比较多的一种方案了。
灵活性强：
- 程序员可以根据需要灵活地控制缓存的更新和失效策略，适应不同的应用场景和需求。
缓存利用率高：
- 只有在缓存未命中时才从数据库读取数据并更新缓存，避免了不必要的数据冗余。

局限

写操作较慢：
- 每次写操作都需要更新数据库并使缓存失效，这样的操作过程较长，导致写操作性能较低。
数据一致性挑战：
- 缓存和数据库之间可能会出现数据不一致的情况，特别是在高并发环境下，更容易出现缓存失效不及时或者更新顺序问题。
缓存预热问题：
- 初始时缓存为空，第一次读取时会有较大的延迟，直到缓存被逐渐填充起来。所以热点数据建议直接放入缓存
复杂的失效策略：
- 程序员需要设计合理的缓存失效策略，以确保缓存的数据及时更新，这增加了实现和维护的复杂性。具体怎么设置失效策略又体现了经验了。
过期数据风险：
- 如果没有合适的失效机制，缓存中可能会存在过期数据，从而返回错误或过时的信息给用户。

Cache Aside 模式在读取性能和实现简单性上有显著的优点，但在写操作性能和数据一致性上面临挑战。在使用这种模式时，需要根据具体应用场景设计合理的缓存更新和失效策略，以最大化其优点并最小化其局限。

对于 PmHub 业务来说，Cache Aside 模式就是最大化利用其优点以及最小化利用其局限性的实践。

PmHub 最佳实践

数据读取

原理很简单，就是先查询缓存，如果有就直接返回，没有就去数据库查询，然后再写入缓存。

这个在 PmHub 中很多地方的代码都有使用，随便举个例子吧：

/**
 * 根据键名查询参数配置信息
 *
 * @param configKey 参数key
 * @return 参数键值
 */
@Override
public String selectConfigByKey(String configKey) {
    String configValue = Convert.toStr(redisService.getCacheObject(getCacheKey(configKey)));
    if (StringUtils.isNotEmpty(configValue)) {
        return configValue;
    }
    SysConfig config = new SysConfig();
    config.setConfigKey(configKey);
    SysConfig retConfig = configMapper.selectConfig(config);
    if (StringUtils.isNotNull(retConfig)) {
        redisService.setCacheObject(getCacheKey(configKey), retConfig.getConfigValue());
        return retConfig.getConfigValue();
    }
    return StringUtils.EMPTY;
}

数据更新

更新数据的时候，先去更新数据库信息，然后再删除缓存，这个在 PmHub 中很多地方都有使用，比如在批量删除参数信息的场景下，先删除数据库信息，然后再删除缓存信息，代码如下：


/**
 * 批量删除参数信息
 *
 * @param configIds 需要删除的参数ID
 */
@Override
public void deleteConfigByIds(Long[] configIds) {
    for (Long configId : configIds) {
        SysConfig config = selectConfigById(configId);
        if (StringUtils.equals(UserConstants.YES, config.getConfigType())) {
            throw new ServiceException(String.format("内置参数【%1$s】不能删除 ", config.getConfigKey()));
        }
        configMapper.deleteConfigById(configId);
        redisService.deleteObject(getCacheKey(config.getConfigKey()));
    }
}