哈希分区防不住单键极端热点需靠应用层给主键加随机后缀

[[哈希分区用复合主键在负载均衡与范围查询间折衷]]能缓解大多数偏斜，但对付不了一种 极端场景：所有读写都集中在同一个键上，比如社交媒体上某个千万粉丝的名人一发状态， 围绕这条状态ID或这个用户ID的读写请求会形成风暴——哈希策略在这里完全无效，因为 同一个键无论哈希多少次，值都一样，请求永远落在同一个分区，加多少节点都没用。目前 大多数数据系统没法自动识别和补偿这种极端偏斜，需要应用层主动介入：最简单的做法是 给这类”热”主键的开头或结尾附加一个随机数，比如两位数的十进制随机数就能把一个热 主键拆分成100种不同的实际存储键、分散到不同分区。但这个手段不是免费的：拆分之后， 任何针对这个逻辑键的读取都必须去查全部100个衍生键、再把结果合并，读取成本明显 上升；而且这个额外的随机化只应该用在真正被识别出是热点的极少数键上，对绝大多数 写入吞吐量正常的键强行加随机后缀纯属浪费，所以还需要一套机制去跟踪、判断”到底 哪些键需要被拆分”，这本身就是额外的运维复杂度。这个案例说明的原则是：分区方案再 精巧，也只能保证”分布均匀”这个统计意义上的目标，对付不了”访问模式本身就是极度 集中”的场景，遇到这种场景时，负载均衡的责任必须部分转移给应用层，而不能指望 底层存储引擎单方面兜底。