我们从近期代码评审过程中的一段代码，开始探讨缓存和数据库的一致性问题。
探讨前置
一般来说，使用缓存主要为了提升应用性能和降低DB的直接负载，从场景上来说可以接受最终一致性方案， 如果业务场景要求 “缓存+数据库” 必须保持强一致性的话，那么需要使用同步方案，比如排它锁或者队列机制+数据库事务处理 这样的话影响系统可用性，简单情况下可以使用....还是另选方案吧
业务场景
- 商品系统的Cache和DB数据(或者RPC操作库存应用)，大致包含商品基本属性、库存、价格，
- 业务特性：读多写少，同一商品id，基本属性修改并发少，库存修改并发多(下单量大的时候库存操作比较频繁)
- 缓存操作模式上，采用Cache Aside Pattern（）
- 具体使用情况的伪代码
public Ware getById(long id) { Ware ware = Cache.get(id); if (ware != null) { return ware; } ware = Db.get(id); if(ware != null){ //缓存时间12小时,根据具体业务调整 Cache.put(ware,60*60*12); } return ware;}public void update(Param param) { Db.update(param); Cache.del(param.getId());}//Cachepublic void del(long id) { //异常 静默 CacheClient.expire("key1"+id, 0); CacheClient.expire("key2"+ id, 0);}复制代码 问题
先说说这段代码已经考虑到的问题，也是使用Cache Aside Pattern的好处
- Q: update 先执行了更新DB,然后删除cache,为什么不能先删cache,再更新DB？ A: 考虑到 getById 和 update并发执行，更新先删，但是查询并发放入，导致cache里为脏数据(读多写少使这种情况更容易出现)
- Q: update 先执行了更新DB,然后删除cache,为什么不能直接更新cache,这样也可以避免热点数据导致缓存击穿问题？
A: 1. 考虑到 update 方法本身并发执行，Db.update和Cache.update不是原子操作,会出现先更新DB的后更新cache 时序不一致问题(库存修改存在并发情况，并要求时序一致性)
A: 2. 商品的缓存数据可能包含多维度比如库存和价格，这儿更新了库存一个字段，如果更新缓存需要查询多表数据聚合放置缓存
A: 3. 此次更新的商品可能不被查询使用，比如冷数据，采用查的时候缓存起到了懒加载效果
A: 4. 缓存击穿问题，这儿的更新是基于单个商品，一般情况可忽略，请求量如果特别高，比如秒杀商品需要更改缓存结构和特殊的处理方式(比如版本替换机制,队列扣减机制等等，后续有机会bob再详解...)
未考虑到的问题
- 缓存操作使用异常静默，这是查询时候异常降级的思路，但是在更新或者删除的时候使用，因为Db.update和Cache.update不是原子操作， 如果发生异常静默，会导致缓存脏数据的出现，如果出现了脏数据，除了等待过期，还能怎么办？
- 缓存删除中我们看到会操作多个key(伪代码中2个)，如果其中1个成功，1个失败，partial failures，用户看到的数据一半对,一半错...怎么办？
- 在update方法并发执行时，多个请求依然有可能出现时序不一致导致的问题，比如先更新的后放置缓存。
- 在update和查询并行的情况下，查询接口从DB中查询出数据准备放置缓存,但是GC暂停，接着update删除缓存,查询恢复放置缓存，极端情况也可能出现脏数据
解决思路
- 根据场景设置合适的缓存过期时间,即使不一致,也只是缓存过期时间内的不一致，过期时间越短，数据一致性越高，但是查数据库就会越频繁
- 为了保持时序一致性可以采用版本化或者加锁机制(影响吞吐量)
- 为了达到最终一致性我们可以引入消息队列来作补偿，在更新后我们不删缓存而是发送消息来异步更新（技术复杂性提高）
- 采用binlog+消息队列(项目目前使用方案)，按照时序解析binlog,发送到消息队列中（使用顺序队列，延迟一定时间消费），然后业务系统顺序消费删除缓存，这样能起到最终一致性，顺序一致性 因为binlog顺序解析并且发送到顺序队列中，所以业务上可以保证顺序一致性，如果删除缓存失败可以继续重试， 为什么要延迟一定时间消费呢，这是为了保证查询和删除缓存并发会出现脏数据，因为延迟了一定时间，这段时间内查询方法应完成，然后再删除，就提高了一致性的可能
- 从业务上将缓存动静隔离(比如将库存作为单独缓存key和基础属性分开处理)、热点隔离(比如秒杀商品采用特殊处理方式)
后续
看到最后我们可以发现与其说是保证了一致性，不如说我们是在 提高缓存一致性
从上面的业务使用场景结合问题分析，我们也可以看出在不同的场景下为了达到不同的效果（一致性要求、吞吐、并发）我们有不同的方案，这些方案的选择离不开场景，但同时我们也要结合技术复杂度和团队技术水平、开发维护成本综合考虑来选择适合团队的方案。