如题，秋招与字节的拉锯战从八月一直持续到十一月，期间经历过1、广告业务捞面 三轮技术面，一轮hr面，两周后排序挂2、搜索广告捞面，重新从一面开始，但三面挂3、剪映社区捞面，也是从一面开始，四天面完三场，但第三场面试的内容让我不得不怀疑，我好像被耍了，如下：剪映三面的面试官摄像头都不开，所有问题都是浅浅的问一问，全程有气无力，手撕之字形层序遍历树，用了两层循环，但所有节点只遍历一遍，时间复杂度已经为O(n)了，却说让我再想想O(n)的解法，解释已经是O(n)后回复了“哦”，遂到反问环节，一个问题只回复一两句话，最后结束面试时整整1小时，一分钟不多一分钟不少。剪映三面目前还没出结果，不过也已经无所谓了，从八月初到现在秋招已经持续了三个月，一边实习一边秋招太累了。不论结果好坏，最后这一场字节的面试就当作今年秋招的收尾吧，最后祝大家都能拿到满意的offer

请问这种是没过还是在横向呀 😭😭😭

字节剪映二面1. 你两个练手项目中遇到过什么难点？或者有思考过参考资料范围外的问题吗？2. 缓存不一致出现的场景、原因及具体解法是什么？3. 先更新数据库再删除缓存的策略，存在哪些边界 case？会怎么发生？4. 延迟双删的第二次删除是在什么时候？该怎么设计逻辑？5. 删掉缓存后，只允许第一个请求读数据库并更新缓存，其他请求被锁住，这个设计是为了实现什么？6. 构建缓存的请求失败了怎么办？7. 为什么选择让未拿到锁的请求直接返回旧数据，而不是让它们等待锁或重试？这种方案的好处和坏处分别是什么？8. 构建缓存请求失败时，继续等锁和直接返回旧数据哪种方案更占优？9. 你实现缓存相关的锁时，用的是什么方式？10. Java 中 HashMap 的底层数据结构是什么？11. 直接用红黑树实现 Map 功能是否可行？HashMap（哈希表+开链/红黑树）与全红黑树实现的 Map 各有什么优劣？12. HashMap 如何解决容量不够的问题？Java 中的扩容是怎么做的？13. 如何避免触发扩容阈值的那次写操作承担所有数据搬迁开销？14. 有办法将扩容的开销均摊出去吗？具体怎么操作？

1.实习介绍2. 你刚才说全链路 10ms 内，这个“10ms”的统计口径具体是从哪到哪？是否包含撮合？如果不包含，柜台内处理和SDK 通信层各占多少？实际压测数据大概是怎么样的3. 说一个最近一次的容量上限：平峰 QPS、行情峰值 QPS、触顶现象是什么4. 为什么选Disruptor而不是LinkedBlockingQueue5.userId%128 做分片——如果用户写或者查很频繁倾斜怎么监测？当有三五个高频量化用户扎堆到同一分片，你们是怎么处理6.迁移前后的有序性怎么保证？7. 第一阶段和第二阶段双层 RingBuffer 的拆分依据是什么8.业务逻辑、持久化、推送为什么不放在一个阶段里用不同handler9.你们是事件源还是只是“事件日志 + 最终态”？RocksDB里存事件还是快照？快照生成策略是什么10.baseLog和RocksDB的边界点是什么？如果RocksDB 落地成功但baseLog→MySQL异步失败怎么办11. 说你们做的是真改单不是撤下重下。那由10个BTC调到11个时，增量冻结要做两阶段么，怎么做，撮合拒绝后怎么回滚呢12.市价改单vs限价改单的冻结口径什么区别？盘口估算失败时你们有保护系数吗？精度/最小变动价位校验放在第一阶段还是SDK前面13.改单失败场景列举一下？比如订单已撮合、深度变更、风控锁定、余额变化、系统切分片迁移中。每种失败的用户可感知到的行为和状态的回退分别是什么样的14. 你们那个柜台和撮合通信的SDK 的发送队列和接收队列是批量阈值触发，那批大小是静态还是自适应？峰值时批过大对尾延迟的影响怎么去抑制呢15.rokesDB 写放大/读放大/空间放大这些你们怎么权衡？用了哪些compaction 策略16. 压测时出现RocksDB 写吞吐低，你们改成128分片、8线程写8库？你们为什么要这么去分，依据是什么，128个分片会不会太多17. 统一账户上线前，你们老柜台如何兼容限额？母账户限额、币对限额、池子限额、档位限额的冻结时机分别是什么？新老系统共用/分开配置怎么保证一致呢18.自动借币/还币是Try/Confirm/Cancel 还是最终一致补偿？借币失败是不是要回滚下单