数据库缓存双写一致性的一些个人想法
有这么个问题，还是经典面试题：
说我们有个数据库，他的读请求特别多，以至于要在数据库上加一层缓存来抗压，这个都能理解吧。
这里的缓存，可能是和数据库一样的数据，也可能是数据库的数据经过一系列复杂运算，得出的结果。
但是涉及到更新数据库内容的时候，如何能保证缓存也能同时更新呢
先说说网友的说法：
1、先删除缓存，再更新数据库，再更新缓存（容易造成脏读）
2、先删除缓存，再更新数据库，然后等若干毫秒，再删除缓存，再更新缓存（降低吞吐量）
3、先删除缓存，再更新数据库，同时把这个更新的请求放在队列中，后面有读这个即将更新的数据的请求，如果发现缓存没数据，会再队列中看一眼，发现这条数据正在更新的话，就轮询着查缓存，直到查到数据，否则一段时间后，要么超时返回，要么返回旧数据。
4、还有一些反例的说法，比如先更新缓存再更新数据库之类的，我这里就不多解释这样做的问题了。
关于这个问题，现在我说下我的理解，可能与网上其他说法略有差异
1、首先确认一点，什么时候应该用缓存，那就是读多写少的情况。一般应用都是这样，如果你的场景不是读多写少的，我还是不建议使用缓存的，因为写操作一多，就涉及到事务相关了，数据库已经把事务做的那么完善了，你非要在上面加个缓存自己再实现一遍，出了问题不是自找么。
2、还有，如果你的系统，对准确性要求特别高，比如涉及到钱的计算，比如转账，那也不建议用缓存，直接加机器吧，把数据库分片，分的片越多，性能越好，而且这种情况一般都有唯一id，比如账号，而对于同一个账号，基本不会出现什么并发，所以老老实实用数据库就行了。
3、除了以上这两种情况，那数据库缓存双写一致性，那还说个啥。想要数据库缓存一致，就必须牺牲吞吐率，而加缓存的原因，就是读请求太多，吞吐率跟不上了，那为了解决一致性，反而把吞吐量又降低了，这不有点自相矛盾么。
总结：
有时候，我们发现问题，就一定要解决，当然这是一个很好的习惯。
但如果你作为一个项目的负责人或者技术负责人，在技术层面加了时间观念，就是不仅要把技术搞好，还要把项目搞好，要尽快搞好，那就不能单纯的看技术了，还要多方面考虑。
因为有些问题，其实是可以绕过的，就比如这个数据库缓存一致性，如果你的项目实在是解决不了这个一致性，不妨不要解决了，退一步，试试不用缓存，还有没有其他方案，比如增加数据库抗压能力等等。
当然，以上都是我的个人一些想法，不一定都对，如果你有任何想法，欢迎交流。
