摘要：我的想法是这样，如果在还没拿到某个大厂 offer 之前，先不着急选部门，哪个部门约你面试，你就面哪个再说，先拿第一个大厂 offer 先拿下来会更好，然后后面再考虑找其他大厂业务比较核心的部门，不然一开始就挑来挑去，最终可能啥都没有。
图解学习网站：https://xiaolincoding.com
大家好，我是小林。
最近是春招投递的高峰期时间，很多同学遇到一个问题，大厂部门那么多，如何选择部门来投递呢？
我的想法是这样，如果在还没拿到某个大厂 offer 之前，先不着急选部门，哪个部门约你面试，你就面哪个再说，先拿第一个大厂 offer 先拿下来会更好，然后后面再考虑找其他大厂业务比较核心的部门，不然一开始就挑来挑去，最终可能啥都没有。
当然，还有一个方式也可以作为参考，就是看大厂各个事业群年终奖的情况，年终奖发的越多，大概率这个业务是比较核心的。
这次，我们来看看快手今年年终奖的情况，我根据脉脉网的爆料，整理了与后端岗位有关的年终奖信息，年终奖也与个人的绩效挂钩，所以仅供参考：
这里也贴一个快手职级体系映射薪酬级别的表格，这个是老的职级：
现在快手是 e 系列为职级了，新老职级的对比如下：
既然聊到快手，那么快手的面经也是逃不了的
来看看最近快手的Java后端开发的校招面经，属于一面，重点考虑了Redis、消息队列、MySQL、网络、SSM、项目场景、算法这些内容。
快手一面Redis有哪些客户端，有什么区别？
在 Java 编程中，我了解到的有 Jedis 和 Redisson 这两种客户端
我的项目中，因为有用到 redis 分布式锁，所以选择了 Redisson。
为什么选择RabbitMQ，kafka了解过吗，使用场景？
Kafka、ActiveMQ、RabbitMQ、RocketMQ来进行不同维度对比。
特性ActiveMQRabbitMQRocketMQKafka选型的时候，我们需要根据业务场景，结合上述特性来进行选型。
比如你要支持天猫双十一类超大型的秒杀活动，这种一锤子买卖，那管理界面、消息回溯啥的不重要。
我们需要看什么？看吞吐量！所以优先选Kafka和RocketMQ这种更高吞吐的。
比如做一个公司的中台，对外提供能力，那可能会有很多主题接入，这时候主题个数又是很重要的考量，像Kafka这样百级的，就不太符合要求，可以根据情况考虑千级的RocketMQ，甚至百万级的RabbitMQ。
又比如是一个金融类业务，那么重点考虑的就是稳定性、安全性，分布式部署的Kafka和Rocket就更有优势。
特别说一下时效性，RabbitMQ以微秒的时效作为招牌，但实际上毫秒和微秒，在绝大多数情况下，都没有感知的区别，加上网络带来的波动，这一点在生产过程中，反而不会作为重要的考量。
其它的特性，如消息确认、消息回溯，也经常作为考量的场景，管理界面的话试公司而定了，反正我呆过的地方，都不看重这个，毕竟都有自己的运维体系。
如何避免消费端重复消费？
避免消费端重复消费的方法有：
什么情况下会出现重复收到消息？
当消费端与消息队列之间的网络出现故障，如网络中断、延迟过高或数据包丢失等情况，可能导致消息的确认信息未能及时发送到消息队列。消息队列在未收到确认信息时，会认为消息没有被成功消费，从而重新发送消息，导致消费端重复收到消息。
TCP 粘包半包是什么，怎么解决的？
粘包
半包指发送方发送的数据大于发送缓冲区，接收端一次接收的数据不是完整的数据。比如，客户端发送一个较大的数据包 “ABCDEFG”，由于数据包大小超过了 TCP 缓存容量，它会被分成多个包发送，服务端第一次可能只收到 “ABC”，这就是半包现象。半包产生的原因主要有以下方面：
针对 TCP 粘包和沾包一般有三种解决的方式。
这种是最简单方法，即每个用户消息都是固定长度的，比如规定一个消息的长度是 64 个字节，当接收方接满 64 个字节，就认为这个内容是一个完整且有效的消息。
但是这种方式灵活性不高，实际中很少用。
我们可以在两个用户消息之间插入一个特殊的字符串，这样接收方在接收数据时，读到了这个特殊字符，就把认为已经读完一个完整的消息。
HTTP 是一个非常好的例子。
HTTP 通过设置回车符、换行符作为 HTTP 报文协议的边界。
有一点要注意，这个作为边界点的特殊字符，如果刚好消息内容里有这个特殊字符，我们要对这个字符转义，避免被接收方当作消息的边界点而解析到无效的数据。
我们可以自定义一个消息结构，由包头和数据组成，其中包头包是固定大小的，而且包头里有一个字段来说明紧随其后的数据有多大。
比如这个消息结构体，首先 4 个字节大小的变量来表示数据长度，真正的数据则在后面。
struct { u_int32_t message_length; char message_data; } message;当接收方接收到包头的大小（比如 4 个字节）后，就解析包头的内容，于是就可以知道数据的长度，然后接下来就继续读取数据，直到读满数据的长度，就可以组装成一个完整到用户消息来处理了。
限流算法中漏桶和令牌桶使用场景是什么？
漏桶限流算法是模拟水流过一个有漏洞的桶进而限流的思路，如图。
水龙头的水先流入漏桶，再通过漏桶底部的孔流出。如果流入的水量太大，底部的孔来不及流出，就会导致水桶太满溢出去。
从系统的角度来看，我们不知道什么时候会有请求来，也不知道请求会以多大的速率来，这就给系统的安全性埋下了隐患。但是如果加了一层漏斗算法限流之后，就能够保证请求以恒定的速率流出。在系统看来，请求永远是以平滑的传输速率过来，从而起到了保护系统的作用。
使用漏桶限流算法，缺点有两个：
令牌桶是另一种桶限流算法，模拟一个特定大小的桶，然后向桶中以特定的速度放入令牌（token），请求到达后，必须从桶中取出一个令牌才能继续处理。如果桶中已经没有令牌了，那么当前请求就被限流。如果桶中的令牌放满了，令牌桶也会溢出。
放令牌的动作是持续不断进行的，如果桶中令牌数达到上限，则丢弃令牌，因此桶中可能一直持有大量的可用令牌。此时请求进来可以直接拿到令牌执行。比如设置 qps 为 100，那么限流器初始化完成 1 秒后，桶中就已经有 100 个令牌了，如果此前还没有请求过来，这时突然来了 100 个请求，该限流器可以抵挡瞬时的 100 个请求。由此可见，只有桶中没有令牌时，请求才会进行等待，最终表现的效果即为以一定的速率执行。令牌桶的示意图如下：
令牌桶限流算法综合效果比较好，能在最大程度利用系统资源处理请求的基础上，实现限流的目标，建议通常场景中优先使用该算法。
Springboot怎么做到导入就可以直接使用的？
这个主要依赖于自动配置、起步依赖和条件注解等特性。
起步依赖是一种特殊的 Maven 或 Gradle 依赖，它将项目所需的一系列依赖打包在一起。例如， 这个起步依赖就包含了 Spring Web MVC、Tomcat 等构建 Web 应用所需的核心依赖。
开发者只需在项目中添加一个起步依赖，Maven 或 Gradle 就会自动下载并管理与之关联的所有依赖，避免了手动添加大量依赖的繁琐过程。
pom.xml中添加 org.springframework.boot spring-boot-starter-webSpring Boot 的自动配置机制会根据类路径下的依赖和开发者的配置，自动创建和配置应用所需的 Bean。它通过 注解启用，该注解会触发 Spring Boot 去查找 META - INF/spring.factories 文件。
spring.factories 文件中定义了一系列自动配置类，Spring Boot 会根据当前项目的依赖情况，选择合适的自动配置类进行加载。例如，如果项目中包含 spring-boot-starter-web依赖，Spring Boot 会加载WebMvcAutoConfiguration类，该类会自动配置 Spring MVC 的相关组件，如 DispatcherServlet、视图解析器等。开发者可以通过自定义配置来覆盖自动配置的默认行为。如果开发者在 application.properties 或application.yml中定义了特定的配置，或者在代码中定义了同名的 Bean，Spring Boot 会优先使用开发者的配置。条件注解用于控制 Bean 的创建和加载，只有在满足特定条件时，才会创建相应的 Bean。Spring Boot 的自动配置类中广泛使用了条件注解，如 、@ConditionalOnMissingBean 等。
@ConditionalOnClass表示只有当类路径中存在指定的类时，才会创建该 Bean。例如，在@Configuration@ConditionalOnClass({ Servlet.class, DispatcherServlet.class, WebMVCConfigurer.class })public class WebMvcAutoConfiguration { // 配置相关的 Bean}类中的配置。mysql默认隔离级别是什么？
可重复读隔离级别
可重复读能够解决幻读问题吗？
可重复读隔离级别下虽然很大程度上避免了幻读，但是还是没有能完全解决幻读。
举一个可重复读下出现幻读的例子？
我举例一个可重复读隔离级别发生幻读现象的场景。以这张表作为例子：
事务 A 执行查询 id = 5 的记录，此时表中是没有该记录的，所以查询不出来。
# 事务 Amysql> begin;Query OK, 0 rows affected (0.00 sec)mysql> select * from t_stu where id = 5;Empty set (0.01 sec)然后事务 B 插入一条 id = 5 的记录，并且提交了事务。
# 事务 Bmysql> begin;Query OK, 0 rows affected (0.00 sec)mysql> insert into t_stu values(5, '小美', 18);Query OK, 1 row affected (0.00 sec)mysql> commit;Query OK, 0 rows affected (0.00 sec)此时，事务 A 更新 id = 5 这条记录，对没错，事务 A 看不到 id = 5 这条记录，但是他去更新了这条记录，这场景确实很违和，然后再次查询 id = 5 的记录，事务 A 就能看到事务 B 插入的纪录了，幻读就是发生在这种违和的场景。
# 事务 Amysql> update t_stu setname = '小林coding'whereid = 5;Query OK, 1 row affected (0.01 sec)Rows matched: 1 Changed: 1 Warnings: 0mysql> select * from t_stu whereid = 5;+----++------+| id | name | age |+----++------+| 5 | 小林coding | 18 |+----++------+1 row in set (0.00 sec)整个发生幻读的时序图如下：
在可重复读隔离级别下，事务 A 第一次执行普通的 select 语句时生成了一个 ReadView，之后事务 B 向表中新插入了一条 id = 5 的记录并提交。接着，事务 A 对 id = 5 这条记录进行了更新操作，在这个时刻，这条新记录的 trx_id 隐藏列的值就变成了事务 A 的事务 id，之后事务 A 再使用普通 select 语句去查询这条记录时就可以看到这条记录了，于是就发生了幻读。
因为这种特殊现象的存在，所以我们认为 MySQL Innodb 中的 MVCC 并不能完全避免幻读现象。
mysql有哪些日志？都有什么作用？
插入一行数据，分别什么时候写入这三个日志？
INSERT 事务 │ │ 1. 生成 Undo Log（记录反向操作） ▼ 更新 Buffer Pool 数据页 │ │ 2. 写入 Redo Log Buffer（物理变更） ▼ 「事务提交 Prepare 阶段」 │ │ 3. Redo Log 刷盘（根据参数配置） ▼ 「事务提交 Commit 阶段」 │ │ 4. 写入 Binlog 并刷盘（根据参数配置） ▼ 完成来源：敏敏萝莉小清新
