0
点赞
收藏
分享

微信扫一扫

java大厂社招面试,蚂蚁金服java面试题

开头

消息队列 RocketMQ 是阿里巴巴集团基于高可用分布式集群技术,自主研发的云正式商用的专业消息中间件,既可为分布式应用系统提供异步解耦和削峰填谷的能力,同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性,是阿里巴巴双 11 使用的核心产品。

6月初偶然从朋友那里得到一份纯手打“RocketMQ笔记”(貌似全网都没有这份学习笔记,中大奖了,哈哈哈),花了十天时间刷了第一遍,感觉挺不错的,今天拿出来献个宝。全网首发,纯手打“RocketMQ笔记”,帮你解决95%以上的问题!

image

事故背景

公司最近安排了一波商品抢购活动,由于后台小哥操作失误最终导致活动效果差,被用户和代理商投诉了。经理让我带同事们一起复盘这次线上事故。

什么原因造成的?

抢购活动计划是零点准时开始,

22:00 运营人员通过后台将商品上线

23:00后台小哥已经将商品导入缓存中,提前预热

抢购开始的瞬间流量非常大,按计划是通过Redis承担大部分用户查询请求,避免请求全部落在数据库上。

缓存命中

如上图预期大部分请求会命中缓存,但是由于后台小哥预热缓存的时候将所有商品的缓存时间都设置为2小时过期,所有的商品在同一个时间点全部失效,瞬间所有的请求都落在数据库上,导致数据库扛不住压力崩溃,用户所有的请求都超时报错。

实际上所有的请求都直接落到数据库,如下图:

缓存雪崩

什么时候发现的?

凌晨01:02 SRE 收到系统告警,登录运维管理系统发现数据库节点 CPU和内存飙升超过阈值,迅速联系后台开发人员定位排查。

为什么没有早点发现?

由于缓存设置过期时间是2小时,凌晨1点前缓存可以命中大部分请求,数据库服务处于正常状态。

发现时采取了什么措施?

后台小哥通过日志定位排查发现问题后,进行了一系列操作:

首先通过API Gateway(网关)限制大部分流量进来?

接着将宕机的数据库服务重启?

再重新预热缓存?

确认缓存和数据库服务正常后将网关流量正常放开,大约01:30 抢购活动恢复正常。

如何避免下次出现?

这次事故的原因其实就是出现了缓存雪崩,查询数据量巨大,请求直接落到数据库上,引起数据库压力过大宕机。

在业界解决缓存雪崩的方法其实比较成熟了,比如有:

  • 均匀过期
  • 加互斥锁
  • 缓存永不过期

(1)均匀过期

设置不同的过期时间,让缓存失效的时间点尽量均匀。通常可以为有效期增加随机值或者统一规划有效期。

缓存key过期时间均匀分布

(2)加互斥锁

跟缓存击穿解决思路一致,同一时间只让一个线程构建缓存,其他线程阻塞排队。

互斥访问

(3)缓存永不过期

跟缓存击穿解决思路一致,缓存在物理上永远不过期,用一个异步的线程更新缓存。

异步更新缓存

技术学习总结

学习技术一定要制定一个明确的学习路线,这样才能高效的学习,不必要做无效功,既浪费时间又得不到什么效率,大家不妨按照我这份路线来学习。

java大厂社招面试,蚂蚁金服java面试题

java大厂社招面试,蚂蚁金服java面试题

java大厂社招面试,蚂蚁金服java面试题

最后面试分享

大家不妨直接在牛客和力扣上多刷题,同时,我也拿了一些面试题跟大家分享,也是从一些大佬那里获得的,大家不妨多刷刷题,为金九银十冲一波!

java大厂社招面试,蚂蚁金服java面试题

java大厂社招面试,蚂蚁金服java面试题

本文已被CODING开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

举报

相关推荐

0 条评论