12｜分布式缓存：大促抢购，不知热点咋防热Key？
徐逸
你好，我是徐逸。
通过上节课的学习，我们知道了提升服务吞吐的数据库架构方案。
不过在实践中，除了在数据库层面做优化之外，我们还可以通过搭配缓存的方式，来减轻数据库的访问压力，避免数据库成为性能瓶颈点。例如电商大促的商品详情页，由于商品的名称、图片链接、价格等数据会被频繁访问，因此一般会被缓存，以便提升系统的性能。
今天我们就来聊聊，在大促抢购期间，有些商品访问 QPS 突然大幅度增高时，我们如何才能保障 Redis 访问的性能不受影响呢？
什么是热 Key 问题
在讨论具体方案之前，你不妨先想一想：要是 Redis 中某个 Key 的访问 QPS 突然变得很高，会给我们的系统带来怎样的影响？
就像下面的图展示的一样，当从 Redis 读取数据时，Redis 代理服务会基于 Key 进行 Hash 计算，以此定位到 Redis 中实际存放数据的后端 Redis Server。所以，要是某个 Key 的访问 QPS 突然大幅攀升，那么这个 Key 所在的 Redis Server 就会有部分请求被迫排队，进而导致延迟升高，严重时还会出现超时失败的状况。这便是我们平常所说的热 Key 问题，而那些被高频率访问的 Key 就是热 Key。
图1 Redis 分片架构
在应对突发热 Key 所引发的性能难题时，各个公司所采用的解决方案可谓是各有千秋。不过，它们的核心思路却殊途同归，那便是借助更多的机器资源，来分担热 Key 的访问流量。这些方案大致能够归为以下两类。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
1. 热 Key 问题对系统性能的影响：突发热 Key 访问会导致 Redis Server 延迟升高和超时失败，成为性能瓶颈点。 2. 业务层解决方案：通过本地缓存全量数据或部分数据，以及使用热 Key 探测框架进行热 Key 的判断与推送，来解决热 Key 问题。 3. Redis层解决方案：采用读写分离架构或利用 Proxy 来缓存热 Key 数据，承担热 Key 访问所带来的压力，从而解决热 Key 问题。 4. Proxy 热 Key 承载方案：利用 Proxy 来缓存热 Key 数据，承担热 Key 访问所带来的压力，避免资源浪费。 5. 业务层解决方案的核心思路：借助更多的机器资源，来分担热 Key 的访问流量，包括本地缓存全量数据、本地缓存部分数据和热 Key 探测框架。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Go 服务开发高手课》，新⼈⾸单¥59
《Go 服务开发高手课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论