PPIO - Serverless AI 后端 二面 一小时
Q1: 请简单介绍一下自己的情况
实习经历:
- 百度: 做架构相关和推理优化相关工作，包括模型路由（类似 Gateway）和推理性能优化
- 腾讯云: 反入侵组，主要做了两个项目：门神防火墙的流能力支持规则库运营平台建设
- Galxe: 链上相关工作，如交易并行化优化
开源经历: 参与 Apache Seata、Dubbo Admin、Kiwi 等项目，是 Apache Seata 的 Committer
Q2: 腾讯云的实习已经结束了吗？
A: 是的
Q3: 百度是在哪里实习？
A: 北京。
Q4: 你简历上写的路由转发系统能介绍一下吗？
A: 这是腾讯云门神防火墙的规则引擎部分。
系统架构:
- 流量从 STGW 网关接入
- 经过规则引擎（基于 Hyperscan 进行正则匹配）
- 再经过 Smart 引擎（在线小模型智能检测）
- 最后下放到具体的节流服务
我做的工作:
- 流能力支持: 原有 Block 模式需要等待所有 chunk 到达才能匹配，产生额外时延改进为 Stream 模式，利用 Hyperscan 的 Stream 特性设计 Time Window 机制，按 3-5 个 chunk 进行顺序校准和合并实现流式匹配，无需等待完整请求
Q5: 这个项目你具体做了哪些事情？项目组多大？
A:
- 项目组规模: 8-9 人
- 我的工作: 负责 Time Window 部分，利用 Hyperscan 已有设施进行兼容性改造，让它能和门神的窗口适配
Q6: 高并发请求转发系统是基于开源的还是自己实现的？
A: 是自己实现的，但这是一个比较简单的设施。
背景:
- 完成流能力后，发现 2M 以上的流量都没有报到门神
- 原因是 STGW 设置了 max package size 约 2M
- 开源组件大多是完整的流量网关，功能过于复杂
- 我们只需要简单地将 STGW 漏掉的流量接入到防火墙
Q7: 涉及到负载均衡吗？
A: 没有，可以理解为一个流量接入的 Pipeline。
Q8: 做这个事情的难点在哪里？有什么价值点？
A:难点:
- 不在开发本身（核心代码只有 200-300 行）
- 在于排查哪一块开始有流量漏报
排查过程:
- 发现规则引擎流量出口开始有 2M+ 流量缺失
- 逐步用 Mock 模块替换功能模块，只做流量统计
- 从引擎出口 → 匹配模块 → 接入 Pad → STGW 逐层排查
- 最终确认 STGW 网关出口有缺失
- 与网关确认是 max package size 参数配置问题
价值:
- 短期快速解决方案
- 单台 SA2(4C8G)机器可达 2400+/分钟吞吐量
- 每天 2000 万请求，5 台机器即可覆盖
Q9: 了解一致性哈希这个概念吗？
理解:
- 通过环形结构进行哈希映射
- 相比普通哈希，优势在于分布式环境下扩缩容时
- 可以根据扩缩容情况动态调整环上的点
- 保证哈希映射的正确性
Q10: 百度做的 Tarot 是什么？
A:背景:
- 大搜下游有多种模型，通过不同方式/框架部署
- Tarot 是流量接入层，统一请求格式
实现流程:
- 通过 NamingService 服务发现，解析获取 IP Port
- 根据请求类型（gRPC/Baidu RPC/OpenAI）判断
- 通过 Stub 做格式转换和封装成 Model Stub
- 交给调度组件做实际转发
我的工作: 主要是安全漏洞相关修复
Q11: 这个漏洞是你找出来的吗？
A: 安全部门定期扫描发现的，通过邮件抄送过来。
Q12: 所以你是修复了安全漏洞？重构配置解析逻辑是什么意思？
A:漏洞原因:
- 配置传递逻辑问题
- RouteTable 读取配置后，后续组件依赖这个配置传递
- 某个逻辑触发时会将配置传给非必经组件，但传递时被 null 掉
- 导致 NamingService 拿到的 Etcd 健全配置为空
隐蔽性:
- Etcd V2 和 V3 API 不统一
- 设置了相同的账号密码
- V3 开启限权后，用 V2 API 访问依旧不需要认证
- 所以即使逻辑触发，系统仍能正常运行
修复: 重构配置解析逻辑，规范化配置传递流程
Q13: Etcd 本身了解吗？它是做什么用的？
A:
- 主要做注册中心
- 本身是一个分布式 KV 服务
Q14: MVCC 这个概念了解吗？
Q15: MySQL 悲观锁怎么实现？
Q16: 乐观锁怎么实现？
Q17: 对容器 Docker 或 K8s 有接触吗？
Q18: 为什么需要用容器？有什么好处？
Q19: 环境隔离是怎么实现的？
A:
- 通过 Linux 本身提供的机制
- Namespace 和 CGroup
Q20: 对分布式事务是怎么理解的？
A:单机事务:
- 在单节点保证一组操作同时成功或同时失败
分布式事务:
- 在分布式环境下，跨节点保证事务组内操作同时成功或失败
- 区别在于大部分情况保证的是最终一致性
- 外部感知到是同时成功或失败，但中间过程不一定
Q21: 分布式事务实现上比较通用的算法有哪些？
A:
- 最常用的是两阶段提交（2PC）/TCC
- 大部分服务会自己定制 2PC
- 接入 Seata 等框架成本较高
Q22: Seata 对数据源有要求吗？
A:
- 取决于多 DB 支持情况
- Java 端进度快，MySQL/PG 等常见 DB 基本都支持
- Go 端进度慢，目前只有 MySQL 比较完整
Q23: 两阶段提交时，如果第二阶段有节点崩掉了，应该怎么恢复？回滚还是重试？
A:要看场景:
要求稳定性高的场景（如订单、支付）:
- 应该直接失败
- 如果没有备份节点或升格节点，不应该影响整个事务流程
- 避免重试影响用户体验
可接受延迟的场景（如后台任务）:
- 可以接受重试
- 只要保证最终对账正确即可
- 用户对此无感知
