面试官：缓存与数据库一致性如何解决？先操作数据库，还是缓存？

本篇文章主要内容

• 数据缓存
  • 为何要使用缓存
  • 哪类数据适合缓存
  • 缓存的利与弊
• 如何保证缓存和数据库一致性
  • 不更新缓存，而是删除缓存
  • 先操作缓存，还是先操作数据库
  • 非要保证数据库和缓存数据强一致该怎么办
• 缓存和数据库一致性实战
  • 实战：先删除缓存，再更新数据库
  • 实战：先更新数据库，再删缓存
  • 实战：缓存延时双删
  • 实战：删除缓存重试机制
  • 实战：读取binlog异步删除缓存

数据缓存

在我们实际的业务场景中，一定有很多需要做数据缓存的场景，比如售卖商品的页面，包括了许多并发访问量很大的数据，它们可以称作是是“热点”数据，这些数据有一个特点，就是更新频率低，读取频率高，这些数据应该尽量被缓存，从而减少请求打到数据库上的机会，减轻数据库的压力。

为何要使用缓存

缓存是为了追求“快”而存在的。我们用代码举一个例子。

我在自己的Demo代码仓库中增加了两个查询库存的接口getStockByDB和getStockByCache，分别表示从数据库和缓存查询某商品的库存量。

随后我们用JMeter进行并发请求测试。（JMeter的使用请参考我之前写的文章：点击这里）

需要声明的是，我的测试并不严谨，只是作对比测试，不要作为实际服务性能的参考。

这是两个接口的代码：

/**
 * 查询库存：通过数据库查询库存
 * @param sid
 * @return
 */
@RequestMapping("/getStockByDB/{sid}")
@ResponseBody
public String getStockByDB(@PathVariable int sid) {
    int count;
    try {
        count = stockService.getStockCountByDB(sid);
    } catch (Exception e) {
        LOGGER.error("查询库存失败：[{}]", e.getMessage());
        return "查询库存失败";
    }
    LOGGER.info("商品Id: [{}] 剩余库存为: [{}]", sid, count);
    return String.format("商品Id: %d 剩余库存为：%d", sid, count);
}

/**
 * 查询库存：通过缓存查询库存
 * 缓存命中：返回库存
 * 缓存未命中：查询数据库写入缓存并返回
 * @param sid
 * @return
 */
@RequestMapping("/getStockByCache/{sid}")
@ResponseBody
public String getStockByCache(@PathVariable int sid) {
    Integer count;
    try {
        count = stockService.getStockCountByCache(sid);
        if (count == null) {
            count = stockService.getStockCountByDB(sid);
            LOGGER.info("缓存未命中，查询数据库，并写入缓存");
            stockService.setStockCountToCache(sid, count);
        }
    } catch (Exception e) {
        LOGGER.error("查询库存失败：[{}]", e.getMessage());
        return "查询库存失败";
    }
    LOGGER.info("商品Id: [{}] 剩余库存为: [{}]", sid, count);
    return String.format("商品Id: %d 剩余库存为：%d", sid, count);
}

首先设置为10000个并发请求的情况下，运行JMeter，结果首先出现了大量的报错，10000个请求中98%的请求都直接失败了。让人很慌张~

打开日志，报错如下：