数据库事务环境下表级缓存的更新问题

表数据过多时，通常会为表的记录增加缓存。在我们的业务中，用户的信息是使用redis来做缓存的，避免用户的每次请求都直接查询数据库。 在一些场景下，需要为用户的一连串数据库操作做事务管理，同时也需要删除掉旧的用户信息表的缓存。例如现在有一个金币兑换物品的场景，用户兑换的流程如下：

1. 用户信息表：扣除用户金币
2. 用户的兑换表：新增一行记录，状态为：“已扣金币；未创建订单”
3. 用户金币流水表：新增用户扣除金币记录
4. 进行实际下单兑换的接口调用
5. 更新用户兑换表状态为：已扣除金币

如果在进行实际下单兑换时接口调用返回来非超时失败，那么需要将1、2、3步骤的数据库操作进行回滚。 这种场景下，什么时候删除旧的缓存就显得很重要，更新缓存的时机不当，会留下缓存数据与数据库数据不一致的隐患。例如将缓存删除的操作位于以下位置时：

1. 用户信息表：扣除用户金币 --》 删除用户信息表缓存
2. 用户的兑换表：新增一行记录，状态为：“已扣金币；未创建订单”
3. 用户金币流水表：新增用户扣除金币记录
4. 进行实际下单兑换的接口调用
5. 更新用户兑换表状态为：已扣除金币

在并发的情况下，可能会出现：

• 下单兑换的线程删除了用户信息表缓存
• 另一个请求的线程重新读取用户信息表数据并更新了缓存
• 此时下单兑换的线程下单失败进行了金币回滚

此时缓存中的用户金币与数据库表中的用户金币是不一致的。将缓存删除的位置处于以下位置时：

1. 用户信息表：扣除用户金币
2. 用户的兑换表：新增一行记录，状态为：“已扣金币；未创建订单”
3. 用户金币流水表：新增用户扣除金币记录
4. 进行实际下单兑换的接口调用
5. 更新用户兑换表状态为：已扣除金币 --》 删除用户信息表缓存

则不会发生以上的情况。在使用表级缓存 + 数据库事务 的环境下 需要注意这个问题。 同理的，在更新表级缓存的时候，在数据库的数据成功更新后，再删除缓存，才是稳妥的操作。