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

引言

什么是热点数据？

身边还有哪些热点数据？

• 得物双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 进行命中率统计
当然这块只是作为验证，不建议所有服务都接入

总结

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