火影bug，未保证短时间数据一致性，拿这个例子讲一下Redis

本文只拿这个游戏的bug来举例Redis，如果有不妥的地方，联系我进行删除

描述：今天在高速上打火影（有隧道，有时候会卡），发现了个bug，我点了两次-1000的忍玉（大概用了1千七百多忍玉），但是神器等级没有增加，可是忍玉数量减少了，过了几小时后，我再登录，神器等级才看到增加。

原来神器等级58，123（没截图）

后面神器等级59，450

1.问题（查询到假数据）

这里假设用的是MySQL和Redis

1.1 业务流程（将信息放入MQ，先操作数据库，再操作Redis）

假设先对忍玉和神器等级的数据库进行update操作，然后进行删忍玉和神器等级缓存（为什么不是更新缓存呢，因为如果我们一直操作数据库，就要一直更新缓存，如果用户不进行查询，那么这些更新缓存的操作就是多余的浪费资源，我们直接删缓存，等用户来查的时候我们再去查一次数据库就好了）

如果一切正常的话，数据库得到更新，缓存得到删除，当用户来查的时候，就拿到了新数据

但是由于我们卡（或其他问题），导致部分进程异常终止，导致没有删缓存的操作，这就导致了我们继续查神器等级的时候，还是拿到了旧数据（Redis存有，直接返回）

2.解决方案

上面是先操作数据库，再操作Redis

由于操作数据库的时间远远大于操作Redis的时间，这就导致在操作数据库的时候出现bug的几率就会增大，所以，我们可以换一下顺序，即 我们先操作Redis，再操作数据库，因为操作Redis的时间很短，这个时间段内出现bug的几率贼低，所以我们删了缓存后，不管数据库是否能正常执行，我们继续查询神奇等级的时候，肯定会比上面那种情况会好，可以拿到新数据。