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 还是最终一致补偿？借币失败是不是要回滚下单