分布式缓存数据一致性问题

双写模式

双写模式是指修改数据后写到数据库，接着写到缓存；

双写模式带来的问题

A：写数据
B：写数据–>写到缓存
A：写到缓存
B写了数据，最终读到的是A写的数据；

可能由于卡顿等原因，导致写缓存B在最前，写缓存A在后面就出现了不一致；

双写模式的解决方案

• 给写到数据库和写到缓存加锁，保证整个过程的完整性；
• 看业务是否允许数据短时间的不一致性（给缓存加过期时间）；

失效模式

失效模式值数据更新写入数据库，删除缓存数据，下次查时再存入缓存；

失效模式带来的问题

A：写数据db1，删缓存
B：在A删缓存之前开始写数据db2(卡顿，还没写完)
C：读缓存(db1)，B写完数据并且删了缓存，C再更新缓存
此时读到的数据还是db1；

失效模式的解决方案

• 对写数据和删缓存加锁，保证整个过程的完整性；但会使整个过程变得笨重，如果经常修改的数据，可以直接读数据库；
• 看业务是否允许数据短时间的不一致性（给缓存加过期时间）；

缓存数据一致性解决方案

无论是双写模式还是失效模式，多个实例同时更新都会导致数据不一致问题；

• 1、如果是用户纬度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，缓存数据加上过期时间，每隔一段时间触发读的主动更新即可；
• 2、如果是菜单，商品介绍等基础数据，也可以去使用canal订阅binlog的方式；
  canal：阿里开源中间件，伪装mysql从库，从biniog日志拿到mysql更新数据；
• 3、缓存数据+过期时间足够解决大部分业务对于缓存的要求；
• 4、通过加锁保证并发读写，写+写的时候按顺序排好队。读+读相当于没加锁。所以适合使用读写锁。（业务不关心脏数据，允许临时脏数据可忽略）;

总结

• 我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间，保证每天拿到当前最新数据即可；
• 我们不应该过度设计，增加系统的复杂性；
• 遇到实时性、一致性要求高的数据，就应该查数据库，即使慢点。