缓存分布式一致性问题

        缓存一致性问题发生的原因，是在更新数据时数据库和缓存数据的不一致。我们要做到保证缓存的最终一致性。如果数据需要强一致性建议直接查询数据库。

双写模式

双写模式为先写数据库，在写缓存。

        进来两个请求，先执行“请求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.读写数据的时候，加上分布式的读写锁（读相当于无锁状态）。