认识达内从这里开始

数据库编程开发技术随着互联网的不断发展而被越来越多的程序员掌握，而本文我们就简单来了解一下，数据库缓存一致性问题都有哪些。

什么是数据库与缓存的一致性问题

程序员应该没人不懂这个，但我还是觉得应该写上，有头有尾。所谓数据库与缓存的一致性问题，可以说是伴随着计算机这个东西一路走来的古老问题。

就我所知早的缓存一致性问题案例就是CPU的Cache与内存之间的缓存一致性问题。

学过计组的都知道，每个CPU都有自己独享的高速缓存Cache，而Cache本质上是对于内存的缓存，当多个CPU共享一个内存时，该问题就来了，比如A，B两个CPU的高速缓存中都存储了内存上0x00001111这个地址的数据，如果此时A处理完了该数据并写回了内存，那么显然B的Cache中的该数据就过期了，如果B又读取了该数据进行处理，那么就使用了错误的数据。我们必须保证所有CPU读取到的缓存中的内容是真实的，不然处理虚假的数据只会造成错误的结果。而这一点引申至一切数据库+缓存的结构中都适用。

CPU的解决方案是基于总线嗅探机制的MESI协议，这个大家也都学过不细说，总之该协议保证了写传播和事物的串行化，解决了CPU的缓存一致性问题，保证了我们使用计算机所获得的服务质量。

扯远了，总之缓存一致性问题本质上就是缓存数据与数据库数据之间的同步问题，一旦数据库中的数据被修改，就必须要让所有缓存了该数据的用户都知道该数据缓存已经失效，需要读取新值。

缓存一致性的解决方案在不同场景下的分析

解决方案无论好坏我都列在下面，如果你希望找一个靠谱的方案请选后面的，前面的例子主要还是给自己看看理解理解。

利用写入顺序的方案

先写缓存再写数据库

先写数据库再写缓存

删除缓存方案

先删除缓存，再写数据库

先写数据库，再删缓存

先写缓存，再写数据库

目前没人会用的方案，先写缓存风险太大，因为要明确当今主流的微服务架构下，任何服务都是不那么可靠的，如果先写缓存成功，再写数据库却失败了，这时我们的缓存中就出现了假数据，这是不可接受的，所以目前这种方案采用的很少。

先写数据库，再写缓存

虽然没有假数据那么严重但还是存在同样的问题，如果先写数据库成功，再写缓存失败，那么数据库中数据虽然真实但是也读取不到，还是没有意义，指望服务自己争气不要出错等同于给自己埋雷。

也有人在这里会说可以把写数据库和写缓存都放在一个事务中，借助事务的原子性来保证正确。这还是会存在非常多的问题，在小并发量下勉强能用，但是这个做法将会严重影响接口性能，不过有时候我很怀疑学校自己的抢课系统是不是就是这么做的，不然怎么能每次抢课都那么卡...

但是一旦并发量起来，这个方案还是会遇到先后顺序的问题，比如A，B两个用户在几乎相同的时间开启了事务准备写回数据，其中A先写完了数据库，但是写缓存时网络波动被延迟，所以又慢于B写缓存，那么两个事务执行完，你就会发现数据库中是B写的，缓存中是A写的，还是不一致，更不用说每次写数据库操作还需要附带一次写缓存，本身就是对于系统资源的一种浪费。

那如果通过加锁来防止并发事务出错，先你需要在这里引入分布式锁问题，相当复杂，其次，这将进一步影响本来就不太行的系统性能，大大折损整个系统的吞吐量，所以总的来说这个方案还是抛弃比较好。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。