表数据过多时,通常会为表的记录增加缓存。在我们的业务中,用户的信息是使用redis来做缓存的,避免用户的每次请求都直接查询数据库。
在一些场景下,需要为用户的一连串数据库操作做事务管理,同时也需要删除掉旧的用户信息表的缓存。例如现在有一个金币兑换物品的场景,用户兑换的流程如下:
- 用户信息表:扣除用户金币
- 用户的兑换表:新增一行记录,状态为:“已扣金币;未创建订单”
- 用户金币流水表:新增用户扣除金币记录
- 进行实际下单兑换的接口调用
- 更新用户兑换表状态为:已扣除金币
如果在进行实际下单兑换时接口调用返回来非超时失败,那么需要将1、2、3步骤的数据库操作进行回滚。
这种场景下,什么时候删除旧的缓存就显得很重要,更新缓存的时机不当,会留下缓存数据与数据库数据不一致的隐患。例如将缓存删除的操作位于以下位置时:
- 用户信息表:扣除用户金币
--》 删除用户信息表缓存 - 用户的兑换表:新增一行记录,状态为:“已扣金币;未创建订单”
- 用户金币流水表:新增用户扣除金币记录
- 进行实际下单兑换的接口调用
- 更新用户兑换表状态为:已扣除金币
在并发的情况下,可能会出现:
- 下单兑换的线程删除了用户信息表缓存
- 另一个请求的线程重新读取用户信息表数据并更新了缓存
- 此时下单兑换的线程下单失败进行了金币回滚
此时缓存中的用户金币与数据库表中的用户金币是不一致的。将缓存删除的位置处于以下位置时:
- 用户信息表:扣除用户金币
- 用户的兑换表:新增一行记录,状态为:“已扣金币;未创建订单”
- 用户金币流水表:新增用户扣除金币记录
- 进行实际下单兑换的接口调用
- 更新用户兑换表状态为:已扣除金币
--》 删除用户信息表缓存
则不会发生以上的情况。在使用表级缓存 + 数据库事务 的环境下 需要注意这个问题。
同理的,在更新表级缓存的时候,在数据库的数据成功更新后,再删除缓存,才是稳妥的操作。