缓存分布式一致性问题
缓存一致性问题发生的原因，是在更新数据时数据库和缓存数据的不一致。我们要做到保证缓存的最终一致性。如果数据需要强一致性建议直接查询数据库。
双写模式
双写模式为先写数据库，在写缓存。
进来两个请求，先执行“请求1”的操作写入数据1，这时可能由于各种原因，“请求1”卡顿。这时候我们的“请求2”执行写数据库为2，更新缓存为2。“请求1”卡顿结束继续写缓存为1。现在出现问题，我们的缓存本该为2，现在却是1，出现了脏数据。
脏数据问题：
暂时性脏数据，但是数据是稳定的，缓存过期后，又能得到最新的正确数据。
保证的是最终一致性。
失效模式
写数据库后删除缓存，当有用户查询时缓存为空，更新添加缓存。
“请求1”在写完数据1后删除缓存。“请求2”在写缓存时如果出现比较慢的情况，这是进来“请求3”的查询操作，读取缓存为空，然后读取数据库为1。
这时候执行有一个情况，“请求2”写完数据库，执行删除缓存。“请求3”更新缓存，那么这时候更新缓存数据为1，与数据库中最新的2不一致，出现一致性问题。
脏数据问题：
暂时性脏数据，但是数据是稳定的，缓存过期后，又能得到最新的正确数据。
缓存数据一致性解决方案
双写模式或者失效模式都会导致缓存不一致问题的出现。那么怎么处理？
1.如果是用户纬度的数据，并发几率小，可以不用考虑大并发出现的一致性问题，缓存加上过期时间，每隔一段时间触发读的主动更新即可解决。
2.如果是菜单、商品介绍等基础数据，可以使用cannal订阅数据库binlog方式进行个性化处理。
3.缓存数据+过期时间可以足够解决大部分业务对缓存的要求。
4.通过加锁保证并发读写，可以使用读写锁。
总结：
我们能放入缓存的数据就不应该是实时性、一致性要求超高的数据。
不应该过度设计，增加系统的复杂度。过度设计会增加大量的开发工作以及维护工作。
缓存一致性解决-Canal
更新缓存
Canal是阿里开源的中间件，可以模拟成数据库的从服务器，直接订阅数据库的binlog日志，然后拿到变化后更新redis
优点：改数据库就可以了，不用关心任何的缓存操作，数据修改完成自动同步更新。
缺点：增加了中间件，需要额外开发。
解决数据异构问题
我们去浏览淘宝京东，每个人推荐的商品都是不一样的，基于爱好进行推荐，可以使用Canal进行操作，简单逻辑：
总结
一致性解决方案：
1.缓存所有数据都要有过期时间，保证数据过期后的下一次查询触发主动更新缓存。
2.读写数据的时候，加上分布式的读写锁（读相当于无锁状态）。