来了，好上岸的中小厂最新面经！

往期硬核面经

哦耶！冲进腾讯了！

牛逼！上岸腾讯互娱和腾讯TEG！

腾讯的面试，强度拉满！

前几篇文章分享了上岸大厂（尤其是腾讯）的最新面经。

不少粉丝股东留言说上岸大厂太难了，有没有好上岸的中小厂的最新面经。

必须安排，今天分享一位朋友社招的面经：

富途 一面

1. http相较于https多了什么步骤？
2. https证书为什么一边是对称加密，一边是非对称加密（没有回答出来）

解析：非对称加密是为了保护证书里的对称密钥，服务器只能用对应的私钥解密拿到里面的对称密钥，后续沟通时就通过证书里的密钥进行对称加密沟通

2. tcp挥手为什么有第四次
3. time\_wait阶段在哪里，为什么需要2MSL的长度
4. 大量连接处于time\_wait阶段可能有什么与原因，怎么解决?

回答：大量连接同时关闭，关闭连接时加上随机偏移值
解析：当大量短连接被快速创建和关闭时，会有大量的连接同时处于TIME\_WAIT状态。
解决方法：

• 调整TCP参数：在服务器上调整TCP参数，比如减少TIME\_WAIT的持续时间或增加可用端口范围。
• 使用长连接：避免频繁建立和关闭连接。可以通过使用长连接（例如，持续的数据库或API连接）来减少进入TIME\_WAIT状态的连接数量
• 负载均衡：使用负载均衡技术分散请求，以减少单一服务器上的连接数。这样可以平均分配连接负载，减少任一服务器上TIME\_WAIT状态的连接数量。
• 连接池：对于数据库或其他需要频繁建立连接的服务，使用连接池可以避免频繁地打开和关闭连接，因为连接池允许连接被重用。

5. 浏览器输入回车后，发生了什么
6. 一道算法题：分段阶梯计费

• 面试官提醒了一些问题：最后一个阶段是（左界限 --- .....）之前的循环条件是按右界限来计算的。
  回答：那应该最后一个阶段，单独判断下
• 如果后面分了很多阶段，代码有什么优化的地方吗？
  没有想出来，不知道咋优化

7. 一道SQL：（没写出来，sql语法都忘了）

解析：

SELECT u.username, COUNT(t.tid) AS post_count
FROM user u
JOIN thread t ON u.uid = t.uid
GROUP BY u.uid, u.username
ORDER BY post_count DESC
LIMIT 10;

索引设计
对于这个查询，可以设计以下索引：

1. 用户表 (user)：

• 主键索引在 uid 字段上（通常在创建表时自动设置为主键）。

2. 帖子表 (thread)：

• 一个复合索引在 uid 和 create\_time 字段上，这有助于快速筛选出每个用户的最新帖子。

确定索引的使用

要确定 SQL 会使用哪个索引，可以在执行 SQL 查询之前使用 EXPLAIN 或 EXPLAIN ANALYZE 命令（取决于具体的数据库管理系统）。这将显示查询的执行计划，包括是否使用了索引以及使用了哪些索引。

在 MySQL 中，则可以使用：

EXPLAIN FORMAT=JSON SELECT ...

查询是否最优

虽然上述查询可能在大多数情况下都能很好地工作，但如果数据量非常大，这个查询可能会变得缓慢，因为需要对所有用户进行聚合和排序。为了优化这个查询，可以考虑以下策略：

• 确保数据库使用适当的索引进行 JOIN 和 ORDER BY 操作。
• 对 thread 表的 uid 字段创建索引可以帮助加速分组和排序操作。
• 如果查询仍然较慢，可以考虑物化视图，预先计算并存储结果，特别是如果这个查询频繁执行而数据变化不大时。

在查询优化和索引策略中，需要根据实际数据量和数据库性能测试结果来不断调整和优化。

童心制物 一面

1. 弹窗推送是负责哪部分

负责从MQ拿到数据解析后给下游服务，同事做极光推送

2. 有改进或者特殊的点吗

1. 数据消息体的格式化，不同的topic的消息体不一样，代码写起来很麻烦，所以直接做了格式化，数据就在payload里面，其他的也在对应字段上。
2. 跟具体解析业务代码的数据交互是通过RPC，因为一个消息可能有多种业务的处理需要，这些也都需要想用返回，所以用了RPC的服务流。

3. 弹窗是有定时和实时的吗

是的，根据设备上报的协议字段做相关推送

4. 工作中并发是怎么应用的呢，看简历上写了errgroup

电量api查询时，比如一个月的用电，可能需要查一个月的每日用电量、当前一个月的累计用电、前一个月的累计用电。把一个大的任务分成多个小的任务，去并发调用执行，增加了接口的响应速度

5. 这期间会出现什么问题吗，比如查询不出来，或者超时怎么办

查询不出来就置为0，然后能在报表上看见。 这个地方不知道怎么咋说。

6. 又遇到过什么并发问题吗？

没有，说业务的并发量比较小

7. 项目中有遇到比较困难的问题吗

同一个子任务，但是不同的升级目标，在子任务的对象里加了一个钩子函数，每次设备升级时检查有没有相同mac的旧任务在升级。有，就先让旧任务结束，直接执行新的任务。

10. 在静默升级中，用了什么中间件做存储呢

redis和mysql，redis做临时的缓存，存储每个子任务的详细信息，mysql最后打印报表

11. redis用的什么存储方式呢

hset，哈希存储，mac是key，升级相关信息是value

12. 说一下channel

回答了无缓存和有缓存，无缓存用于通知是在静默升级系统里用到，每个Task同时只能有一个处于创建升级子任务的状态，子任务创建完后执行升级。但是创建的状态同时只能有一个Task（没想明白为什么，防止并发问题？如果有同时多个任务里，有相同mac的子任务，那么不知道最后执行完的是哪个，可能没法升级到最新的版本，有可能是中途有问题的版本。可能出现高版本向低版本升级的i情况，有些设备允许，但有些不允许，可能会导致设备直接不可用）。

13. GC，写屏障是解决之前三色标记法的什么问题

直接回答的八股

深圳小鹅网络技术 一面

1. 询问测试环境是否分开，是否是docker搭建
2. 能源数据报告的优化，怎么优化

也说了预缓存一些电量水量的数据，因为结构都一样，这样更快

3. MQ消息的有序

回答：解析因为使用了幂等性，状态跳转才会有触发推送，那么不管是否有序或者重复消费无所谓

4. App的http请求在到达后端的链路是什么样的，经过了什么服务或者网关
5. 设计一个秒杀系统，怎么保证库存的一致性和不超限

回答：消息队列做请求缓存，限流熔断限制流量，下单操作只操作缓存，并异步更新到数据库，减轻数据库压力，接口限流、用户身份验证保证流量安全。保证一致性采用多级缓存（先更新数据库，在更本地，在更redis）

6. 多级缓存的话，现在有11个请求，有可能同时读redis，这时读到同样的数据。减11次会出现库存-1的情况，怎么解决呢

开源中国 一面

1. 介绍自己项目的模块的亮点

回答：说了一个GRPC的通信

2. MQ消费端没有正常消费的话，可能有什么原因
3. 是否了解mq或者kafka的具体消息机制还是原理什么的，有点忘了

这个直接说的只是简单的消费，不是太深

4. mysql的隔离级别
5. redis就在项目中用做缓存吗
6. 是否用过k8s
7. nginx用过，修改过一些参数

回答：只是修改了nginx的日志地址，还有代理的节点，其他没用过

早日上岸！

我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。

没准能让你能刷到自己意向公司的最新面试题呢。

感兴趣的朋友们可以加我微信：wangzhongyang1993，备注：面试群。

本文首发在我的同名公众号：王中阳Go，未经授权禁止转载。