注册有好礼谈一谈服务器端缓存失效的应对方法经验总结
2020-12-29 11:00:18 阅读（160）
以缓存失效为例，查看此段伪代码：复制代码如下：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的增量日志来获取增量数据的一种数据分发模式，为阿里巴巴云数据传输提供数据分发模式。缓存失效策略通过数据订阅实现，使业务更新更快，使业务逻辑更简单、更可靠。通过数据订阅实现的缓存故障策略使业务更新更快，使业务逻辑更简单、更可靠。数据订阅只是数据传输提供的一种传输方式。除了数据订阅，数据传输还提供多种传输能力，如实时数据同步和持续服务迁移。如果您需要了解更多关于数据传输的信息，请单击数据传输。
推荐阅读
猜你喜欢
Copyright © 2004-2022 万商云集（成都）科技股份有限公司 版权所有
蜀ICP备12001963号-2
川公网安备 51010402000322号
快速找产品
扫码下载APP
全方位服务一触即达
关注万商云集
和10万中小企共成长
400-0033-166
8:30-18:00
