缓存

电商系统高并发场景中的缓存 DB 数据一致性问题

电商系统中存在非常多的高并发场景，而高并发场景又存在非常多的缓存 DB 等数据一致性问题。这些问题具体是怎么造成的，今天我们一起来看图说话！

对应高并发系统，系统的压力一般都在后端的 DB 中。大量的并发写、并发读，给 DB 带来非常大的压力。一不小心就会产生崩溃，导致整个系统不可用。当然，实际生产中我们肯定有其他的策略来保证服务的可用性、可靠性。高可用是我们的第一要素，第一要求。

安全是第一生产力，在电商的系统里也存在这样的真理！

为了降低 DB 的压力，我们通常会引入缓存来解决问题。redis 做一个缓冲操作，让请求先访问到 redis，而不是直接访问 MySQL 等数据库。

上图就是一个电商系统中的缓存 + DB 模式系统简图。

在这个业务场景，主要是解决读数据从 Redis 缓存，一般都是按照下图的流程来进行业务操作。

但是引入 Redis 缓存后，会带来一些新问题。比如标题中的数据一致性问题，以及缓存设计不合理，缓存穿透等问题。

所以并没有完美的技术，完美的架构。都是选择各自的优点，并使用它们的优点打造一流的系统。

数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。你到底是先操作数据库呢？还是先操作缓存？

不管是先写 MySQL 数据库，再删除 Redis 缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。

如果删除了缓存 Redis，还没有来得及写库 MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。

如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。因为写和读是并发的，没法保证顺序，就会出现缓存和数据库的数据不一致的问题。

出现问题后，我们就要思考如何去解决这类问题。

同志们，你们先思考一下如何解决这类问题？想要成功牛逼的人，必须要有牛逼的想法。伟人的成功都离不开思考啊！

先给大家提个醒，推荐几个解决方案。如：采用延时双删策略，设置缓存过期时间策略，异步更新缓存(基于订阅binlog的同步机制)策略等。具体的策略，我们明天继续！

本文由 创作，采用 知识共享署名4.0 国际许可协议进行许可。本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名。最后编辑时间为: 2021/04/19 10:35