数据一致性问题出现原因
在高并发场景下，如果每一次请求都要访问数据库，那么性能一定是低的，因为数据库存储在磁盘里，磁盘的IO操作是比较慢的；
所以就出现的缓存技术，因为内存IO要比磁盘IO快很多，将一些数据存到内存中可以显著的提高访问效率，常用的就是Redis来做缓存。
但同时也会产生一些问题，在缓存和数据库同时存在时，如果数据需要修改，是应该先修改数据库还是先修改缓存呢？这个问题就是数据一致性问题。
解决方案
先更新数据库，再更新缓存
该方案可能会导致数据不一致的情况。
如果在更新数据库后并在更新缓存前服务挂掉了，此时数据库更新了，缓存没有更新，数据库和缓存的数据不一致；
还有一种极端的情况：
如果在更新数据库后，还没来得及更新缓存呢，大量的请求访问缓存，那么这些请求所读到的都是脏数据；
先更新缓存，再更新数据库
该方案可能会导致数据不一致的情况。
如果在更新缓存后并在更新数据库前服务挂掉了，此时缓存更新了，数据库没有更新，数据库和缓存的数据不一致；
先删除缓存，再更新数据库
该方案巧妙的解决数据不一致的问题：
先删除缓存，如果删除成功，下次请求时到数据库重新拿数据写入缓存，如果删除失败，也不会更新数据库；
这种方案虽然没有数据一致性问题，但会产生性能问题：
如果缓存删除成功后有大量的请求来访问，这就会造成穿透、击穿甚至是雪崩问题
MQ异步处理
MQ有消息重投机制，缓存和数据库有一个写入失败消费失败，可以重新消费，重新写入缓存和数据库
缺陷
数据同步会有一段时间的延迟，并发场景下，会有大量请求读到脏数据
canal订阅Mysql的binlog
