哈啰出行 JAVA开发 一面 面经

拼多多 暑期实习 二面，总共用时1h 左右， 被面试官疯狂拷打， 估计凉凉。首先介绍项目， 对方完全不感兴趣： 你做的这些和后端开发有什么关系？我简单介绍了下后端相关的，面试官可能觉得太简单了，没有继续问。然后就是痛苦的手撕拷打，持续50mins 左右。问题1： 给你两个班级， 每个班级共有 k 个人，你是班主任，要从每个班级中挑出1个人，使得他们的身高差最小。回答： 先排序， 然后遍历A班级，二分查找B班级中的第一个大于等于（lower_bound）A班级里的那个 的位置，然后比较那个位置和前一个位置。面试官和我不太同频，问我为什么要找第一个大于等于？二分查找不就是找一个位置吗？ 面试官笑眯眯的问我是第一次接触二分搜索吗？然后计算时间复杂度。感觉完全不同频。问还有更优解法吗？回答双指针，还是固定遍历A， 然后另一个指针从B开始找比A大的，然后在和前一个也比较，取最小的。这样就是O(n).面试官提示一下，不要局限在当前这个和前一个比较，换种思路。 然后我一直在思考，对方问我双指针要怎么初始化？  因为我还没想好，就没回答。面试官： 双指针要怎么初始化？这你都不懂吗。。。？ 怎么不回答我。我说新思路还没想好，面试官表示刚才那种思路的双指针要怎么初始化？ 答：都初始化在第一个位置。问题2： 两个班级， 换成 N 个班级， 每个班级选1个人， 要求算出来的人里的 max - min 最小。答没思路， 面试官提示下多个指针？ 考虑下指针应该如何移动。我想了想，移动最小的那个指针，直到所有指针都走到末尾，每次移动，从这个N个人里面取最大的，最小的，比较。然后算时间复杂度：n个班，每个班k个人，  我想整体的数据规模是 N = n*k ， 然后我用 N 去后续表示。面试官：你为什要定义新的符号N？ 算完时间复杂度，问我“从这个N个人里面取最大的，最小的”这部分可以优化吗？ 我回答可以使用 map （cpp里的），面试官表示你直接说数据结构，不要说语言中的名字。问这个的时间复杂度，答logn面试官：那你开始写吧。写了大概 3 分钟。 他看了眼。问题3： ping 100ms  ， curl http://1.2.3.4:8080/hello  需要多少时间？这里我考虑了4次挥手， 面试官：需要考虑这个吗？答 200ms. 问题4： 直播间，打赏金额最高的100个用户？ 你应该如何实现维护？我回答使用 redis 的 zset ，  可以高效的获取top 100.面试官问：这样有什么问题吗？ 如果用户特别多的情况。我想了一会，也没想出什么问题，回答没什么思路。面试官：用户太多了会有 大 key 问题， zset 删除的时候会阻塞几秒。 （我不太理解）面试官：你应该考虑怎么优化？答： string 配合 zset 使用， string kv 中存 user, money,  而 zset 中只维护 top 100 的。同时更新这俩。最后， 反问部门业务：拼多多直播带货。技术栈： 面试官看我的简历里面，cpp 太底层了我们这边不用，golang 也不用，主要是 java ， 然后 redis， mysql, kafka这些。面试官问我懂不懂二分， 我当时多少有点生气💢， 不过总的来说面试官人还不错，还算友善，给了很多引导。

专栏简介161. Kafka分区机制与多实例环境下的消息顺序性Kafka通过分区（Partition）机制来提高吞吐量和实现负载均衡。在单个分区内部，Kafka能够保证消息的严格顺序性，即消息按照生产者发送的顺序被存储和消费。如果生产者将一系列消息指定发送到同一个分区，并且这些消息都成功写入，那么消费者在拉取该分区的消息时，将严格按照发送顺序接收到它们。然而，在多实例部署的生产者环境中，即使指定了分区，也可能出现消费者感知到的消息顺序与预期不符的情况。这主要源于以下几个因素：首先，多个生产者实例并发地向同一分区发送消息时，网络延迟、客户端处理速度差异以及Broker端的处理时序可能导致消息实际...

实习情况：1.四月一号开始的实习，目前一个半月了2.组内转正几率低，竞争很激烈，之前和mentor聊建议我多学点写到简历上秋招面试有东西聊（感觉是明示不好转正了😂）3.目前组内项目技术方案的文档还有代码仓库学的七七八八，跟着mentor做了一些小需求，代码不复杂，偏数据处理（用公司内kafka，redis的sdk实现些小功能之类的），还有些写sql、调api接口的代码。学校情况：1.一般6月末要中期答辩，需要提前回校一段时间准备2.二月下旬开始找的实习，按6月20回校算的话找实习+实习本身合起来将近四个月没去过实验室了😂回校后导师再放实习可能性不大往年6月底开始中期答辩。需要提前回校准备，大概6月20附近就该走了应该6月20日直接离职or回校和导师硬刚中期后再回来实习？

https://jiekun.dev/posts/dev-node-distributed-tracing-with-victorialogs/谈到可观测性，人们总是会提起它的三大支柱：Metrics, Tracing, 和 Logging。在 VictoriaMetrics，我们已经有了 Metrics 和 Logging 的解决方案 VictoriaMetrics 和 VictoriaLogs。同时我们也一直听到很多声音，其中之一就是：VictoriaTraces 什么时候发布。如果你也关心这个问题，那么相信这篇博客可以让你了解我们内部对 Distributed Tracing 解决方案的...