高并发技巧-redis热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。

既然单节点扛不住，那么显然可以将数据写到N个节点上，也就是将奖池存到多个节点，在页面读取的时候随机选一个节点去读。假如有10W的qps，N=10，那么每个节点的流量就成了1W的qps。

<