字节Java高级岗：华为4面技术5面HR

一、前言

最近刚读完一本书：《Netty、Zookeeper、Redis 并发实战》，个人觉得 Netty 部分是写得很不错的，读完之后又对 Netty 进行了一波很好的复习（之前用 spring boot + netty + zookeeper 模仿 dubbo 做 rpc 框架，那时候是刚学 netty 后自己造的小轮子）。

虽然对于 Netty 的使用已经比较熟悉了，而且还知道它的底层是基于 Java NIO 做进一步的封装，使得并发性能和开发效率得到大大的提升。但是，对于同步阻塞、同步非阻塞、异步这些概念，还是比较的模糊，一直处于似懂非懂的状态。

所以这两天，一直在网上看看大家对此的评论，也得到了一些启发。而且还有很多同学们提到了 《Netty 权威指南 第二版》 这本书，说前两章对于网络 I/O 模型和 Java I/O 的介绍很不错，所以我也特意去找了一本 pdf 来看看（比较穷。。。）。看了前两章后，确实对于这方面的概念清晰了不少，所以决定写下此文章来记录一下，也分享给更多不清楚这方面理论的同学们，并且也下定决定，有空一定把这本书继续看完，哈哈哈。

事故背景

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

什么原因造成的？

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

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

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

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

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

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

什么时候发现的？

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

为什么没有早点发现？

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

发现时采取了什么措施？

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

首先通过API Gateway（网关）限制大部分流量进来

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

再重新预热缓存

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

如何避免下次出现？

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

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

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

（1）均匀过期

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

（2）加互斥锁

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

（3）缓存永不过期

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

最后

针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。

上述的面试题答案都整理成文档笔记。 也还整理了一些面试资料&最新2021收集的一些大厂的面试真题（都整理成文档，小部分截图）

资料领取方式：点击这里免费获取

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。
mN1R2dB)**

[外链图片转存中…(img-h2U86WZS-1624444760267)]

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。