IcanFixIt

在大部分分布式应用中,为了提高系统的效率,都会引入缓存,例如使用Redis。与此同时,也会带来缓存与数据库数据不一致的问题。
如果对数据一致性要求不是很高的场景,我们正常的操作是,客户端先去缓存查询,如果查询不到再去数据中查找,数据库查询到以后,
再在缓存中放一份,最后返回给客户端。这样把大多数的请求落在缓存上,减少数据库的查询操作。

如果是做数据增删改的操作,一般也是有两种情况。
1.先删除缓存,再操作数据库;
2.先操作数据库,再更新缓存。

这两种情况也各有优劣,大部分使用第二种场景。

当然这里存在缓存穿透,缓存雪崩,缓存击穿等情况,在这里不做详细解释。

这里举了例子,苹果官网预售Apple 12 Pro Max,库存是200W,然后果粉们准备去抢购,那么这里会存在以下情况:

  1. 数据库扣减库存成功了,但是更新缓存失败。例如,数据库里已经剩余100W,但缓存里还有150W,缓存库存大于数据库剩余库存。
    这种请求如何解决?其实可以再=在扣减库存前,先去查询剩余数量,如果数量不足,则返回失败。
  2. 如果数据库扣减失败了,但缓存里的缓存却更新了,也就是说缓存中库存数量小于数据库里的数量,那么就存在部分剩余库存无法卖出的问题。
    当然这种情况何难发生,因为数据库的读操作是远远快于写操作的。

但是,如果要保证数据库与缓存强一致性该如何设计?
这里可以考虑另一种思路,也就是使用MySQL的binlog。

流程图是这样的:

这里说一下流程:
1.客户端从缓存中读取;
2.如果有变更操作,更新数据库;
3.数据库事务提交以后写入binlog;
4.我们自己写一个Java应用程序,把自己模拟成一个MySQL的slave,去订阅MySQL的数据库的binlog,MySQL会把binlog dump给我们应用程序;
5.因为binlog是二进制文件,这里需要解析,处理insert、update、delete这些操作。
6.解析完以后,把这些数据丢到消息队列里。这里的消息队列有两个用处,第一是做持久化消息,第二是重试机制;
7.客户端消费消息队列的消息,然后推到缓存中,如果没有成功,进行重试。
8.更新缓存完毕。

相关文章: