这篇文章我将介绍工作中处理热key问题的常用手段，可能介绍的不是很全，毕竟不同的业务场景可能有不同的解决方案，但是相信通过这部分的介绍能提供一个热key问题的思路。
热key问题，简单来说就是对某一资源的访问量过高问题，再简单一点来说就是对某个资源访问的qps过高，而解决访问量高的问题通常我们使用分布式缓存，最常见的就是redis，这个资源对应redis的一个key简称热key。热key在开发中是非常常见的，比如各种app的榜单，活动页面上的一些资源。
虽然redis号称单节点能扛住10Wqps，但是开发中肯定不能这样去估计，毕竟安全第一，比如5000似乎就可能就可以作为上限。如果超过5000该怎么处理呢？下面将提供几种常见的解决方案。
冗余写/随机读
假设在做活动，活动总金额为amount，用户每次完成任务会得到一笔奖金，每天结算一次，在页面会展示剩余金额restAmount。我们将剩余金额存到redis中，{key: pool, value: restAmount}
由于每天统一结算，所以写的qps不会很高，毕竟我们能自己控制流量，比如用户完成后发个延迟结算消息到mq，然后由消费者来处理计算剩余金额最后更新到redis中。
但是在页面的读的qps是很高的。显然奖池pool就是个热key。
既然单节点扛不住，那么显然可以