“天下武功,无坚不摧,唯快不破”
2019年6月6日 下午6:06分 全民女神林志玲宣布结婚,这是一条爆炸新闻,究竟有多炸??,一会儿我再给你分析,看到这条消息的这一刻,我的心里也一阵悲叹,为什么在全民下班准备回家过端午的时候发布这条消息,这真的很6666。
微信里所有的群都在讨论“这位大哥你是谁?” 你究竟哪来的神仙?你很6吗?
做为一个程序员,我不关心这位大哥你有多6,我担心的是9,什么是9,是新浪服务器请求成功率还剩几个9,是99.9999,还是已经挺不住了?
为什么会担心这个呢?现在从技术角度来分析一下志玲姐姐宣布结婚的消息,对一个系统有什么挑战。
关于热点数据的危害与解决方案
什么是热点数据?
如淘宝双11,京东618,电商促销秒杀活动,微博爆炸性新闻等,一个话题或一件商品,在短时间内被大量读写,这些数据都有可能成为热点数据,一般解决热点数据,而这些热点数据往往存储在分布式缓存里,如Redis,
由于商品物美价廉,志玲姐姐太过漂亮,用户收到消息后会进入活动页面疯狂点击,请求量巨大,最终导致页面异常,服务器报警。报警信息显示很多关于Redis缓存的异常,一旦redis请求被打满请求无法相应后,系统自动降级转而向数据库去查询数据,这样数据库更加难以支撑,整个业务集群处于雪崩状态。
热点数据产生点危害
Redis使用最佳实践
2.热点key容易造成CPU、网络上的高负载。建议业务对热点key有降级方案
2.multi,pipeline,hgetall 如何选择? 如果本身key 不超过 100 , 建议存放在 hash中, hash批量获取可以减少网络IO (只获取一个key 和 获取多个key 的区别)
大部分场景下,推荐业务使用双机房部署方案,一个机房部署主节点,一个机房部署从节点,可以满足绝大多数的场景需求。极端场景下可能主节点所在机房掉电,那么集群处于不可用状态(此时可以通过人工介入来恢复集群的可用状态)。
对可用性要求高的业务我们推荐三机房部署方案,即便在一个机房掉电的场景下也能保证集群的高可用。
最后,我呼吁天下所有单身||离婚的程序员,不要再惦记志玲了,关注我跟我学技术,或许下一个女神就是你的。
我不是言承旭