现在比较常见的缓存读写策略是这样的
写模式
在数据库层前置一道缓存，是为了减轻数据库层面的访问压力。但是同一份数据落在两个系统中，势必会造成数据一致性问题。
比如说：
有多个操作t1、t2执行同时对一份数据进行update，如果t1更新完DB以后，因为某些原因造成一瞬间的延迟，使t2更新完DB以后，先把缓存给改了，这时候t1再执行更新缓存，缓存是t1=a，数据库存的是t2=b，就引发了DB和缓存双写不一致。
无论是先更新DB，再删除缓存，或者是先删除缓存，再更新DB，都无法从根本上解决问题。在同一条时间线上的并发场景下，总会有这样那样的意外。
数据一致性是CAP理论的三大基石之一，强一致性又很难保障，追求强一致性就一定会牺牲部分可用性，所以应当考虑的是在可以容忍的范围内达到数据最终一致性
通过加分布式锁来获得强一致性的做法通常是不受人待见的。
市场上比较主流的方案：
1、延迟双删
在一个线程更新了DB，再删除缓存以后，sleep一小段时间以后再删一次。
2、读写锁。
针对读多写少的场景，读写互斥，写入的时候排队，读取的时候可以并发。这个可以考虑。
3、还有一个离谱的，监听mysql的binlog日志，投递到消息队列中，发出去再更新到缓存中。
4、定时任务，定时同步，