恒生电子 10.9 面经（项目偏多）

《面试题目》

1. 自我介绍。
2. 针对你项目里的选型（如 Redis 和 RabbitMQ）进行针对性询问：在你的项目中是怎么实现的？
3. MySQL 相关的问题：最好把你的任务流程串联起来，问你「为什么存在这里」。
4. 压力测试相关：项目的目标值是多少？慢 SQL 优化是怎么做的？现在让你重新设计，你会怎么设计？
5. 基础八股（超基础版）。
6. 反问。

《参考解析》

「为什么用 Redis / 为什么用 RabbitMQ」这类选型题要用「不选它会怎样」来答。以缓存为例：接口读多写少、数据量小于内存、能接受短暂不一致，才适合上 Redis；要能说出不上的后果（数据库 QPS 打满、P99 时延上升），也要能说出上的代价（缓存一致性怎么维护、雪崩怎么防、内存成本多少）。RabbitMQ 的落点通常是业务解耦、削峰填谷、异步通知，要能说清消息的可靠性三段：生产端用 publisher confirm + 重试、broker 用持久化队列 + 镜像/quorum 队列、消费端用手动 ack（处理成功才确认）加幂等消费。面试官问「怎么实现的」时不要停在选型理由上，要给具体参数和链路：缓存用什么 key 结构（String 还是 Hash）、过期时间怎么定、更新策略是先更新库再删缓存还是基于 binlog 失效；MQ 的交换机类型、路由键设计、消息体格式、重试与死信队列配置。能报出真实数字（队列积压峰值、缓存命中率）最有说服力。

「把任务流程串起来，问你为什么存在这里」是这题的灵魂。 面试官想看的是你能从「一个模块的实现」上升到「数据在整个链路里怎么流」。答题模板是：一次请求进来 → 经过哪些层 → 在这一层做了什么判断 → 数据落到哪里 → 为什么这一层要存在（不做会出什么问题）→ 下游怎么取用。比如「消息表为什么存在」的答案不是「用来存消息」，而是「它是本地事务和异步投递之间的桥：业务写入和消息记录在同一个本地事务里，保证业务成功则消息一定不丢，再由投递任务负责发出并重试」。把每个组件的存在理由都说成「它解决了哪一类失败」，这一段就会很有说服力。

压测目标值与慢 SQL 优化这两问通常连着问。压测的目标值要来自业务：日活 × 人均请求 ÷ 有效时长 × 峰值系数，再留 2–3 倍余量；指标要同时看 TPS、P95/P99 时延、错误率和资源水位（CPU、内存、连接池、GC）。要能说出「并发加到多少 TPS 出现拐点、拐点处哪个资源先到顶」——这才是压测的产出，单纯报一个 TPS 数字没有意义。慢 SQL 优化的标准动作：先用慢查询日志（long_query_time）和 Rows_examined 排序找到 TOP N，再用 EXPLAIN 看执行计划，重点看 type（出现 ALL 就是全表扫）、key（是否用上索引）、rows（预估扫描行数）、Extra（Using filesort、Using temporary 都是坏信号）；然后按情形处理——缺索引就补联合索引并遵守最左前缀、回表多就做覆盖索引、深分页就改游标或延迟关联、OR/函数导致失效就改写 SQL、数据量太大就归档或分区。改完必须复测并对比扫描行数和 P99 时延，形成闭环。

「重新设计你会怎么做」是加分题，要敢承认现有设计的不足并给出演进路径。可以按「当前的问题是什么 → 如果重来会在哪一层改 → 为什么这样更好 → 代价是什么」来答。例如当前用单表存订单、量上来后查询变慢：重来会把冷热数据分开（近期热数据保留在 MySQL，历史归档到冷存储）、把统计类查询从主库挪到从库或 OLAP、把强一致的扣减收敛到单库单表，跨库的部分改用本地消息表做最终一致。要说清代价（复杂度上升、运维成本、开发周期），不要只画理想架构——面试官更想听你是否有成本意识。最后「反问」环节建议问具体的东西：这个岗位负责哪条产品线、团队的技术栈与发版节奏、新人上手的前三个月大概做什么，比问「公司文化怎么样」有效得多。