例如：项目中，如果人为修改了一个DB数据，那么就会产生缓存层与DB数据不一致，测试环境我就就直接删缓存了。
比较适合小项目的解决方案：
生产环境一般不非法人为操作数据库。
基于代理数据源方式，判断commit提交成功的情况下，将数据异步的提交到redis中。
因为多线程，大项目会对项目有不小影响，可以用mq异步会更好些。
一、多线程：如果并发上来，采用多线程，线程池满了，会导致项目内存爆掉，或拒绝请求。如果出现这种情况可以存在本地文件中，下次做补偿。
如果人为修改数据库一定会造成数据不一致。
二、mq:插入更新删除的时候，将数据放入mq中，昨晚DB操作后，操作redis.
缺陷：耦合度较高，同步操作在一个业务里。如果操作完db停了，那redis还是会不一致。
解决缺陷：mysql主从复制。通过mysql 的binlog文件。mysql主从
binlog:对mqsql操作的写的请求都会有一个二进制的日志文件。
mysql主从复制业务场景：从只读。一般的云数据库都是主从一套，但是有时间的备份
1.备份mysql数据。
2.读写分离
3.高可用集群
cannal:
分布式微服务项目不可能保证强一致性，最基本的网络传输也需要时间的，只不过时间很快，像是强一致性。
分布式领域中无法保证强一致性，但是可以保证最终一致性。短暂的数据不一致是允许的，但是最终数据一定一致。
上图还有问题，如果频繁的操作db那么canal监听是单线程的，会造成阻塞增大延迟。
下图这种方法，如果出现db操作过大，可以建立mq消费者集群，但是要注意消息顺序性，mq中有
此处其实还有一个问题，binlog的json发送过来的写入mq的时候，多个消费者会出现操作的前后顺序混乱，也可以做成一个queue对应一个消费者，用内存队列存储然后操作。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
