system-design-notes排行榜分区2大策略哈希分区 vs 范围分区怎么选【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes本文基于系统设计面试笔记system-design-notes《System Design Interview》配套笔记第 25 章实时游戏排行榜带你吃透排行榜系统扩容时最核心的一个决策数据分区。当单台 Redis 扛不住 5000 万日活的存储与 25 万 QPS 时就有两条主流路线——范围分区Range Partitioning和哈希分区Hash Partitioning。它们各自擅长什么、坑在哪里、最终该怎么选看完这篇你就明白了。为什么需要分区单台 Redis 扛不住的临界点 排行榜的核心存储是 Redis 的有序集合Sorted Set一张按分数排序的member → score表新增和查找都是 O(logN)按笔记中的估算500 万 DAU约 650MB 存储 2500 QPS单台 Redis 轻松搞定用户增长 10 倍到 5000 万 DAU存储涨到 65GB写入 QPS 飙到 25 万——单实例到顶了必须分片。整体架构上玩家获胜 → 游戏服务校验后更新分数 → 排行榜服务写入 Leaderboard Store → 玩家随时拉取 Top 10 和自己的名次接下来就是本章最精华的部分怎么把这份数据切成多块策略一范围分区Range Partitioning——查 Top 10 一步到位按分数区间手动分片每个分片是一个只负责一段分数的有序集合应用层维护user_id → 分片的映射可用 MySQL 或缓存。两大高频查询的表现非常漂亮查询做法查 Top 10只查分数最高的那个分片如[900, 1000]一步出结果查用户名次算出用户在本分片内的名次再把其他分片中分数更高的人数累加进来各分片总条数可用 Redisinfo keyspace命令 O(1) 获取一句话读路径极简精确名次可算。代价是分片区间需要人工规划扩容时要手动迁移数据。策略二哈希分区Hash Partitioning——Redis Cluster 免费帮你搞定直接用Redis Cluster客户端请求先经过 Proxy按Slot CRC16(key) % 16384把 key 自动打散到各主节点每个分片自带副本数据分布均匀、自动扩容、副本容错都是免费的。但问题来了——查 Top 10 变难了每个分片里的数据是随机打散的你必须取回每个分片各自的 Top 10再在应用层做 scatter-gather 归并哈希分区的三大短板 ⚠️K 一大就慢要取 Top K 且 K 很大时得从所有分片拉大量数据再合并分片越多延迟越高scatter-gather 的耗时随分区数量线性增长精确名次没有捷径无法像范围分区那样直接累加得出用户的绝对排名。怎么选两大策略速查对比维度范围分区哈希分区Redis Cluster数据分布手动规划区间哈希自动打散天然均匀查 Top K✅ 一步到位延迟最低❌ 需全分片 scatter-gather查用户精确名次✅ 可计算❌ 无直接方案扩容 / 容错手动迁移✅ 自动、带副本适合场景排行榜等读多、Top K 高频通用 KV 存储Top K 低频笔记作者对排行榜场景的结论很明确倾向范围固定分区。因为排行榜的主旋律就是实时 Top 10 我的名次正好踩在范围分区的甜区上。补充思路NoSQL 写分片方案 如果愿意换存储DynamoDB / Cassandra / MongoDB 这类 NoSQL 也能承载用game#月份做分区键、分数做排序键。但最新月份会形成热点分区可以用写分片技巧——给每个 key 追加pN编号N user_id % 分区数打散写入代价同样要记牢分区越多写扩展性越好但读聚合要查的分区也越多而且精确名次依然算不出来——笔记建议退一步用定时任务统计分数分布告诉用户你处在 90 分位即可。一句话总结 高频查Top K 需要精确名次→ 选范围分区只要通用 KV 能力、Top K 查询低频 →哈希分区Redis Cluster省心能接受分位数替代精确名次 →NoSQL 写分片也是合格答案。完整推导、容量估算与所有架构图见原章节25. Real-time Gaming Leaderboard/README.md【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 system-design-notes：排行榜分区2大策略：哈希分区 vs 范围分区怎么选？
system-design-notes排行榜分区2大策略哈希分区 vs 范围分区怎么选【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes本文基于系统设计面试笔记system-design-notes《System Design Interview》配套笔记第 25 章实时游戏排行榜带你吃透排行榜系统扩容时最核心的一个决策数据分区。当单台 Redis 扛不住 5000 万日活的存储与 25 万 QPS 时就有两条主流路线——范围分区Range Partitioning和哈希分区Hash Partitioning。它们各自擅长什么、坑在哪里、最终该怎么选看完这篇你就明白了。为什么需要分区单台 Redis 扛不住的临界点 排行榜的核心存储是 Redis 的有序集合Sorted Set一张按分数排序的member → score表新增和查找都是 O(logN)按笔记中的估算500 万 DAU约 650MB 存储 2500 QPS单台 Redis 轻松搞定用户增长 10 倍到 5000 万 DAU存储涨到 65GB写入 QPS 飙到 25 万——单实例到顶了必须分片。整体架构上玩家获胜 → 游戏服务校验后更新分数 → 排行榜服务写入 Leaderboard Store → 玩家随时拉取 Top 10 和自己的名次接下来就是本章最精华的部分怎么把这份数据切成多块策略一范围分区Range Partitioning——查 Top 10 一步到位按分数区间手动分片每个分片是一个只负责一段分数的有序集合应用层维护user_id → 分片的映射可用 MySQL 或缓存。两大高频查询的表现非常漂亮查询做法查 Top 10只查分数最高的那个分片如[900, 1000]一步出结果查用户名次算出用户在本分片内的名次再把其他分片中分数更高的人数累加进来各分片总条数可用 Redisinfo keyspace命令 O(1) 获取一句话读路径极简精确名次可算。代价是分片区间需要人工规划扩容时要手动迁移数据。策略二哈希分区Hash Partitioning——Redis Cluster 免费帮你搞定直接用Redis Cluster客户端请求先经过 Proxy按Slot CRC16(key) % 16384把 key 自动打散到各主节点每个分片自带副本数据分布均匀、自动扩容、副本容错都是免费的。但问题来了——查 Top 10 变难了每个分片里的数据是随机打散的你必须取回每个分片各自的 Top 10再在应用层做 scatter-gather 归并哈希分区的三大短板 ⚠️K 一大就慢要取 Top K 且 K 很大时得从所有分片拉大量数据再合并分片越多延迟越高scatter-gather 的耗时随分区数量线性增长精确名次没有捷径无法像范围分区那样直接累加得出用户的绝对排名。怎么选两大策略速查对比维度范围分区哈希分区Redis Cluster数据分布手动规划区间哈希自动打散天然均匀查 Top K✅ 一步到位延迟最低❌ 需全分片 scatter-gather查用户精确名次✅ 可计算❌ 无直接方案扩容 / 容错手动迁移✅ 自动、带副本适合场景排行榜等读多、Top K 高频通用 KV 存储Top K 低频笔记作者对排行榜场景的结论很明确倾向范围固定分区。因为排行榜的主旋律就是实时 Top 10 我的名次正好踩在范围分区的甜区上。补充思路NoSQL 写分片方案 如果愿意换存储DynamoDB / Cassandra / MongoDB 这类 NoSQL 也能承载用game#月份做分区键、分数做排序键。但最新月份会形成热点分区可以用写分片技巧——给每个 key 追加pN编号N user_id % 分区数打散写入代价同样要记牢分区越多写扩展性越好但读聚合要查的分区也越多而且精确名次依然算不出来——笔记建议退一步用定时任务统计分数分布告诉用户你处在 90 分位即可。一句话总结 高频查Top K 需要精确名次→ 选范围分区只要通用 KV 能力、Top K 查询低频 →哈希分区Redis Cluster省心能接受分位数替代精确名次 →NoSQL 写分片也是合格答案。完整推导、容量估算与所有架构图见原章节25. Real-time Gaming Leaderboard/README.md【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考