赵丽颖离婚后我都想了些什么

导言

什么是抢手数据？

身边还有哪些抢手数据？

• 得物双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 进行命中率核算
当然这块仅仅作为验证，不主张全部服务都接入

总结

日子很长，现在很好，愿未来更好。