缓存分布式一致性标题

        缓存一致性标题发生的缘故原由，是在更新数据时数据库和缓存数据的不一致。我们要做到保证缓存的最终一致性。如果数据需要强一致性发起直接查询数据库。
双写模式

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

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



免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。