时间：2024-11-22 17:56
人气：
作者：admin
Redis作为一款高效的内存数据存储系统，被广泛应用在业务系统中的缓存层，尤其是在与关系型数据库（如MySQL、PostgreSQL等）结合使用时，通过将热点数据存储在Redis中，可以在很大程度上缓解数据库的压力，提高整体系统的性能表现。
很重要的问题是：如何确保Redis缓存与数据库之间的双写一致性。双写一致性，是指当数据在数据库中发生变更时，能够及时且准确地反映在Redis缓存中。由于网路延迟，或者并发控制，往往数据的一致性受到挑战。
出现双写一致性问题，会造成数据丢失、脏读、重复读等问题。
可以通过以下的方法和策略解决：
分布式系统中的一致性指的是在多个节点上存储和处理数据时，确保系统中的数据在不同节点之间保持一致的特性。在分布式系统中，一致性通常可以分为以下几个类别：
所有节点在任何时间都看到相同的数据。任何更新操作都会立即对所有节点可见，保证了数据的强一致性。
造成影响：增加通信开销和降低系统的可用性。
弱一致性下的系统允许在一段时间内，不同节点之间看到不同的数据状态。弱一致性通常用于需要在性能和一致性之间进行权衡的场景，例如缓存系统等。
是弱一致性的一种特例，它保证了在经过一段时间后，系统中的所有节点最终都会达到一致状态。
最终一致性通常通过一些技术手段来实现，例如基于版本向量或时间戳的数据复制和同步机制。
当直接对数据库进行更新操作而没有相应地更新缓存时，后续的读请求可能仍然从缓存中获取旧数据，导致数据的不一致。
在某些场景下，为了保证数据新鲜度，会在更新数据库前先删除缓存。但如果数据库更新过程中出现异常导致更新失败，那么缓存将长时间处于空缺状态，新的查询将会直接命中数据库，加重数据库压力，并可能导致数据版本混乱。
在高并发场景下，可能存在多个读写请求同时操作同一份数据的情况。比如，在删除缓存、写入数据库的过程中，新的读请求获取到了旧的数据库数据并放入缓存，此时就出现了数据不一致的现象。
对于具备主从复制功能的数据库集群，主库更新数据后，存在一定的延迟才将数据同步到从库。如果在此期间缓存刚好过期并重新从数据库加载数据，可能会从尚未完成同步的从库读取到旧数据，进而导致缓存与主库数据的不一致。
是一种在分布式系统中广泛采用的缓存和数据库协同工作策略，在这个模式中，数据以数据库为主存储，缓存作为提升读取效率的辅助手段。也是日常中比较常见的一种手段。其工作流程如下：
问题1：为什么操作缓存的时候是删除旧缓存而不是直接更新缓存？
我们举例模拟下并发环境下的更新DB&缓存：
这时候缓存中保存的就是线程A的数据，而数据库中保存的是线程B的数据。这时候如果读取到的缓存就是脏数据。但是如果使用删除缓存取代更新缓存，那么就不会出现这个脏数据。这种方式可以简化并发控制、保证数据一致性、降低操作复杂度，并能更好地适应各种潜在的异常场景和缓存策略。尽管这种方法可能会增加一次数据库访问的成本，但在实际应用中，考虑到数据的一致性和系统的健壮性，这是值得付出的折衷。
并且在写多读少的情况下，数据很多时候并不会被读取到，但是一直被频繁的更新，这样也会浪费性能。实际上，写多的场景，用缓存也不是很划算。只有在读多写少的情况下使用缓存才会发挥更大的价值。
问题2：为什么是先操作数据库再操作缓存？
在操作缓存时，为什么要先操作数据库而不是先操作缓存？我们同样举例模拟两个线程，线程A写入数据，先删除缓存在更新DB，线程B读取数据。流程如下：
所以这样就会出现缓存中存储的是旧数据，而数据库中存储的是新数据，这样就出现脏数据，所以我们一般都采取先操作数据库，在操作缓存。这样后续的读请求从数据库获取最新数据并重新填充缓存。这样的设计降低了数据不一致的风险，提升了系统的可靠性。同时，这也符合CAP定理中对于一致性（Consistency）和可用性（Availability）权衡的要求，在很多场景下，数据一致性被优先考虑。
Cache Aside Pattern相对简单直观，容易理解和实现。只需要简单的判断和缓存失效逻辑即可，对已有系统的改动较小。并且由于缓存是按需加载的，所以不会浪费宝贵的缓存空间存储未被访问的数据，同时我们可以根据实际情况决定何时加载和清理缓存。
尽管Cache Aside Pattern在大多数情况下可以保证最终一致性，但它并不能保证强一致性。在数据库更新后的短暂时间内（还未开始操作缓存），如果有读请求发生，缓存中仍是旧数据，但是实际数据库中已是最新数据，造成短暂的数据不一致。在并发环境下，特别是在更新操作时，有可能在更新数据库和删除缓存之间的时间窗口内，新的读请求加载了旧数据到缓存，导致不一致。
它们主要用于缓存系统与持久化存储之间的数据交互，旨在确保缓存与底层数据存储的一致性。
Read-Through 是一种在缓存中找不到数据时，自动从持久化存储中加载数据并回填到缓存中的策略。具体执行流程如下：
Write-Through 是一种在缓存中更新数据时，同时将更新操作同步到持久化存储的策略。具体流程如下：
Read-Through 和 Write-Through 的共同目标是确保缓存与底层数据存储之间的一致性，并通过自动化的方式隐藏了缓存与持久化存储之间的交互细节，简化了客户端的处理逻辑。这两种策略经常一起使用，以提供无缝且一致的数据访问体验，特别适用于那些对数据一致性要求较高的应用场景。然而，需要注意的是，虽然它们有助于提高数据一致性，但在高并发或网络不稳定的情况下，仍然需要考虑并发控制和事务处理等问题，以防止数据不一致的情况发生。
Write Behind（异步缓存写入），也称为 Write Back（回写）或 异步更新策略，是一种在处理缓存与持久化存储（如数据库）之间数据同步时的策略。在这种模式下，当数据在缓存中被更新时，并非立即同步更新到数据库，而是将更新操作暂存起来，随后以异步的方式批量地将缓存中的更改写入持久化存储。其流程如下：
使用 Write Behind 策略时，由于更新并非即时同步到数据库，所以在异步处理完成之前，如果缓存或系统出现故障，可能会丢失部分更新操作。并且对于高度敏感且要求强一致性的数据，Write Behind 策略并不适用，因为它无法提供严格的事务性和实时一致性保证。Write Behind 适用于那些可以容忍一定延迟的数据一致性场景，通过牺牲一定程度的一致性换取更高的系统性能和扩展性。
延时双删策略主要用于解决在高并发场景下，由于网络延迟、并发控制等原因造成的数据库与缓存数据不一致的问题。
当更新数据库时，首先删除对应的缓存项，以确保后续的读请求会从数据库加载最新数据。
但是由于网络延迟或其他不确定性因素，删除缓存与数据库更新之间可能存在时间窗口，导致在这段时间内的读请求从数据库读取数据后写回缓存，新写入的缓存数据可能还未反映出数据库的最新变更。
所以为了解决这个问题，延时双删策略在第一次删除缓存后，设定一段短暂的延迟时间，如几百毫秒，然后在这段延迟时间结束后再次尝试删除缓存。这样做的目的是确保在数据库更新传播到所有节点，并且在缓存中的旧数据彻底过期失效之前，第二次删除操作可以消除缓存中可能存在的旧数据，从而提高数据一致性。
删除缓存重试机制是在删除缓存操作失败时，设定一个重试策略，确保缓存最终能被正确删除，以维持与数据库的一致性。
在执行数据库更新操作后，尝试删除关联的缓存项。如果首次删除缓存失败（例如网络波动、缓存服务暂时不可用等情况），系统进入重试逻辑，按照预先设定的策略（如指数退避、固定间隔重试等）进行多次尝试。直到缓存删除成功，或者达到最大重试次数为止。通过这种方式，即使在异常情况下也能尽量保证缓存与数据库的一致性。
这种重试方式确保缓存删除操作的成功执行，可以应对网络抖动等导致的临时性错误，提高数据一致性。但是可能占用额外的系统资源和时间，重试次数过多可能会阻塞其他操作。
监听并读取biglog异步删除缓存
在数据库发生写操作时，将变更记录在binlog或类似的事务日志中，然后使用一个专门的异步服务或者监听器订阅binlog的变化（比如Canal），一旦检测到有数据更新，便根据binlog中的操作信息定位到受影响的缓存项。讲这些需要更新缓存的数据发送到消息队列，消费者处理消息队列中的事件，异步地删除或更新缓存中的对应数据，确保缓存与数据库保持一致。
这种方法的好处是将缓存的更新操作与主业务流程解耦，避免阻塞主线程，同时还能处理数据库更新后由于网络问题或并发问题导致的缓存更新滞后情况。当然，实现这一策略相对复杂，需要对数据库的binlog机制有深入理解和定制开发。
在分布式系统中，为了保证缓存与数据库双写一致性，可以采用以下方案：
读取操作：
更新操作：
同时，还需注意以下要点：
本文转载自：https://www.coderacademy.online/article/redismysql.html
关注微信