缓存强一致性方案

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/cache-consistency-solution.html

背景

考虑到部分场景可能需要强一致性缓存：

后端更新时，需要保证使用端查询缓存时立马就能查询出最新的缓存值，且需要考虑并发场景导致的不一致情况

所谓的『强一致性』问题确认

首先，确认的是，我们讨论的一致性问题不是最终一致性这种，而是强一致性，前者可以通过数据库消费binlog设置缓存的形式实现，后者则需要考虑并发场景下的问题

方案设计–基于类似分布式锁实现

1. 在后端更新数据库前，先将缓存值设置为『LOCK』，并设置一个过期时间，这个过期时间需要根据业务场景来设置，一般来说，这个过期时间需要大于后端更新缓存的时间，这样可以保证在后端更新缓存时，缓存值一直是『LOCK』状态
2. 后端更新数据库、提交事务后，再将缓存值设置为『正常值』，这样就可以保证缓存值一直是『LOCK』状态
3. 用户侧使用缓存前时先判断缓存值不为『LOCK』，为『LOCK』则阻塞等待更新完成，否则直接使用缓存值
4. 至此，就可以保证缓存的强一致性了

可能的问题点

1. 缓存频繁更新可能影响读取效率
2. redis故障或网络问题导致等缓存更新失败，会导致缓存处于『LOCK』状态一段时间，影响读取效率

结语

1. 一般来说，这种场景下，缓存的更新频率不会很高，所以影响不大
2. 以上场景在实际业务上其实比较少，更多的还是用延迟双删，或者消费binlog设置缓存实现近实时的最终一致性就行了