14｜本地缓存：缓存存不下又不能回源怎么破？

徐逸

你好，我是徐逸。
在前面两节课里，我们已经深入探讨了多种解决分布式缓存问题的策略。然而，在面对高并发、低延迟的场景，特别是在抖音、快手这类短视频应用的推荐与搜索功能场景，我们发现 Redis 作为缓存解决方案存在一定的局限性。
这是因为 Redis 主要支持基本的 GET 操作，对于复杂的业务逻辑处理能力有限。为了达成个性化推荐的效果，单个请求通常都得从 Redis 中调取大量数据，然后在服务本地开展个性化的过滤与排序等工作。即便我们能够借助增加本地缓存来减少延时，可本地缓存从 Redis 回源的这个过程，还是会使响应时间变长，导致延时无法达到性能要求。
对于这类场景，我们更倾向于采用服务本地主动缓存全量数据的策略，由于服务所有实例缓存了全量数据，这一方式还天然规避了 Redis 的热 Key 和大 Key 问题。
今天我们就来聊聊，在本地缓存全量数据时，如何处理缓存加载、更新以及数据量过大的问题。
启动：如何解决加载慢的问题？如果采用本地缓存全量数据的方案，那么当程序启动时，我们就需要加载所有数据。对于数据的加载，最简单的方法就是当程序启动时，轮询从数据库拉取所有数据，并写入本地缓存。
图1 轮询 poll 加载
对于数据量较小的场景，这种方法是可行的。然而，随着数据量的增加，这种从数据库拉取全量数据的方式，会导致程序的启动时间显著变长。一旦服务出现问题，很难快速完成发布与回滚操作。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
法语
德语
日语
韩语
俄语
西班牙语
解释
总结

1. 本地缓存全量数据加载优化：采用本地文件加载和数据库轮询加载相结合的策略，以减少服务启动时间。 2. 数据更新同步策略：介绍了时间间隔轮询和广播触发更新两种方法，以确保本地缓存与数据库数据的同步，减少数据延迟对业务的影响。 3. 数据同步保障机制：建议实施定期对账机制，以确保本地缓存与数据库之间的最终一致性。 4. 分片集群策略：借鉴数据库分库分表的设计思路，将数据按一定规则拆分成多份，并放入不同的服务集群，以解决本地缓存过大问题.

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Go 服务开发高手课》，新⼈⾸单¥59

立即购买

登录后留言

精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。

收起评论