先删缓存还是先删数据库 DB读写分离情况下，如何解决缓存和数据库不一致性问题？
DB读写分离情况下，如何解决缓存和数据库不一致性问题？
有两种选择。
让我们首先了解缓存和数据库数据不一致时会发生什么。查询数据时，优先从缓存中获取数据。如果缓存不存在，则查询数据库并写入缓存。如果数据库数据发生更改，请清除缓存。在正常情况下，没有问题。但是，在服务的并发性非常高的情况下，如果删除缓存，则在数据库完成数据更新之前会有查询请求。此时，旧数据将被读写到缓存中。在这种情况下，缓存和数据库不一致。
第一种解决方案：延迟删除。更改数据库数据时，清除缓存的操作会延迟一段时间。这段时间可能很短。它只需要确保数据库写入操作已完成。但在实际环境中，我们不知道数据库何时会写入数据，所以很难控制这段时间。如果太短，就不行了。如果时间太长，会影响体验。但总的来说，这种方法可以解决问题。
另一种解决方案是使用数据库的binlog来订阅binlog。更新数据时，该消息用于通知删除缓存。该方案能保证数据库更新操作的完成和缓存的及时更新。
用了缓存了，数据库就没问题了吗？
当然不是。
如果数据库有问题，我们应该根据系统对数据库的读写压力来决定。
通常当用户达到一定水平后，我们会根据系统的业务特点进行相应的技术架构调整和服务器扩展。让我简单介绍一下常见的中小互联网公司的数据扩展过程。其过程大致如下：
单实例数据库--->读写分离--->缓存服务--->多实例数据库--->多实例缓存--->冷热分离--->数据平台沉淀--->分布式搜索引擎
当然，这个过程不是很严谨，但也很复杂非常粗糙。不同的业务系统需要不同的拆分和数据扩展方法。有些人甚至喜欢使用服务器本身的内存来缓存一些数据。这里只是一个简单的解释，当系统给数据库带来压力时，我们应该继续做技术跟进。当然，随着业务系统的发展，技术架构往往是解耦的。技术架构和业务架构相辅相成。
这里是一个简单的帖子，提供了一个常见的基本互联网架构图：
如果您对系统架构设计感兴趣，请注意或查看我以前的答案。有信息共享。谢谢您
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
