服务器端缓存失效的应对方法经验概括
发布时间：2022-07-22 15:20:21 所属栏目：经验 来源：互联网
导读：缓存失效情况举例 看下这个段伪代码： local value = get_from_cache(key) if not value then value = query_db(sql) set_to_cache(value， timeout ＝ 100) end return value 看上去没有问题，在单元测试情况下，也不会有异常。 但是，进行压力测试的时候，
|
缓存失效情况举例 看下这个段伪代码： local value = get_from_cache(key) if not value then value = query_db(sql) set_to_cache(value， timeout ＝ 100) end return value 看上去没有问题，在单元测试情况下，也不会有异常。 但是，进行压力测试的时候，你会发现，每隔100秒，数据库的查询就会出现一次峰值。如果你的cache失效时间设置的比较长，那么这个问题被发现的机率就会降低。 怎么解决？自然的想法是发现缓存失效后，加一把锁来控制数据库的请求。具体的细节，春哥在lua-resty-lock的文档里面做了详细的说明，我就不重复了，请看这里。多说一句，lua-resty-lock库本身已经替你完成了wait for lock的过程，看代码的时候需要注意下这个细节。 在上图中，大家可以看到，用户的更新数据直接持久化到DB, 业务读请求直接请求缓存数据，所以业务需要解决缓存失效问题，即解决因为数据变更导致缓存中的数据失效的问题。 目前业务解决缓存失效问题的解决方法一般是业务实现DB、缓存双写。通过业务双写解决缓存失效，存在如下的问题： 代码侵入性比较强，需要双写两份存储，任何对DB的数据变更，都需要同时更新缓存，代码层面后期可维护程度不高 用户请求线程里同步调用缓存，对缓存存在强以来，遇到缓存超时等异常时，没有办法做到有效的重试，遇到异常给用户返回系统错误、操作失败等信息，严重影响用户体验 用户请求线程里同步完成DB、缓存双写，变更请求链路长，访问延迟大，影响用户体验 RDS数据订阅消费，轻松解决缓存失效 在阿里巴巴内部同样也遇到了缓存失效的问题，随着业务架构得不断调整优化，我们已经沉淀出一套高可靠、极优雅得缓存失效架构。即通过数据传输提供的数据订阅功能，异步获取DB（例如公共云上的RDS）的增量数据，根据增量数据进行缓存失效。具体的架构类似下图： 在这个架构里面，缓存更新流程如下： 1.业务完成DB更新后即返回请求 2.数据订阅通过日志解析方式实时解析并订阅DB的增量更新数据，当发现DB有数据更新时，将增量数据推送给下游消费者 3.下游消费业务一旦接收到增量更新数据，即调用消费线程进行缓存更新 至此完成整个缓存更新过程。 从上面的缓存失效流程，可以看出这种缓存失效机制： 1.更新路径短，延迟低： 缓存失效为异步流程，业务更新DB完成后直接返回，不需要关心缓存失效流程，整个更新路径短，更新延迟低 2.应用简单可靠：应用无需实现复杂双写逻辑，只需启动异步线程监听增量数据，更新缓存数据即可 小结 数据订阅功能为阿里云数据传输提供的一种数据分发方式。通过数据订阅实现的缓存失效策略，让业务更新更快捷，让业务逻辑更简单、更可靠。 数据订阅只是数据传输提供的一种传输方式，除数据订阅之外，数据传输还提供了数据实时同步，不停服迁移等多种传输能力，如需了解数据传输更多详情，请猛击数据传输。  （编辑：应用网_丽江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330468号