📚 课程目录第2章高频面试问题与回答框架

高频面试问题与回答框架

本章聚焦 Ruby 微服务面试中最高频的三类问题：技术原理、架构设计、生产问题排查。面试官通过这些问题考察候选人的深度、广度以及系统化思维。以下先给出通用答题框架，再配合三个典型问答卡片进行实战训练。

问题类型	典型提问	答题侧重	字节跳动/TMD	阿里/美团
技术原理	Rack 中间件栈、线程安全	源码级理解 + 对比	性能与并发细节	中间件/框架扩展性
架构设计	微服务拆分原则、服务发现	方案对比 + 你的取舍	高可用、容错设计	一体化拆分演进
生产排查	线上假死、慢请求、内存泄漏	定位思路 + 工具链	实时排查 & 监控联动	全链路日志 & 根因分析

面试官考察点：对 Rack 规范的理解深度，中间件可扩展设计，线程安全考量。
回答框架：三段式：① 点明本质（Rack 是 Web 服务器与应用间的接口标准）→ ② 展开原理（call 方法、@app 链式调用、env 贯穿）→ ③ 项目关联（我在 XX 项目实现了一个请求耗时统计中间件，注意了线程安全）。
简短示例回答：（约80字）“Rack 定义了一个全链路调用协议，每个中间件实现 call(env) 并调用 @app.call(env) 传给下一个。我在订单服务中写了一个 LatencyMiddleware，记录每个请求的时间并上报 Prometheus，因为 Rails 默认线程安全，我用了 Thread.current 来传递上下文。”
可能追问：如果中间件里发生异常怎么处理？多个中间件的顺序如何控制？
⚠️ 避坑提醒：不要只说“中间件就是 before/after 钩子”，面试官要看你对 call 链和 env 的理解；不要忘记说线程安全。

面试官考察点：架构解耦意识，数据所有权理解，分布式事务权衡。
回答框架：① 点明本质（共享数据库是微服务反模式，导致紧耦合）→ ② 展开原理（每个服务应拥有自己的数据存储，通过 API 通信）→ ③ 项目关联（我之前在老项目中遇到订单与库存共用 MySQL，后拆分时用了事件驱动 + Saga 模式来解决一致性问题）。
简短示例回答：（约85字）“共享数据库会使服务间产生隐性耦合，改变 schema 要协调多个团队。我重构商城时，把订单和库存的公共表拆成各自私有存储，通过 RabbitMQ 发布事件来同步库存变化，并用本地事务表 + 补偿事务保证最终一致性。”
可能追问：为什么不直接用分布式事务（XA）？Saga 模式和两阶段提交的区别？
⚠️ 避坑提醒：不要直接说“不能共享”，要承认历史遗留情况下可临时共享但给出演进方案；也不要只停留在理论，要有具体技术选型。

面试官考察点：问题定位方法论，Linux 工具（strace/gdb），Ruby 内部机制（GIL、线程调度）。
回答框架：① 点明本质（假死通常由线程阻塞、死锁或慢外部调用导致）→ ② 展开原理（先用 kill -3 拿线程 dump，检查所有线程状态；再看系统调用是否卡在 I/O）→ ③ 项目关联（我曾用 strace -p 发现一个 Redis 连接池获取超时导致所有 worker 饥饿，改为非阻塞连接后解决）。
简短示例回答：（约90字）“先看 puma stats 确认所有线程 busy，执行 kill -3 <pid> 拿到 dump 发现 20 个线程都在等待 Mutex。用 strace 看到大量 futex 调用，定位到是 Sidekiq 中间件误用了全局锁。改成按队列锁后恢复。”
可能追问：如果 dump 里全是 IO.select 怎么办？如何区分 genuine 死锁和性能瓶颈？
⚠️ 避坑提醒：不要只背诵命令列表，要说明排查逻辑（先现象→工具→定位→解决）；切忌说“我直接重启”，面试官要你展示根因分析能力。