商品，活动热key问题监听

在疯狂的消费者面前,某些热点商品带来的疯狂是开发人员都不敢想象的,所以redis都可能TM扛不住,只有使用最牛逼的本地缓存可以抗衡(ps：也不一定，有些第三方服务做的好的除外，我这边不太能完全相信第三方)

一.这里对于目前手里的资源，做了一些妥协向下的适配

组内资源有限，不像京东主页的秒杀团队，动辄能有几万核，几十万G内存的资源调度，那么我就要做一些妥协了...因为常驻的本地缓存就等同于我们主观的内存泄露，设置的不合理，极有可能导致我们线上GC失调

1.目前为了实现本地缓存最高命中率,以及节约服务器内存资源,只有活动信息以及时段信息等上线就不会变化的,而且要是高频查询的(像活动是不是活动商品,活动有效期啊,活动开团时段啊等等),这些咱们进行本地化缓存
2.另外固定热key条数限制为1000条
3.淘汰算法为LRU淘汰,因为我这边周期购活动,周期性时间规律比较强,用LFU最近最少使用极有可能淘汰掉只是暂时没开团的活动,导致本地缓存命中率低顺带着提一嘴,我们这里用的京东云提供给我们的热点发现服务,我也就是LUR算法,对一定时间内的数据做统计

二 热key的简略流程图

图是用processon画的，不用问了

三 如何获取热Key？

一般情况 热key的获取有两种

• 1.第三方中间件服务提供的热key监听（如redis的热key反馈）
• 2.我方主动上报（一般以一定时间间隔收集请求频次，并上报到work进行计算）

四 推荐一个热key统计服务

hotkey 京东零售开源出来的一个热key统计服务
京东App后台中间件，毫秒级探测热点数据，毫秒级推送至服务器集群内存，大幅降低热key对数据层查询压力，每秒单机吞吐量（写入+对外推送）目前在70万左右稳定。