- 延时双删?
- 延时双删流程:
- 先删除缓存
- 再更新数据库
- 休眠一会(比如1秒)，再次删除缓存。
- 这种方案还算可以，只有休眠那一会(比如就那1秒)，可能有脏数据，一般业务也会接受的。但是如果第二次删除缓存失败呢?缓存和数据库的数据还是可能不一致，对吧?给Kev设置一个自然的expire过期时间，让它自动过期怎样?那业务要接受过期时间内，数据的不一致?还是有其他更佳方案呢?
- 删除缓存重试机制
- 因为延时双删可能会存在第二步的删除缓存失败，导致的数据不一致问题。可以使用这个方案优化:删除失败就多删除几次,保证删除缓存成功就可以了。所以可以引入删除缓存重试机制
- 读取biglog异步删除缓存
- 重试删除缓存机制会造成好多业务代码入侵。其实，还可以这样优化:通过数据库的binlog来异步淘汰key。以mysql为例吧
- 可以使用阿里的canal将binlog日志采集发送到MQ队列里面
- 然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性
