highlight: a11y-dark theme: Chinese-red
往期硬核面经
前几篇文章分享了上岸大厂（尤其是腾讯）的最新面经。
不少粉丝股东留言说上岸大厂太难了，有没有好上岸的中小厂的最新面经。
必须安排，今天分享一位朋友社招的面经：
富途 一面
- http相较于https多了什么步骤？
- https证书为什么一边是对称加密，一边是非对称加密（没有回答出来）
解析：非对称加密是为了保护证书里的对称密钥，服务器只能用对应的私钥解密拿到里面的对称密钥，后续沟通时就通过证书里的密钥进行对称加密沟通
- tcp挥手为什么有第四次
- time_wait阶段在哪里，为什么需要2MSL的长度
- 大量连接处于time_wait阶段可能有什么与原因，怎么解决?
回答：大量连接同时关闭，关闭连接时加上随机偏移值 解析：当大量短连接被快速创建和关闭时，会有大量的连接同时处于TIME_WAIT状态。 解决方法：
- 调整TCP参数：在服务器上调整TCP参数，比如减少TIME_WAIT的持续时间或增加可用端口范围。
- 使用长连接：避免频繁建立和关闭连接。可以通过使用长连接（例如，持续的数据库或API连接）来减少进入TIME_WAIT状态的连接数量
- 负载均衡：使用负载均衡技术分散请求，以减少单一服务器上的连接数。这样可以平均分配连接负载，减少任一服务器上TIME_WAIT状态的连接数量。
- 连接池：对于数据库或其他需要频繁建立连接的服务，使用连接池可以避免频繁地打开和关闭连接，因为连接池允许连接被重用。
- 浏览器输入回车后，发生了什么
- 一道算法题：分段阶梯计费
- 面试官提醒了一些问题：最后一个阶段是（左界限 --- .....）之前的循环条件是按右界限来计算的。 回答：那应该最后一个阶段，单独判断下
- 如果后面分了很多阶段，代码有什么优化的地方吗？ 没有想出来，不知道咋优化
- 一道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;
索引设计 对于这个查询，可以设计以下索引：
- 用户表 (user)：
- 主键索引在 uid 字段上（通常在创建表时自动设置为主键）。
- 帖子表 (thread)：
- 一个复合索引在 uid 和 create_time 字段上，这有助于快速筛选出每个用户的最新帖子。
确定索引的使用
要确定 SQL 会使用哪个索引，可以在执行 SQL 查询之前使用 EXPLAIN 或 EXPLAIN ANALYZE 命令（取决于具体的数据库管理系统）。这将显示查询的执行计划，包括是否使用了索引以及使用了哪些索引。
在 MySQL 中，则可以使用：
EXPLAIN FORMAT=JSON SELECT ...
查询是否最优
虽然上述查询可能在大多数情况下都能很好地工作，但如果数据量非常大，这个查询可能会变得缓慢，因为需要对所有用户进行聚合和排序。为了优化这个查询，可以考虑以下策略：
- 确保数据库使用适当的索引进行 JOIN 和 ORDER BY 操作。
- 对 thread 表的 uid 字段创建索引可以帮助加速分组和排序操作。
- 如果查询仍然较慢，可以考虑物化视图，预先计算并存储结果，特别是如果这个查询频繁执行而数据变化不大时。
在查询优化和索引策略中，需要根据实际数据量和数据库性能测试结果来不断调整和优化。
童心制物 一面
- 弹窗推送是负责哪部分
负责从MQ拿到数据解析后给下游服务，同事做极光推送
- 有改进或者特殊的点吗
- 数据消息体的格式化，不同的topic的消息体不一样，代码写起来很麻烦，所以直接做了格式化，数据就在payload里面，其他的也在对应字段上。
- 跟具体解析业务代码的数据交互是通过RPC，因为一个消息可能有多种业务的处理需要，这些也都需要想用返回，所以用了RPC的服务流。
- 弹窗是有定时和实时的吗
是的，根据设备上报的协议字段做相关推送
- 工作中并发是怎么应用的呢，看简历上写了errgroup
电量api查询时，比如一个月的用电，可能需要查一个月的每日用电量、当前一个月的累计用电、前一个月的累计用电。把一个大的任务分成多个小的任务，去并发调用执行，增加了接口的响应速度
- 这期间会出现什么问题吗，比如查询不出来，或者超时怎么办
查询不出来就置为0，然后能在报表上看见。 这个地方不知道怎么咋说。
- 又遇到过什么并发问题吗？
没有，说业务的并发量比较小
- 项目中有遇到比较困难的问题吗
同一个子任务，但是不同的升级目标，在子任务的对象里加了一个钩子函数，每次设备升级时检查有没有相同mac的旧任务在升级。有，就先让旧任务结束，直接执行新的任务。
- 在静默升级中，用了什么中间件做存储呢
redis和mysql，redis做临时的缓存，存储每个子任务的详细信息，mysql最后打印报表
- redis用的什么存储方式呢
hset，哈希存储，mac是key，升级相关信息是value
- 说一下channel
回答了无缓存和有缓存，无缓存用于通知是在静默升级系统里用到，每个Task同时只能有一个处于创建升级子任务的状态，子任务创建完后执行升级。但是创建的状态同时只能有一个Task（没想明白为什么，防止并发问题？如果有同时多个任务里，有相同mac的子任务，那么不知道最后执行完的是哪个，可能没法升级到最新的版本，有可能是中途有问题的版本。可能出现高版本向低版本升级的i情况，有些设备允许，但有些不允许，可能会导致设备直接不可用）。
- GC，写屏障是解决之前三色标记法的什么问题
直接回答的八股
深圳小鹅网络技术 一面
- 询问测试环境是否分开，是否是docker搭建
- 能源数据报告的优化，怎么优化
也说了预缓存一些电量水量的数据，因为结构都一样，这样更快
- MQ消息的有序
回答：解析因为使用了幂等性，状态跳转才会有触发推送，那么不管是否有序或者重复消费无所谓
- App的http请求在到达后端的链路是什么样的，经过了什么服务或者网关
- 设计一个秒杀系统，怎么保证库存的一致性和不超限
回答：消息队列做请求缓存，限流熔断限制流量，下单操作只操作缓存，并异步更新到数据库，减轻数据库压力，接口限流、用户身份验证保证流量安全。保证一致性采用多级缓存（先更新数据库，在更本地，在更redis）
- 多级缓存的话，现在有11个请求，有可能同时读redis，这时读到同样的数据。减11次会出现库存-1的情况，怎么解决呢
开源中国 一面
- 介绍自己项目的模块的亮点
回答：说了一个GRPC的通信
- MQ消费端没有正常消费的话，可能有什么原因
- 是否了解mq或者kafka的具体消息机制还是原理什么的，有点忘了
这个直接说的只是简单的消费，不是太深
- mysql的隔离级别
- redis就在项目中用做缓存吗
- 是否用过k8s
- nginx用过，修改过一些参数
回答：只是修改了nginx的日志地址，还有代理的节点，其他没用过
早日上岸！
我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。
没准能让你能刷到自己意向公司的最新面试题呢。
感兴趣的朋友们可以加我微信：wangzhongyang1993，备注：面试群。
本文首发在我的同名公众号：王中阳Go，未经授权禁止转载。