谈一谈服务器端缓存失效的应对方法经验总结

以缓存失效为例，查看此段伪代码：复制代码如下：localvalue=get_from_cache(key)ifnotvaluethen  value=query_db(sql)  set_to_cache(value，timeout＝100)endreturnvalue看起来没有问题，单元测试时也不会有异常。但是，在进行压力测试时，你会发现数据库的查询每100秒就会出现一次峰值。然而，当进行压力测试时，你会发现数据库的查询每100秒就会出现一次峰值。如果您的cache故障时间设置较长，则发现此问题的概率将降低。为什么会出现峰值？想象一下，在cache失败的那一刻，如果有1000个并发请求同时到达query_db(sql)这个函数会怎么样？是的，数据库中会有1000个请求。这是一场由缓存失效瞬间引起的风暴。它有一个英文名字，叫"dog-pileeffect"。怎么解决？自然的想法是在发现缓存失效后，添加一把锁来控制数据库的要求。具体细节，春哥在lua-resty-在lock的文档中做了详细的说明，我就不重复了，请看这里。多说一句，lua-resty-lock库本身已经为您完成了waitforlock的过程，在查看代码时需要注意这个细节。为了提高业务访问速度和业务阅读并发性，许多用户将在业务架构中引入缓存层。通过缓存的内存读取机制，将所有业务读取请求路由到缓存层，大大提高了业务读取性能。缓存中的数据不能持久。一旦缓存异常退出，内存中的数据就会丢失。因此，为了确保数据的完整性，业务更新数据将落在持久存储中，如DB。目前，云用户的业务结构一般如下图所示：在上图中，您可以看到用户的更新数据直接持续到DB，业务阅读请求直接要求缓存数据，因此业务需要解决缓存故障问题，即缓存中的数据故障问题。目前，解决业务缓存失效问题的解决方案一般是业务实现DB、缓存双写。缓存故障通过业务双写解决，存在以下问题：代码侵入性强，需要双写两个存储，任何DB数据变更，需要同时更新缓存，代码水平后期维护不高用户要求线程同步调用缓存，缓存强，缓存超时等异常，无法实现有效的重试，遇到异常返回系统错误、操作失败等信息，DB在用户体验用户请求线程中同步完成、缓存双写，变更要求链路长，访问延迟大，影响用户体验RDS数据订阅消费，轻松解决阿里巴巴缓存故障也遇到缓存故障问题，随着业务结构的不断调整和优化，我们沉淀了一套高可靠、优雅的缓存故障结构。也就是说，DB(如公共云上的RDS)的增量数据通过数据传输提供的数据订阅功能异步获取，并根据增量数据缓存失效。具体结构如下图所示：在此结构中，缓存更新过程如下：1。业务完成DB更新后，返回请求2。数据订阅通过日志分析实时分析和订阅DB增量更新数据。当DB发现数据更新时，将增量数据推送给下游消费者。3.一旦下游消费者业务收到增量更新数据，即调用消费线程进行缓存更新，完成整个缓存更新过程。从上述缓存故障过程可以看出，该缓存故障机制：1。更新路径短，延迟低：缓存故障为异步过程，业务更新DB完成后直接返回，无需关心缓存故障过程，整个更新路径短，更新延迟低。2.应用程序简单可靠：应用程序不需要实现复杂的双写逻辑，只需启动异步线程来监控增量数据，3.应用程序更新无性能消耗：因为数据订阅是通过分析DB的增量日志来获取增量数据的一种数据分发模式，为阿里巴巴云数据传输提供数据分发模式。缓存失效策略通过数据订阅实现，使业务更新更快，使业务逻辑更简单、更可靠。通过数据订阅实现的缓存故障策略使业务更新更快，使业务逻辑更简单、更可靠。数据订阅只是数据传输提供的一种传输方式。除了数据订阅，数据传输还提供多种传输能力，如实时数据同步和持续服务迁移。如果您需要了解更多关于数据传输的信息，请单击数据传输。

以上就是关于谈一谈服务器端缓存失效的应对方法经验总结的相关介绍，更多谈一谈服务器端缓存失效的应对方法经验总结相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对谈一谈服务器端缓存失效的应对方法经验总结有更深的了解和认识。