|
请求量越来越大的时候，系统会慢慢出现瓶颈，由于数据库的链接是有限的，无法支撑较高的QPS，所以我们要想一个办法分担数据库的压力，于是就有了双写，将数据写入缓存，客户端读取数据直接从缓存中读取，这样就可以提高系统的性能。
但是如果要使用双写，那么不管是先更新缓存还是先更新mysql，总会有时间间隔，那么就要保证你的业务在一定程度上允许短暂的数据不一致的情况出现，否则，还是不建议使用的.
那么就有人问了?双写一定不能保证强一致性吗?案是可以，只要把所有与其相关的读写请求用队列串行化，这样就可以保证双写的强一致性了，但是这样会极大的降低系统的QPS，非常不推荐这种做法。
既然要双写，那么肯定会出现数据库和缓存数据不一致的情况，要怎样去避免呢?
双写不一致问题要怎么解决
一.先更新数据库，再更新缓存
这种情况会有什么问题呢?我们看下图:先更新数据库，按照正常流程来走，紧接着要a线程删除缓存，可是突然后面来了个b线程，并且a线程因为各种业务原因卡住了，导致b线程先完成了，之后a线程才更新缓存。这时突然有其他线程进来读数据，就会读到a的数据，但是按照业务流程来走，应该读到b的数据，此时，就出现了数据错乱的问题。
-
1.线程a更新数据库
-
2.线程b更新数据库
-
3.线程b更新缓存
-
4.线程a更新缓存
-
5.其他线程读数据(读错了)
到这里我们会发现，直接更新缓存是有很大的问题的，而且很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值，有可能是联合其他的很多数据结合计算出来的一个值。
而且可能会有一种场景，我们经常在更新数据库后直接更新缓存，但是在此之间并没有缓存被访问的需求，这样我们就做了很多无用功，付出了很多代价。
大家应该对单例模式有所了解，其中有一种懒加载的思想，就是说，在你需要的时候再去加载，用在双写的情况下非常合适，也就有了下面这种先更新数据库，再删除缓存的模式。
二.先更新数据库，再删除缓存
然也有了，其实我们可以每次写入都记录日志，然后修改结束后也记录日志，通过日志状态来判断是否写入成功，
-
如果没有写入成功后续并且没有新的写入请求，就补写，
-
否则不做处理。
但是这种情况也会出现不一致的问题，就是如果写数据库程序断了，到下次恢复数据之前这段时间，还会出现数据不一致的情况。
并且如果是频繁写入的情况，很有可能日志机制没有发挥作用，就有新数据写入覆盖，并且日志系统还要占用额外的资源。
我懂了!应该先删除缓存再更新数据库，这样就可以了!
三.先删除缓存 再更新数据库
来来来，继续贴图，是不是很熟悉?
（编辑：宁德站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
