前言
我们在日常工作中经常会遇到要求缓存和数据库强一致性的问题，我们平常的做法是，确保数据库插入成功，然后再更新缓存，但有时候数据库插入成功后，缓存出现问题或者缓存系统挂了，这时候请求会直接访问数据库最新的数据，但是当缓存恢复的时候，我们的并发请求又会访问到以前旧的缓存数据，这时候就会出现不一致问题。如果我们的业务系统对一致性要求不高，那么可以这么做，但是如果必须是强一致性，那么这个方案是有明显漏洞的。
有的朋友可能会说，当缓存恢复的时候直接清空缓存就可以了，然后重新加载一遍，这样有二个问题，第一个是我们的缓存数据有一部分其实是不经常变动的，全部清空再加载效率就非常低了。
方案一讲解
- 数据写入端
注：同样我们是同时写数据库和缓存，但是在写缓存的时候会判断写入是否成功，如果写入出错，我们将key和更新状态值插入到数据库状态表中，同时关闭前端访问缓存的开关。
- 数据读入端
注：客户端在读数据的时候，要先判断一下当然开关是否打开，如果打开则读取缓存，如果关闭则直接访问数据库。关于判断缓存开关的问题，可以不用每次读库，而可以事先缓存到本地。
- 缓存恢复端
注：后台有一个守护定时任务，每隔一定时间来检测缓存系统是否可用，如果可用则从状态表中读取key值和更新状态位，然后打开缓存读取开关，这样前端数据读取端则能够从缓存读取最新数据。
- 总结
这方案的前提是当前并发量并不是非常大的情况，试想如果当前并发非常大，同时缓存又出了问题，这时候整个请求就穿透到了数据库层造成严重问题。
那么我之前的初步想法是将这个流程封装为中间件，根据不同库配置不同的数据源，客户端只需要直接请求中间件即可。但此方案不适合分库分表的场景！在某种情况下是有局限性的！这个方案更多是为大家提供一种思路！
方案二讲解
当缓存不可用时，在第一时间不对数据库服务发起请求，在需要的时候异步填充缓存（优先热点缓存），然后我们将前端的请求直接返回失败，也就是快速返回失败，直到缓存恢复并且热点缓存填充完毕。
注：在某些情况下，这种方法意义不大，但当系统的一部分发生故障时可以确保系统仍然可用的一种方式，让请求快速失败，确保不占用资源，也避免了级联下游服务的故障。
