目录一、走进业务中的缓存一本地缓存二分布式缓存二、缓存更新模式分析一Cache Aside Pattern旁路缓存模式读操作流程写操作流程流程问题思考问题1为什么不是先删缓存再更新数据库问题2为什么更新操作是将cache失效而不是更新Cache Aside Pattern模式不一致问题的发生二Read/Write Through Pattern读写穿透模式Read ThroughWrite Through三Write Behind Caching Pattern异步写缓存模式四几种模式对比三、缓存一致性分析一一致性问题根因业务层面引起的一致性问题系统层面引起的一致性问题二强一致性解决方案采用强一致性协议并行请求转为串行化综合考虑三最终一致性解决方案重试机制重试binlog综合考虑四、缓存热门问题分析和解决一缓存穿透问题描述解决策略分析二缓存雪崩问题描述解决策略分析三缓存击穿问题描述解决策略分析四热点key问题问题描述五大key问题问题描述大key的认定解决策略分析五、复杂工程应对本地缓存双缓存方案一本地缓存双缓存方案架构本地缓存双缓存方案优势与实施细节二策略层设计降级策略兜底策略报警策略三缓存查询流程1. 主备缓存切换2. 缓存异常处理3. 异常情况处理四缓存更新策略流程1. 数据总线重试机制2. 双缓存更新策略3. 自动校对任务六、总结干货分享感谢您的阅读在日常生活中大家都会在家里储备一些粮食比如米面油。但是你不会在初期就囤积大量的食物比如说一口气买半年甚至一年的粮食。如果你住的地方附近有便利的超市随时可以买到新鲜的食物且你目前的家庭成员不多消耗量不大那么大规模囤粮不仅占用储物空间还可能造成浪费因为食品有保质期。只有在你预计家里即将迎来很多客人或者附近的超市要关门维修几个月时大规模囤粮才是明智之举。说这个例子主要还是想提缓存的必要性虽然缓存技术可以大幅提升系统性能但在没有明确需要时应该慎重考虑是否使用缓存。如果在系统初期或者短期内直接使用数据库就能满足业务需求那么最好先不要引入缓存。缓存的引入应该是在系统确实需要提升性能或者有其他明确原因的时候。历史基础问题回顾具体内容基础对应详细知识和解法链接探析缓存穿透问题高并发场景下的缓存穿透问题探析与应对策略探析缓存雪崩高并发场景下的缓存雪崩探析与应对策略-CSDN博客探析缓存击穿高并发场景下的缓存击穿问题探析与应对策略-CSDN博客热key识别与实战解决优化分布式系统性能热key识别与实战解决方案_热key识别框架-CSDN博客探析缓存热点key高并发场景下的热点key问题探析与应对策略_热点账户高并发解决方案-CSDN博客探析大 Key 问题高并发场景下的大 Key 问题及应对策略-CSDN博客一、走进业务中的缓存在现代高并发系统中缓存作为一种关键技术被广泛应用于各种场景中以提升性能和系统稳定性。缓存的存在使得系统能够在面对大量请求时依然保持高效的响应速度和较高的吞吐量。因此缓存被誉为高并发系统的三大保护利器之一缓存、限流、降级能够显著提升系统访问速度和并发用户数。在一次用户请求的路径中数据通常会经过多个缓存节点。这些节点包括浏览器缓存、CDN节点缓存、网关代理缓存以及在各业务系统内常用的本地缓存和分布式缓存等。每个缓存节点都承担着特定的作用以减少数据源的访问压力提高数据的访问速度。我们聚焦在服务端开发时其主要包括本地缓存和分布式缓存两部分。一本地缓存对于单机应用或数据量较小的场景使用本地缓存是一个高效且简单的解决方案。利用HashMap或Guava Cache等工具可以轻松实现一个简单而快速的本地缓存。本地缓存的主要优点是速度快因为它直接在应用进程内存中存储数据避免了网络开销。然而本地缓存也有其局限性。由于数据存储在本地内存中当应用部署在多台服务器上时本地缓存的数据一致性和同步问题将会变得复杂。此外本地缓存受限于单台服务器的内存容量无法处理大规模数据。二分布式缓存对于需要处理大量数据和高并发请求的分布式系统分布式缓存是必不可少的。常用的分布式缓存解决方案包括 Redis、Tair 等。分布式缓存通过将数据存储在独立的缓存服务器上并提供高效的访问接口极大地提升了数据的访问速度和系统的伸缩性。二、缓存更新模式分析通过将缓存部署在数据库前面可以有效地抵挡大量的数据查询请求直接减轻数据库的负载提高系统的响应速度。然而缓存的引入也带来了数据一致性和缓存更新的问题。为了应对这些挑战开发中常用几种缓存更新模式Cache Aside Pattern旁路缓存模式Read/Write Through Pattern读写穿透模式Write Behind Caching Pattern异步写缓存模式一Cache Aside Pattern旁路缓存模式Cache Aside Pattern旁路缓存模式是一种常见且实用的缓存管理模式特别适用于需要在高并发系统中提升读取效率的场景。该模式没有单独的缓存维护组件而是由应用程序负责管理缓存和数据库之间的数据一致性。读操作流程在 Cache Aside 模式中对于读请求的处理流程如下请求读取数据应用程序首先尝试从缓存中读取数据。缓存命中如果缓存中存在请求的数据则直接返回缓存中的数据。缓存未命中如果缓存中不存在请求的数据应用程序则从数据库中查询数据。更新缓存从数据库中读取到数据后应用程序将数据写入缓存以便下次相同的读请求可以直接从缓存中获取。返回数据最后应用程序将从数据库中查询到的数据返回给请求方。写操作流程对于写请求的处理流程如下更新数据库应用程序首先执行对数据库的写操作确保数据的持久化和一致性。失效缓存成功更新数据库后应用程序将对应的缓存条目标记为失效或者直接删除以便下次读取时强制从数据库重新加载最新数据。流程问题思考问题1为什么不是先删缓存再更新数据库这种做法会引发并发访问下的数据一致性问题即脏数据的产生。具体来说假设同时存在并发的读写请求写请求A删除缓存写请求A首先删除了缓存中的数据并且成功删除。读请求B查询缓存未命中此时读请求B发起了查询操作发现缓存中不存在数据因此从数据库中查询数据。读请求B获取旧数据并写入缓存读请求B从数据库中获取了旧数据并将旧数据写入了缓存中。写请求A更新数据库写请求A继续执行数据库更新操作将新数据写入数据库中。在这种情况下缓存中的数据变成了旧数据而数据库中已经更新为新数据。因此后续从缓存中读取的数据将是旧的导致数据的不一致性问题。这种不一致可能会一直持续直到缓存中的旧数据过期或被替换为新数据。问题2为什么更新操作是将cache失效而不是更新这种情况会造成2方面的问题同时2个并发的写请求时可能会导致脏数据违背数据懒加载。并发写请求可能导致脏数据写请求A先更新了数据库。之后写请求B成功更新了数据库并成功更新了缓存。写请求A最后更新了缓存此时写请求A的数据已经是脏数据造成了不一致并且会一致脏下去。违背数据懒加载的原则某些缓存值可能需要经过复杂的计算才能得出例如缓存的结果是从数据库中查询并经过计算得出的。如果每次更新数据时都直接更新缓存即使后续在一段时间内并没有读取该缓存数据仍然进行了不必要的计算。相反采用失效缓存的策略即先更新数据库后失效缓存可以保证数据的一致性并且在需要数据时再重新计算缓存值避免了不必要的计算消耗符合数据懒加载的原则。综上所述选择失效缓存而不是直接更新缓存可以有效避免并发写操作导致的数据不一致性问题并符合数据懒加载的设计原则提高了系统的性能和可维护性。Cache Aside Pattern模式不一致问题的发生实际上先更新db再失效cache这种模式理论上也可能出现问题只是相对于以上的更新顺序出现不一致的几率会更小。读请求A首先读取缓存未命中这个时候去读数据库成功查询到数据。写请求B进来更新数据库成功并删除缓存的数据成功。最后请求A再将查询的数据写入到缓存中而此时请求A写入的数据已经是脏数据造成了数据不一致。之所以建议用这种更新顺序因为理论上造成不一致的几率会比较小要达到不一致需要读请求要先与写请求查询然后后与写请求返回通常来说数据库的查询的耗时会小于数据库写入的耗时所以这种问题出现概率会比较小。二Read/Write Through Pattern读写穿透模式Cache Aside Pattern模式中由应用方维护数据库和缓存的读写导致应用方数据库和缓存的维护设计侵入代码数据层的耦合增大代码复杂性增加。而Read/Write Through Pattern模式弥补了这一问题调用方无需管理缓存和数据库调用通过在设计中多抽象出一层缓存管理组件来负责和缓存和数据库读写维护并且缓存和数据库的读写维护是同步的。调用方直接和缓存管理组件打交道缓存和数据库对调用方是透明的视为一个整体。通过分离出缓存管理组件解耦业务代码。Read Through应用向缓存管理组件发送查询请求由缓存管理组件查询缓存若缓存未命中查询数据库并将查询的数据写入缓存并返回给应用。Write ThroughWrite Through 套路和Read Through相仿当更新数据的时候将请求发送给缓存管理组件由缓存管理组件同步更数据库和缓存数据。三Write Behind Caching Pattern异步写缓存模式Write Behind模式和Write Through模式整个架构是一样的最核心的一点在于Write Through在缓存数据库中的更新是同步的而Write Behind是异步的。每次的请求写都是直接更新缓存然后就成功返回并没有同步把数据更新到数据库。而把更新到数据库的过程称为flush触发flush的条件可自定义如定时或达到一定容量阈值时进行flush操作。并且可以实现批量写合并写等策略也有效减少了更新数据的频率这种模式最大的好处就是读写响应非常快吞吐量也会明显提升因为都是跟cache交互。当然这种模式也有其他的问题。例如数据不是强一致性的因为选择了把最新的数据放在缓存里如果缓存在flush到数据库之前宕机了就会丢失数据另外实现也是最复杂的。四几种模式对比模式优点缺点Cache Aside简单直观易于实现适用于读多写少的场景可能出现数据一致性问题因为读写操作分开处理代码侵入大需要调用方维护缓存和db的更新逻辑Read/Write Through引入缓存管理组件缓存和数据库的维护对应用方式透明的应用代码入侵小逻辑更清晰引入缓存管理组件实现更复杂Write Behind Caching读写直接和缓存打交道异步批量更新数据库性能最好缓存和数据库对应用方透明实现最复杂数据丢失的风险一致性最弱三、缓存一致性分析一一致性问题根因在实际应用中缓存引入后确实会带来一致性问题特别是在分布式环境中使用分布式缓存时更为突出。这些问题通常涉及业务层面和系统层面业务层面引起的一致性问题在业务层面缓存和数据库的一致性问题主要由以下因素引起缓存更新策略不同的缓存更新策略会影响到数据一致性。例如在 Cache Aside Pattern 中先更新数据库再失效缓存或者先删除缓存再更新数据库都有可能在高并发情况下导致数据不一致的情况发生。选择合适的更新策略可以降低数据不一致的概率但并不能完全消除问题。并发访问控制缺乏有效的并发访问控制机制可能导致并发写操作造成的数据竞争和不一致。例如在多个请求同时更新同一条数据时如果没有合适的并发控制可能会导致最终数据的不确定性或者错误。事务边界处理在涉及到事务的复杂操作中将缓存的更新与数据库操作放在同一个事务中可能会增加事务的粒度和持有数据库连接的时间从而降低系统的性能。因此有时候必须将缓存更新与数据库更新分开处理但这会引入数据一致性的挑战。系统层面引起的一致性问题在系统层面主要的一致性问题源于分布式环境中单个节点或者整个系统的失败或异常情况缓存服务的故障如果使用分布式缓存其中一台缓存节点的故障可能会导致部分数据不可用或者不一致。尤其是在缓存更新时如果更新请求发送到的缓存节点故障或者网络分区更新可能无法正常完成从而导致缓存与数据库数据的不一致。网络分区和延迟分布式系统中的网络分区和网络延迟可能导致缓存更新操作的延迟或失败进而影响数据的一致性。例如数据写入缓存成功但是由于网络延迟或者分区问题导致数据库的更新操作未能及时完成。分布式事务的实现如果应用程序需要在分布式环境中实现跨多个数据存储的事务例如同时更新数据库和缓存需要确保事务的原子性和一致性。分布式事务的复杂性和性能开销可能会限制其适用性。二强一致性解决方案强一致性在分布式系统中确实能够保证数据的实时一致性但其带来的性能开销常常是系统设计中需要权衡的重要因素。一般采用采用强一致性协议或将并行请求转为串行化。采用强一致性协议强一致性协议确保在任何时间点系统中所有副本的数据都保持一致。主要的强一致性协议如两阶段提交2PC、三阶段提交3PC等它们通过同步协调多个节点或服务的状态来保证事务的原子性和一致性。并行请求转为串行化为了确保强一致性有时系统会将并行执行的请求转换为串行化处理即一次只处理一个请求等待前一个请求处理完成后再处理下一个请求。这种方式可以确保事务的顺序执行和数据的强一致性但也明显地增加了系统的响应时间和处理能力上限。综合考虑在实际应用中选择是否采用强一致性协议或者将并行请求转为串行化需要根据具体的业务需求、性能要求和系统架构来进行权衡和决策。通常情况下强一致性适用于对数据实时性要求极高的场景如金融交易系统而对于需要更高吞吐量和较低延迟的系统可能会选择牺牲一些一致性来换取性能和可用性的提升采用最终一致性策略。三最终一致性解决方案最终一致性是指系统保证在一段时间内所有数据副本最终达到一致状态即使在某些时间段内可能存在数据不一致的情况但最终会达到一致状态。在互联网场景下这种方式通常是可接受的并且具有较好的可扩展性和性能。重试机制应用更新数据库若这一步就失败那么更新事务失败回退。应用更新缓存失败将失败的数据写入mq消费mq得到失败的数据重试删除缓存整个过程考虑了数据库写入成功缓存因系统故障等写入失败导致数据库和缓存此时数据不一致将失败的数据写入mq监听mq重试删除缓存来到达最终一致性。缺点是整个重试写入的维护都在业务代码中代码侵入性比较高。因此可以考虑一下方式引入databus订阅数据更新binlog解耦缓存更新过程。重试binlog应用更新数据库binlog日志同步databus。缓存管理组件订阅binlog并删除缓存失败则将缓存key写入mq。缓存管理组件订阅mq重试删除缓存。通过引入databus和缓存管理组件将缓存更新的维护和业务代码解耦。另一个原因是现在的数据库通常是主从架构来提升整体的查询qps因数据库主从同步的延迟删除缓存后如果此时从数据库还未同步完成新来的请求发现缓存失效了从从库里查询了已经过期的数据放到缓存中也会造成数据的不一致。而通过订阅binlog的同步的延迟性使删除缓存的时序延后进一步降低不一致的几率。综合考虑缓存的引入在提升系统性能方面有着显著的效果但也带来了数据一致性的问题。在实际设计中需要根据具体的业务需求、数据特性和系统架构综合考虑缓存策略和过期时间设置以在高性能和一致性之间找到最佳的平衡点。通过灵活运用最终一致性策略、主动刷新、缓存预热等技术手段可以在保证系统高性能的同时尽量减少数据不一致的风险。四、缓存热门问题分析和解决在高并发场景下缓存作为前置查询机制显著减轻了数据库的压力提高了系统性能。然而这也带来了缓存失效、增加回溯率等风险。常见的问题包括缓存穿透、缓存雪崩、热Key和大Key等。这些问题如果不加以处理会影响系统的稳定性和性能。因此采用有效的缓存策略如缓存空结果、布隆过滤器、缓存过期时间随机化、多级缓存等对于保障系统在高并发情况下的可靠性至关重要。接下来我们将详细探讨这些常见缓存问题及其应对策略。一缓存穿透问题描述缓存的设计通常旨在提高系统的查询效率通过减少对数据库的直接访问来缓解压力。然而当大量非法请求查询数据库中不存在的数据时既无法命中缓存也无法从数据库中获取结果这种情况被称为缓存穿透。缓存穿透使缓存形同虚设缓存命中率降为零每次请求都直接穿过缓存到达数据库。在这种情况下数据库承受了所有请求的压力缓存未能发挥其应有的作用。如果有人恶意攻击系统通过大量不存在的key请求接口这些请求会直接穿透缓存并打到数据库上可能导致数据库负载过重甚至宕机。解决策略分析详细解决方案可见高并发场景下的缓存穿透问题探析与应对策略-CSDN博客二缓存雪崩问题描述缓存层挡在db层前面抗住了非常多的流量在分布式系统中“everything will fails”缓存作为一种资源当cache crash后流量集中涌入下层数据库称之为缓存雪崩。造成这种问题通常有2种原因业务层面大量的缓存key同时失效失效请求全部回源到数据库造成数据库压力过大崩溃。系统层面缓存服务宕机。解决策略分析详细解决方案可见高并发场景下的缓存雪崩探析与应对策略-CSDN博客三缓存击穿问题描述在缓存系统中有些数据可能会被频繁访问这些数据被称为热点数据。为了保证缓存的有效性缓存通常会设置一个过期时间。然而当一个热点数据的缓存失效时所有对该数据的请求会同时到达数据库。这种情况会导致以下问题数据库压力大当大量请求同时涌向数据库时数据库的负载会瞬间增加可能导致数据库性能下降甚至崩溃。无效的重复查询所有请求都试图从数据库中读取相同的数据并更新缓存这种重复的查询是无效的因为只需要一次查询结果就能满足所有请求。缓存击穿是由于热点数据的缓存失效导致的数据库压力过大问题。为了解决这个问题可以采用互斥锁、永不过期和提前预热缓存等方法。这些方法各有优缺点可以根据具体业务场景选择合适的解决方案以确保系统在高并发访问下的稳定性和高性能。解决策略分析详细解决方案可见高并发场景下的缓存击穿问题探析与应对策略-CSDN博客四热点key问题问题描述热点 key 问题是指某些数据的访问量非常高超过了缓存服务器的处理能力。这种现象在电商促销、社交媒体热点等场景中特别常见。热点 key 问题主要有以下几个方面流量集中达到物理网卡上限当大量请求集中到某个热点 key 时这些请求会被路由到相同的缓存服务器。随着流量增加服务器的物理网卡可能达到带宽上限无法再处理更多请求。请求过多缓存分片服务被打垮缓存系统通常使用分片机制来分担负载。然而热点 key 的访问量可能过高单个分片无法处理导致该分片服务被打垮。缓存分片打垮重建再次被打垮引起业务雪崩当某个缓存分片被打垮后系统可能会尝试重建该分片。然而重建过程中的负载再次集中到该分片上导致分片再次被打垮形成恶性循环引起业务系统的雪崩。对于其发现机制可见优化分布式系统性能热key识别与实战解决方案-CSDN博客详细解决方案可见高并发场景下的热点key问题探析与应对策略五大key问题问题描述大 Key 是指在缓存系统中某些 Key 对应的值Value存储的数据量非常大大 Key 可能会导致一系列性能问题和系统不稳定性响应超时由于 Redis 是单线程的如果某个 Key 的 Value 很大在进行GET或SET操作时会占用 Redis 的单线程导致其他请求被阻塞从而引发响应超时。另外集合类型如 Set、List、Hash、ZSet的元素较多时删除或读取这些大集合的时间复杂度为 O(n)会严重阻塞 Redis 进程导致应用服务的超时和崩溃。数据倾斜大 Key 会导致 Redis 集群中某些节点存储的数据量远大于其他节点从而引起数据分布不均衡的问题。集群负载不均衡会导致某些节点的内存和计算资源紧张降低整体性能。大key的认定缓存系统中一般大 Key 的定义如下String 类型Value 大于 10K 为“大” KeyValue 大于 100K 为“超大” KeySet、List、Hash、ZSet 等集合类型元素个数超过 1000 为“大” Key元素个数超过 10000 为“超大” Key解决策略分析详细解决方案可见高并发场景下的大 Key 问题及应对策略-CSDN博客五、复杂工程应对本地缓存双缓存方案一本地缓存双缓存方案架构当设计缓存方案时可采用了本地缓存和双缓存策略应对平台的高流量压力和对缓存组件高度依赖的情况。本地缓存本地缓存被用于存储那些数据量小、频繁访问且变更频率较低的数据例如API信息和业务基础数据。这些数据通常不会经常变更因此可以在本地缓存中实现快速访问和响应减少对分布式缓存的请求次数从而提升系统性能和响应速度。双缓存方案尽管分布式缓存系统Redis、Squirrel、Tair等已经实现了高可用性的建设但考虑到实际使用过程中偶尔会因为单一缓存不稳定而导致的业务报警所以可以引入了双缓存方案。在这种方案中Tair和Redis互为主备可以随时切换其角色。主缓存用于正常运行时的数据访问备用缓存则作为故障恢复或负载均衡的备选。优势与实施细节提高系统可用性双缓存方案通过备用缓存的存在确保即使主缓存出现故障或性能问题系统仍能继续运行。降低对缓存的单一依赖避免了单一缓存带来的风险如性能瓶颈或故障导致的服务中断。实时切换能力可以根据监控系统或自动化策略在发生问题时快速切换到备用缓存最大限度地减少业务影响和服务下线时间。通过这种组合的本地缓存和双缓存方案我们能够在保证高性能和高可用性的同时有效管理和优化平台的整体缓存策略以应对不断增长的流量和业务需求。二策略层设计在缓存架构中策略层主要负责实现降级、双缓存熔断自动切换或人工切换以及保证最终一致性的兜底策略和及时报警的监控策略。降级策略降级策略是为了在缓存出现问题或性能下降时保证系统的稳定性和可用性自动切换到备用缓存当主缓存出现熔断或故障时系统会自动切换到备用缓存以保证数据访问的连续性。人工切换运维人员可以通过手动开关将请求切换到备用缓存从而快速响应缓存故障或性能问题。直接查询数据库当所有缓存失效或不可用时降级业务可以直接向数据库发起查询确保业务的正常运行。兜底策略兜底策略用于保证缓存与数据库数据的最终一致性数据订阅与同步引入数据总线如Databus订阅数据库表的数据变化。当数据库数据发生变更时及时更新对应的缓存数据确保缓存的数据与数据库保持一致性。定期校对与刷新定时任务会周期性地检查缓存和数据库数据的一致性。如果发现缓存更新失败或数据总线组件异常系统会通过刷新缓存来修复不一致的数据状态。报警策略报警策略用于监控和及时响应缓存运行时的异常情况实时监控运行状态系统会持续监控双缓存的运行状态包括缓存命中率、响应时间、缓存失效率等关键指标。异常报警通知一旦监控到缓存运行状态异常如缓存熔断、性能下降、数据不一致等系统会立即触发报警通知通知相关的运维团队或负责人员进行及时处理。通过精心设计和实施这些策略能够确保缓存系统在面对高流量和复杂业务场景时保持高可用性、高性能并且能够及时响应和修复潜在的故障和数据一致性问题。三缓存查询流程采用灵活的查询策略以应对不同的运行情况和故障场景保证系统的稳定性和高可用性。1. 主备缓存切换主缓存优先正常情况下系统优先使用主缓存来响应数据请求以保证快速的访问速度和低延迟。熔断策略当主缓存频繁失败或命中率低于设定阈值时系统会触发熔断机制。此时自动切换到备用缓存来维护数据访问的连续性和稳定性。手动切换运维团队可以通过操作开关手动将数据请求切换到备用缓存以应对主缓存故障或性能下降的紧急情况。2. 缓存异常处理缓存异常处理流程当主备缓存均异常或缓存未命中时系统会自动触发查询数据库的流程。数据库异步加载查询数据库时系统会异步加载数据到缓存中不要求即时成功。这种方式保证了即使数据库访问不稳定或数据丢失系统仍能继续提供服务避免因缓存问题而导致的服务中断或性能下降。3. 异常情况处理数据加载成功性异步加载数据库数据到缓存中的过程中系统不强制要求每次加载都成功。如果加载失败系统会在后续的重试过程中尝试修复并补充缓存数据。四缓存更新策略流程采了多层次的更新策略来处理缓存更新失败的情况。1. 数据总线重试机制更新失败通知任何一个缓存Tair或Squirrel的更新失败时都会通知数据总线DataBus标记该次更新为失败。重试机制DataBus会自动进行重试确保最终的数据一致性。重试机制确保即使在初次更新失败的情况下数据总线仍会不断尝试直至更新成功。2. 双缓存更新策略允许部分更新成功在更新缓存时允许Tair和Redis中的一个缓存更新成功。如果其中一个缓存更新失败系统会标记该次更新为失败并触发重试机制。数据一致性保证当某个缓存不可用时系统保证更新成功的缓存数据与数据库数据保持一致。通过这种策略即使部分缓存服务出现故障系统仍能保证数据的一致性和可用性。3. 自动校对任务定期自动校对系统会在每天的低峰期运行自动校对任务检查并修正缓存与数据库之间的差异。此任务可以确保在长时间运行后缓存数据仍能与数据库数据保持一致。手动触发校对除了自动校对任务运维团队还可以手动触发校对任务以应对紧急情况或特殊需求。通知机制每次校对任务完成后系统会发送通知告知任务的执行情况和结果确保相关人员及时了解数据状态。无论是缓存更新失败、部分缓存不可用还是需要定期校对数据我们都能通过有效的机制和流程来保证系统的稳定运行和数据的可靠性。六、总结缓存技术在现代分布式系统中至关重要不仅提升了系统性能还减轻了后端数据库的压力。然而缓存系统也面临着诸多挑战如缓存穿透、缓存雪崩、缓存击穿和热点key问题。通过多种策略的综合应用包括本地缓存、双缓存方案、多级缓存、多副本、热点key拆分和动态分散等可以有效应对这些问题。本地缓存适用于频繁访问且少变更的数据如API信息和业务基础信息而双缓存方案则通过Tair和Squirrel的组合实现主备缓存切换和高可用性。在缓存更新上采用旁路缓存模式、读写穿透模式和异步写缓存模式等方法确保数据一致性和系统稳定性。策略层设计中降级策略、兜底策略和报警策略进一步保障了缓存系统的可靠性。综合来看通过合理设计和灵活应用缓存技术可以显著提升分布式系统的性能和稳定性为业务的高效运行提供强有力的支持。
全面击破工程级复杂缓存难题
目录一、走进业务中的缓存一本地缓存二分布式缓存二、缓存更新模式分析一Cache Aside Pattern旁路缓存模式读操作流程写操作流程流程问题思考问题1为什么不是先删缓存再更新数据库问题2为什么更新操作是将cache失效而不是更新Cache Aside Pattern模式不一致问题的发生二Read/Write Through Pattern读写穿透模式Read ThroughWrite Through三Write Behind Caching Pattern异步写缓存模式四几种模式对比三、缓存一致性分析一一致性问题根因业务层面引起的一致性问题系统层面引起的一致性问题二强一致性解决方案采用强一致性协议并行请求转为串行化综合考虑三最终一致性解决方案重试机制重试binlog综合考虑四、缓存热门问题分析和解决一缓存穿透问题描述解决策略分析二缓存雪崩问题描述解决策略分析三缓存击穿问题描述解决策略分析四热点key问题问题描述五大key问题问题描述大key的认定解决策略分析五、复杂工程应对本地缓存双缓存方案一本地缓存双缓存方案架构本地缓存双缓存方案优势与实施细节二策略层设计降级策略兜底策略报警策略三缓存查询流程1. 主备缓存切换2. 缓存异常处理3. 异常情况处理四缓存更新策略流程1. 数据总线重试机制2. 双缓存更新策略3. 自动校对任务六、总结干货分享感谢您的阅读在日常生活中大家都会在家里储备一些粮食比如米面油。但是你不会在初期就囤积大量的食物比如说一口气买半年甚至一年的粮食。如果你住的地方附近有便利的超市随时可以买到新鲜的食物且你目前的家庭成员不多消耗量不大那么大规模囤粮不仅占用储物空间还可能造成浪费因为食品有保质期。只有在你预计家里即将迎来很多客人或者附近的超市要关门维修几个月时大规模囤粮才是明智之举。说这个例子主要还是想提缓存的必要性虽然缓存技术可以大幅提升系统性能但在没有明确需要时应该慎重考虑是否使用缓存。如果在系统初期或者短期内直接使用数据库就能满足业务需求那么最好先不要引入缓存。缓存的引入应该是在系统确实需要提升性能或者有其他明确原因的时候。历史基础问题回顾具体内容基础对应详细知识和解法链接探析缓存穿透问题高并发场景下的缓存穿透问题探析与应对策略探析缓存雪崩高并发场景下的缓存雪崩探析与应对策略-CSDN博客探析缓存击穿高并发场景下的缓存击穿问题探析与应对策略-CSDN博客热key识别与实战解决优化分布式系统性能热key识别与实战解决方案_热key识别框架-CSDN博客探析缓存热点key高并发场景下的热点key问题探析与应对策略_热点账户高并发解决方案-CSDN博客探析大 Key 问题高并发场景下的大 Key 问题及应对策略-CSDN博客一、走进业务中的缓存在现代高并发系统中缓存作为一种关键技术被广泛应用于各种场景中以提升性能和系统稳定性。缓存的存在使得系统能够在面对大量请求时依然保持高效的响应速度和较高的吞吐量。因此缓存被誉为高并发系统的三大保护利器之一缓存、限流、降级能够显著提升系统访问速度和并发用户数。在一次用户请求的路径中数据通常会经过多个缓存节点。这些节点包括浏览器缓存、CDN节点缓存、网关代理缓存以及在各业务系统内常用的本地缓存和分布式缓存等。每个缓存节点都承担着特定的作用以减少数据源的访问压力提高数据的访问速度。我们聚焦在服务端开发时其主要包括本地缓存和分布式缓存两部分。一本地缓存对于单机应用或数据量较小的场景使用本地缓存是一个高效且简单的解决方案。利用HashMap或Guava Cache等工具可以轻松实现一个简单而快速的本地缓存。本地缓存的主要优点是速度快因为它直接在应用进程内存中存储数据避免了网络开销。然而本地缓存也有其局限性。由于数据存储在本地内存中当应用部署在多台服务器上时本地缓存的数据一致性和同步问题将会变得复杂。此外本地缓存受限于单台服务器的内存容量无法处理大规模数据。二分布式缓存对于需要处理大量数据和高并发请求的分布式系统分布式缓存是必不可少的。常用的分布式缓存解决方案包括 Redis、Tair 等。分布式缓存通过将数据存储在独立的缓存服务器上并提供高效的访问接口极大地提升了数据的访问速度和系统的伸缩性。二、缓存更新模式分析通过将缓存部署在数据库前面可以有效地抵挡大量的数据查询请求直接减轻数据库的负载提高系统的响应速度。然而缓存的引入也带来了数据一致性和缓存更新的问题。为了应对这些挑战开发中常用几种缓存更新模式Cache Aside Pattern旁路缓存模式Read/Write Through Pattern读写穿透模式Write Behind Caching Pattern异步写缓存模式一Cache Aside Pattern旁路缓存模式Cache Aside Pattern旁路缓存模式是一种常见且实用的缓存管理模式特别适用于需要在高并发系统中提升读取效率的场景。该模式没有单独的缓存维护组件而是由应用程序负责管理缓存和数据库之间的数据一致性。读操作流程在 Cache Aside 模式中对于读请求的处理流程如下请求读取数据应用程序首先尝试从缓存中读取数据。缓存命中如果缓存中存在请求的数据则直接返回缓存中的数据。缓存未命中如果缓存中不存在请求的数据应用程序则从数据库中查询数据。更新缓存从数据库中读取到数据后应用程序将数据写入缓存以便下次相同的读请求可以直接从缓存中获取。返回数据最后应用程序将从数据库中查询到的数据返回给请求方。写操作流程对于写请求的处理流程如下更新数据库应用程序首先执行对数据库的写操作确保数据的持久化和一致性。失效缓存成功更新数据库后应用程序将对应的缓存条目标记为失效或者直接删除以便下次读取时强制从数据库重新加载最新数据。流程问题思考问题1为什么不是先删缓存再更新数据库这种做法会引发并发访问下的数据一致性问题即脏数据的产生。具体来说假设同时存在并发的读写请求写请求A删除缓存写请求A首先删除了缓存中的数据并且成功删除。读请求B查询缓存未命中此时读请求B发起了查询操作发现缓存中不存在数据因此从数据库中查询数据。读请求B获取旧数据并写入缓存读请求B从数据库中获取了旧数据并将旧数据写入了缓存中。写请求A更新数据库写请求A继续执行数据库更新操作将新数据写入数据库中。在这种情况下缓存中的数据变成了旧数据而数据库中已经更新为新数据。因此后续从缓存中读取的数据将是旧的导致数据的不一致性问题。这种不一致可能会一直持续直到缓存中的旧数据过期或被替换为新数据。问题2为什么更新操作是将cache失效而不是更新这种情况会造成2方面的问题同时2个并发的写请求时可能会导致脏数据违背数据懒加载。并发写请求可能导致脏数据写请求A先更新了数据库。之后写请求B成功更新了数据库并成功更新了缓存。写请求A最后更新了缓存此时写请求A的数据已经是脏数据造成了不一致并且会一致脏下去。违背数据懒加载的原则某些缓存值可能需要经过复杂的计算才能得出例如缓存的结果是从数据库中查询并经过计算得出的。如果每次更新数据时都直接更新缓存即使后续在一段时间内并没有读取该缓存数据仍然进行了不必要的计算。相反采用失效缓存的策略即先更新数据库后失效缓存可以保证数据的一致性并且在需要数据时再重新计算缓存值避免了不必要的计算消耗符合数据懒加载的原则。综上所述选择失效缓存而不是直接更新缓存可以有效避免并发写操作导致的数据不一致性问题并符合数据懒加载的设计原则提高了系统的性能和可维护性。Cache Aside Pattern模式不一致问题的发生实际上先更新db再失效cache这种模式理论上也可能出现问题只是相对于以上的更新顺序出现不一致的几率会更小。读请求A首先读取缓存未命中这个时候去读数据库成功查询到数据。写请求B进来更新数据库成功并删除缓存的数据成功。最后请求A再将查询的数据写入到缓存中而此时请求A写入的数据已经是脏数据造成了数据不一致。之所以建议用这种更新顺序因为理论上造成不一致的几率会比较小要达到不一致需要读请求要先与写请求查询然后后与写请求返回通常来说数据库的查询的耗时会小于数据库写入的耗时所以这种问题出现概率会比较小。二Read/Write Through Pattern读写穿透模式Cache Aside Pattern模式中由应用方维护数据库和缓存的读写导致应用方数据库和缓存的维护设计侵入代码数据层的耦合增大代码复杂性增加。而Read/Write Through Pattern模式弥补了这一问题调用方无需管理缓存和数据库调用通过在设计中多抽象出一层缓存管理组件来负责和缓存和数据库读写维护并且缓存和数据库的读写维护是同步的。调用方直接和缓存管理组件打交道缓存和数据库对调用方是透明的视为一个整体。通过分离出缓存管理组件解耦业务代码。Read Through应用向缓存管理组件发送查询请求由缓存管理组件查询缓存若缓存未命中查询数据库并将查询的数据写入缓存并返回给应用。Write ThroughWrite Through 套路和Read Through相仿当更新数据的时候将请求发送给缓存管理组件由缓存管理组件同步更数据库和缓存数据。三Write Behind Caching Pattern异步写缓存模式Write Behind模式和Write Through模式整个架构是一样的最核心的一点在于Write Through在缓存数据库中的更新是同步的而Write Behind是异步的。每次的请求写都是直接更新缓存然后就成功返回并没有同步把数据更新到数据库。而把更新到数据库的过程称为flush触发flush的条件可自定义如定时或达到一定容量阈值时进行flush操作。并且可以实现批量写合并写等策略也有效减少了更新数据的频率这种模式最大的好处就是读写响应非常快吞吐量也会明显提升因为都是跟cache交互。当然这种模式也有其他的问题。例如数据不是强一致性的因为选择了把最新的数据放在缓存里如果缓存在flush到数据库之前宕机了就会丢失数据另外实现也是最复杂的。四几种模式对比模式优点缺点Cache Aside简单直观易于实现适用于读多写少的场景可能出现数据一致性问题因为读写操作分开处理代码侵入大需要调用方维护缓存和db的更新逻辑Read/Write Through引入缓存管理组件缓存和数据库的维护对应用方式透明的应用代码入侵小逻辑更清晰引入缓存管理组件实现更复杂Write Behind Caching读写直接和缓存打交道异步批量更新数据库性能最好缓存和数据库对应用方透明实现最复杂数据丢失的风险一致性最弱三、缓存一致性分析一一致性问题根因在实际应用中缓存引入后确实会带来一致性问题特别是在分布式环境中使用分布式缓存时更为突出。这些问题通常涉及业务层面和系统层面业务层面引起的一致性问题在业务层面缓存和数据库的一致性问题主要由以下因素引起缓存更新策略不同的缓存更新策略会影响到数据一致性。例如在 Cache Aside Pattern 中先更新数据库再失效缓存或者先删除缓存再更新数据库都有可能在高并发情况下导致数据不一致的情况发生。选择合适的更新策略可以降低数据不一致的概率但并不能完全消除问题。并发访问控制缺乏有效的并发访问控制机制可能导致并发写操作造成的数据竞争和不一致。例如在多个请求同时更新同一条数据时如果没有合适的并发控制可能会导致最终数据的不确定性或者错误。事务边界处理在涉及到事务的复杂操作中将缓存的更新与数据库操作放在同一个事务中可能会增加事务的粒度和持有数据库连接的时间从而降低系统的性能。因此有时候必须将缓存更新与数据库更新分开处理但这会引入数据一致性的挑战。系统层面引起的一致性问题在系统层面主要的一致性问题源于分布式环境中单个节点或者整个系统的失败或异常情况缓存服务的故障如果使用分布式缓存其中一台缓存节点的故障可能会导致部分数据不可用或者不一致。尤其是在缓存更新时如果更新请求发送到的缓存节点故障或者网络分区更新可能无法正常完成从而导致缓存与数据库数据的不一致。网络分区和延迟分布式系统中的网络分区和网络延迟可能导致缓存更新操作的延迟或失败进而影响数据的一致性。例如数据写入缓存成功但是由于网络延迟或者分区问题导致数据库的更新操作未能及时完成。分布式事务的实现如果应用程序需要在分布式环境中实现跨多个数据存储的事务例如同时更新数据库和缓存需要确保事务的原子性和一致性。分布式事务的复杂性和性能开销可能会限制其适用性。二强一致性解决方案强一致性在分布式系统中确实能够保证数据的实时一致性但其带来的性能开销常常是系统设计中需要权衡的重要因素。一般采用采用强一致性协议或将并行请求转为串行化。采用强一致性协议强一致性协议确保在任何时间点系统中所有副本的数据都保持一致。主要的强一致性协议如两阶段提交2PC、三阶段提交3PC等它们通过同步协调多个节点或服务的状态来保证事务的原子性和一致性。并行请求转为串行化为了确保强一致性有时系统会将并行执行的请求转换为串行化处理即一次只处理一个请求等待前一个请求处理完成后再处理下一个请求。这种方式可以确保事务的顺序执行和数据的强一致性但也明显地增加了系统的响应时间和处理能力上限。综合考虑在实际应用中选择是否采用强一致性协议或者将并行请求转为串行化需要根据具体的业务需求、性能要求和系统架构来进行权衡和决策。通常情况下强一致性适用于对数据实时性要求极高的场景如金融交易系统而对于需要更高吞吐量和较低延迟的系统可能会选择牺牲一些一致性来换取性能和可用性的提升采用最终一致性策略。三最终一致性解决方案最终一致性是指系统保证在一段时间内所有数据副本最终达到一致状态即使在某些时间段内可能存在数据不一致的情况但最终会达到一致状态。在互联网场景下这种方式通常是可接受的并且具有较好的可扩展性和性能。重试机制应用更新数据库若这一步就失败那么更新事务失败回退。应用更新缓存失败将失败的数据写入mq消费mq得到失败的数据重试删除缓存整个过程考虑了数据库写入成功缓存因系统故障等写入失败导致数据库和缓存此时数据不一致将失败的数据写入mq监听mq重试删除缓存来到达最终一致性。缺点是整个重试写入的维护都在业务代码中代码侵入性比较高。因此可以考虑一下方式引入databus订阅数据更新binlog解耦缓存更新过程。重试binlog应用更新数据库binlog日志同步databus。缓存管理组件订阅binlog并删除缓存失败则将缓存key写入mq。缓存管理组件订阅mq重试删除缓存。通过引入databus和缓存管理组件将缓存更新的维护和业务代码解耦。另一个原因是现在的数据库通常是主从架构来提升整体的查询qps因数据库主从同步的延迟删除缓存后如果此时从数据库还未同步完成新来的请求发现缓存失效了从从库里查询了已经过期的数据放到缓存中也会造成数据的不一致。而通过订阅binlog的同步的延迟性使删除缓存的时序延后进一步降低不一致的几率。综合考虑缓存的引入在提升系统性能方面有着显著的效果但也带来了数据一致性的问题。在实际设计中需要根据具体的业务需求、数据特性和系统架构综合考虑缓存策略和过期时间设置以在高性能和一致性之间找到最佳的平衡点。通过灵活运用最终一致性策略、主动刷新、缓存预热等技术手段可以在保证系统高性能的同时尽量减少数据不一致的风险。四、缓存热门问题分析和解决在高并发场景下缓存作为前置查询机制显著减轻了数据库的压力提高了系统性能。然而这也带来了缓存失效、增加回溯率等风险。常见的问题包括缓存穿透、缓存雪崩、热Key和大Key等。这些问题如果不加以处理会影响系统的稳定性和性能。因此采用有效的缓存策略如缓存空结果、布隆过滤器、缓存过期时间随机化、多级缓存等对于保障系统在高并发情况下的可靠性至关重要。接下来我们将详细探讨这些常见缓存问题及其应对策略。一缓存穿透问题描述缓存的设计通常旨在提高系统的查询效率通过减少对数据库的直接访问来缓解压力。然而当大量非法请求查询数据库中不存在的数据时既无法命中缓存也无法从数据库中获取结果这种情况被称为缓存穿透。缓存穿透使缓存形同虚设缓存命中率降为零每次请求都直接穿过缓存到达数据库。在这种情况下数据库承受了所有请求的压力缓存未能发挥其应有的作用。如果有人恶意攻击系统通过大量不存在的key请求接口这些请求会直接穿透缓存并打到数据库上可能导致数据库负载过重甚至宕机。解决策略分析详细解决方案可见高并发场景下的缓存穿透问题探析与应对策略-CSDN博客二缓存雪崩问题描述缓存层挡在db层前面抗住了非常多的流量在分布式系统中“everything will fails”缓存作为一种资源当cache crash后流量集中涌入下层数据库称之为缓存雪崩。造成这种问题通常有2种原因业务层面大量的缓存key同时失效失效请求全部回源到数据库造成数据库压力过大崩溃。系统层面缓存服务宕机。解决策略分析详细解决方案可见高并发场景下的缓存雪崩探析与应对策略-CSDN博客三缓存击穿问题描述在缓存系统中有些数据可能会被频繁访问这些数据被称为热点数据。为了保证缓存的有效性缓存通常会设置一个过期时间。然而当一个热点数据的缓存失效时所有对该数据的请求会同时到达数据库。这种情况会导致以下问题数据库压力大当大量请求同时涌向数据库时数据库的负载会瞬间增加可能导致数据库性能下降甚至崩溃。无效的重复查询所有请求都试图从数据库中读取相同的数据并更新缓存这种重复的查询是无效的因为只需要一次查询结果就能满足所有请求。缓存击穿是由于热点数据的缓存失效导致的数据库压力过大问题。为了解决这个问题可以采用互斥锁、永不过期和提前预热缓存等方法。这些方法各有优缺点可以根据具体业务场景选择合适的解决方案以确保系统在高并发访问下的稳定性和高性能。解决策略分析详细解决方案可见高并发场景下的缓存击穿问题探析与应对策略-CSDN博客四热点key问题问题描述热点 key 问题是指某些数据的访问量非常高超过了缓存服务器的处理能力。这种现象在电商促销、社交媒体热点等场景中特别常见。热点 key 问题主要有以下几个方面流量集中达到物理网卡上限当大量请求集中到某个热点 key 时这些请求会被路由到相同的缓存服务器。随着流量增加服务器的物理网卡可能达到带宽上限无法再处理更多请求。请求过多缓存分片服务被打垮缓存系统通常使用分片机制来分担负载。然而热点 key 的访问量可能过高单个分片无法处理导致该分片服务被打垮。缓存分片打垮重建再次被打垮引起业务雪崩当某个缓存分片被打垮后系统可能会尝试重建该分片。然而重建过程中的负载再次集中到该分片上导致分片再次被打垮形成恶性循环引起业务系统的雪崩。对于其发现机制可见优化分布式系统性能热key识别与实战解决方案-CSDN博客详细解决方案可见高并发场景下的热点key问题探析与应对策略五大key问题问题描述大 Key 是指在缓存系统中某些 Key 对应的值Value存储的数据量非常大大 Key 可能会导致一系列性能问题和系统不稳定性响应超时由于 Redis 是单线程的如果某个 Key 的 Value 很大在进行GET或SET操作时会占用 Redis 的单线程导致其他请求被阻塞从而引发响应超时。另外集合类型如 Set、List、Hash、ZSet的元素较多时删除或读取这些大集合的时间复杂度为 O(n)会严重阻塞 Redis 进程导致应用服务的超时和崩溃。数据倾斜大 Key 会导致 Redis 集群中某些节点存储的数据量远大于其他节点从而引起数据分布不均衡的问题。集群负载不均衡会导致某些节点的内存和计算资源紧张降低整体性能。大key的认定缓存系统中一般大 Key 的定义如下String 类型Value 大于 10K 为“大” KeyValue 大于 100K 为“超大” KeySet、List、Hash、ZSet 等集合类型元素个数超过 1000 为“大” Key元素个数超过 10000 为“超大” Key解决策略分析详细解决方案可见高并发场景下的大 Key 问题及应对策略-CSDN博客五、复杂工程应对本地缓存双缓存方案一本地缓存双缓存方案架构当设计缓存方案时可采用了本地缓存和双缓存策略应对平台的高流量压力和对缓存组件高度依赖的情况。本地缓存本地缓存被用于存储那些数据量小、频繁访问且变更频率较低的数据例如API信息和业务基础数据。这些数据通常不会经常变更因此可以在本地缓存中实现快速访问和响应减少对分布式缓存的请求次数从而提升系统性能和响应速度。双缓存方案尽管分布式缓存系统Redis、Squirrel、Tair等已经实现了高可用性的建设但考虑到实际使用过程中偶尔会因为单一缓存不稳定而导致的业务报警所以可以引入了双缓存方案。在这种方案中Tair和Redis互为主备可以随时切换其角色。主缓存用于正常运行时的数据访问备用缓存则作为故障恢复或负载均衡的备选。优势与实施细节提高系统可用性双缓存方案通过备用缓存的存在确保即使主缓存出现故障或性能问题系统仍能继续运行。降低对缓存的单一依赖避免了单一缓存带来的风险如性能瓶颈或故障导致的服务中断。实时切换能力可以根据监控系统或自动化策略在发生问题时快速切换到备用缓存最大限度地减少业务影响和服务下线时间。通过这种组合的本地缓存和双缓存方案我们能够在保证高性能和高可用性的同时有效管理和优化平台的整体缓存策略以应对不断增长的流量和业务需求。二策略层设计在缓存架构中策略层主要负责实现降级、双缓存熔断自动切换或人工切换以及保证最终一致性的兜底策略和及时报警的监控策略。降级策略降级策略是为了在缓存出现问题或性能下降时保证系统的稳定性和可用性自动切换到备用缓存当主缓存出现熔断或故障时系统会自动切换到备用缓存以保证数据访问的连续性。人工切换运维人员可以通过手动开关将请求切换到备用缓存从而快速响应缓存故障或性能问题。直接查询数据库当所有缓存失效或不可用时降级业务可以直接向数据库发起查询确保业务的正常运行。兜底策略兜底策略用于保证缓存与数据库数据的最终一致性数据订阅与同步引入数据总线如Databus订阅数据库表的数据变化。当数据库数据发生变更时及时更新对应的缓存数据确保缓存的数据与数据库保持一致性。定期校对与刷新定时任务会周期性地检查缓存和数据库数据的一致性。如果发现缓存更新失败或数据总线组件异常系统会通过刷新缓存来修复不一致的数据状态。报警策略报警策略用于监控和及时响应缓存运行时的异常情况实时监控运行状态系统会持续监控双缓存的运行状态包括缓存命中率、响应时间、缓存失效率等关键指标。异常报警通知一旦监控到缓存运行状态异常如缓存熔断、性能下降、数据不一致等系统会立即触发报警通知通知相关的运维团队或负责人员进行及时处理。通过精心设计和实施这些策略能够确保缓存系统在面对高流量和复杂业务场景时保持高可用性、高性能并且能够及时响应和修复潜在的故障和数据一致性问题。三缓存查询流程采用灵活的查询策略以应对不同的运行情况和故障场景保证系统的稳定性和高可用性。1. 主备缓存切换主缓存优先正常情况下系统优先使用主缓存来响应数据请求以保证快速的访问速度和低延迟。熔断策略当主缓存频繁失败或命中率低于设定阈值时系统会触发熔断机制。此时自动切换到备用缓存来维护数据访问的连续性和稳定性。手动切换运维团队可以通过操作开关手动将数据请求切换到备用缓存以应对主缓存故障或性能下降的紧急情况。2. 缓存异常处理缓存异常处理流程当主备缓存均异常或缓存未命中时系统会自动触发查询数据库的流程。数据库异步加载查询数据库时系统会异步加载数据到缓存中不要求即时成功。这种方式保证了即使数据库访问不稳定或数据丢失系统仍能继续提供服务避免因缓存问题而导致的服务中断或性能下降。3. 异常情况处理数据加载成功性异步加载数据库数据到缓存中的过程中系统不强制要求每次加载都成功。如果加载失败系统会在后续的重试过程中尝试修复并补充缓存数据。四缓存更新策略流程采了多层次的更新策略来处理缓存更新失败的情况。1. 数据总线重试机制更新失败通知任何一个缓存Tair或Squirrel的更新失败时都会通知数据总线DataBus标记该次更新为失败。重试机制DataBus会自动进行重试确保最终的数据一致性。重试机制确保即使在初次更新失败的情况下数据总线仍会不断尝试直至更新成功。2. 双缓存更新策略允许部分更新成功在更新缓存时允许Tair和Redis中的一个缓存更新成功。如果其中一个缓存更新失败系统会标记该次更新为失败并触发重试机制。数据一致性保证当某个缓存不可用时系统保证更新成功的缓存数据与数据库数据保持一致。通过这种策略即使部分缓存服务出现故障系统仍能保证数据的一致性和可用性。3. 自动校对任务定期自动校对系统会在每天的低峰期运行自动校对任务检查并修正缓存与数据库之间的差异。此任务可以确保在长时间运行后缓存数据仍能与数据库数据保持一致。手动触发校对除了自动校对任务运维团队还可以手动触发校对任务以应对紧急情况或特殊需求。通知机制每次校对任务完成后系统会发送通知告知任务的执行情况和结果确保相关人员及时了解数据状态。无论是缓存更新失败、部分缓存不可用还是需要定期校对数据我们都能通过有效的机制和流程来保证系统的稳定运行和数据的可靠性。六、总结缓存技术在现代分布式系统中至关重要不仅提升了系统性能还减轻了后端数据库的压力。然而缓存系统也面临着诸多挑战如缓存穿透、缓存雪崩、缓存击穿和热点key问题。通过多种策略的综合应用包括本地缓存、双缓存方案、多级缓存、多副本、热点key拆分和动态分散等可以有效应对这些问题。本地缓存适用于频繁访问且少变更的数据如API信息和业务基础信息而双缓存方案则通过Tair和Squirrel的组合实现主备缓存切换和高可用性。在缓存更新上采用旁路缓存模式、读写穿透模式和异步写缓存模式等方法确保数据一致性和系统稳定性。策略层设计中降级策略、兜底策略和报警策略进一步保障了缓存系统的可靠性。综合来看通过合理设计和灵活应用缓存技术可以显著提升分布式系统的性能和稳定性为业务的高效运行提供强有力的支持。
