往期硬核面经

哦耶！冲进腾讯了！

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

腾讯的面试，强度拉满！

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

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

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

富途 一面

1. https 相较于 http 多了什么步骤？

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_countFROM user uJOIN thread t ON u.uid = t.uidGROUP BY u.uid, u.usernameORDER BY post_count DESCLIMIT 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，未经授权禁止转载。