分布式缓存一致性解决
双写模式：
会产生脏数据，解决方案有两种：
1，加锁，让一个线程执行完所有内容其他线程在执行
2，如果业务允许暂时性的数据不一致问题，可以不用管
失效模式：
读写并发的脏数据：解决方法：
1，加锁
2，频繁修改，且实时性要求较高的数据不应放缓存，直接读数据库
小总结：虽然二者都有脏数据问题，但是数据稳定，在缓存过期以后又可以得到最新的正确数据
缓存一致性的最终解决方案;
1,如果是用户维度的数据（订单，用户），这种并发几率较小，不用考虑这个问题，缓存加上过期时间，每隔一段时间触发读的主动更新即可
2，如果是菜单，商品介绍等基础信息，也可以使用canal订阅binlog的方式
3，缓存数据+过期时间足够解决大部分业务对于缓存的要求
4，通过加锁保证并发读写，写写的时候按顺序排好队，读读无所谓。所以适合使用读写锁。（业务允许临时脏数据可忽略）
一句话总结：一致性要求高的数据不放缓存
当前系统解决方案：数据过期时间+分布式读写锁
简单了解：
Canal:数据库的从服务器，MYSQL一有更新他就会立刻同步过来