导言
什么是抢手数据？
身边还有哪些抢手数据？
- 得物双11
- 淘宝双11
- 京东618
- 微博爆炸性新闻：#特斯拉展台变维权现场#
抢手带来的应战&危机
- 流量来的凶狠，措不及防，达到很多物理设备上线，不得不拔网线
- 缓存击穿
- 服务击垮
- db防线失守
- 系统奔溃
该如何是好？
已然我们阻止不了支离破碎的婚姻，那么只能做好自己本分的工作：抢手勘探；模拟以下场景
- 产品概况数据量巨大，有些乃至几十上百K，最大的有M等级
- 商家搞活动常常将网卡打满
- 加本地缓存却又增加了节点资源开支，命中率，利用率极低
- 爆款无法及时预知，机器要保存99%闲暇去ready？
整体架构
规划特性分析
- 伸缩性：接收抢手输入选用kafka消费日志，可扩展多台集群，抢手发现选用redis-cluster，关于多抢手可以进行集群横向扩展
- 高可用：中间件大都选用zk推举、或许其他分布式推举战略，保证集群高可用
- 稳定性：抢手核算选用异步核算，对线上事务无影响
- 扩展性：可扩展
抢手勘探
勘探维度规划
已然要涉及成多产品运用，我们应该有appName
每个产品有自己的维度比如帖子服务，有议论抢手，点赞抢手等所以eventKey 也应该具有
事情产生的时刻：eventTime
在核算抢手帖子可能有很多维度，点赞，议论，阅览，相比之下议论的权重比阅览高 那么每个事情应该有自己的权重：weight
数据流转、核算细节
收集：集群消费kafka音讯，将数据放入chm中
热度核算：滑动窗口每隔必定时钟，将数据放入redis zset 中
抢手勘探：抢手勘探从redis zset 中拿取指定事情的topN、top%N等数据
实时性：可以经过时刻轮的时钟周期动态调整，比如文章相关于帖子的周期较长
功能：chm内存操作，并非实时操作redis
本地缓存
抢手核算的top值可以实时的推送给事务方，事务方依据情况给感兴趣的用户发送推送，或许提早做好本地缓存。
命中率核算
作为我们规划的效果，命中率校验自然是少不了，可以参看spring 的aop 进行命中率核算
当然这块仅仅作为验证，不主张全部服务都接入
总结
日子很长，现在很好，愿未来更好。
