Scala分布式系统工程师面试宝典 - 第4节
第4章 Akka与Actor模型：生命周期、消息传递、监督策略、路由器
本章聚焦Akka核心概念在分布式系统中的面试高频考点。围绕Actor生命周期、消息传递保证、监督策略选择、路由器模式展开，每个知识点均以“面试官视角+可迁移回答”形式呈现，帮助你在面试中快速定位考点并给出结构化答案。
面试问题：阐述Akka Actor的生命周期，以及如何在代码中监听生命周期事件？
面试官考察点：对Actor管道化生命周期的理解深度；是否了解preStart、postStop、preRestart、postRestart等钩子方法；能否结合业务场景说明监管时机。
回答框架：
- 总述Akka Actor生命周期5个阶段：创建→启动→处理消息→停止→资源释放。
- 核心方法：
preStart()（初始化）、postStop()（清理）、 - 实战示例：使用
context.watch(childActor)接收Terminated消息实现自动监控。
preRestart(reason, message)（重启前保存状态）、postRestart(reason)（重启后恢复）。
示例回答：“Actor生命周期包括创建、启动、消息循环、停止和回收。我通常在preStart()中初始化数据库连接，在postStop()中释放资源。同时通过context.watch()监听子Actor的死亡，实现全链路监控。”
可能追问：① 重启时如何保证消息不丢失？② 如果preStart中抛出异常，生命周期如何演进？③ ActorRef与Actor路径的区别？
避坑提醒：避免在
postStop()中执行耗时操作，否则会阻塞Actor系统关闭；重启时务必清理旧状态，防止内存泄漏。面试问题：Akka中消息传递的保证级别有哪些？如何实现“至少一次”或“恰好一次”语义？
面试官考察点：是否区分“最多一次”和“至少一次”在Akka中的默认行为；是否了解
AtLeastOnceDelivery和PersistentActor；能否给出实际限流/重试方案。回答框架：
- Akka默认提供“至多一次”传递（异步、无确认）。
- 实现“至少一次”：使用
AtLeastOnceDelivery+ 带确认的ACK协议（如ask模式 + 超时重试）。 - 实现“恰好一次”：结合
PersistentActor事件溯源（Event Sourcing） + 幂等接收者。 - 工程简化：利用
ActorLogging记录DeliveryId，配合context.become实现重试状态机。
示例回答：“Akka保证最多一次。我在订单系统中用AtLeastOnceDelivery配合超时重试，在接收端维护幂等表，最后用PersistentActor持久化确认状态，达到业务级恰好一次。”
可能追问：① 如何防止消息重复消费？② 分布式环境下消息顺序如何保证？③ Akka与Kafka在传递语义上的区别？
避坑提醒：不要在生产环境直接使用
tell实现“至少一次”，必须搭配确认机制；重试间隔要加指数退避，避免风暴。面试问题：Akka监督策略如何配置？对比OneForOne和AllForOne在路由场景下的选择差异。
面试官考察点：是否掌握
SupervisorStrategy配置方式；能否结合路由器区分策略应用场景；是否了解默认策略Escalate的传播机制。回答框架：
- 监督策略由父Actor定义，通过
SupervisorStrategy.stoppingStrategy或自定义配置。 - OneForOne：子Actor失败仅重启自己，适合无状态或独立计算任务。
- AllForOne：子Actor失败将重启所有兄弟，适合强一致性场景（如两阶段提交中的协调器）。
- 路由器场景：
RoundRobin/ConsistentHashing通常搭配OneForOne；Broadcast搭配AllForOne确保全部分组一致。 - 使用
SupervisorStrategy.customStrategy可根据异常类型（如ArithmeticException）返回不同指令。
示例回答：“在支付路由Actor中我用OneForOne，单个子Actor失败不影响其他渠道。但在批量订单处理中改用AllForOne保证事务一致性，一旦某个子Actor异常，所有子Actor都重启并回滚状态。”
可能追问：① 自定义策略如何判断
Escalate与Restart的边界？② 路由器中supervisingStrategy与SupervisorStrategy的优先级？③ 全局监督与本地监督的层级如何设计？避坑提醒：不要对所有异常一律使用Restart，如
NullPointerException可能是代码缺陷，应Escalate到顶层；路由器子Actor的监管权在路由器创建时已委托给父Actor，勿重复配置。项目案例：Akka分布式订单处理系统
项目名称：实时订单路由与状态管理平台
| 维度 | 内容 |
|---|---|
| 业务背景 | 电商大促期间订单峰值50万/s，需保证每个订单被可靠路由至下游仓储、支付、物流微服务，不允许丢单或重复处理。 |
| 规模指标 | 100个Akka节点集群，每秒处理50万消息，99.99%可靠，TP99响应<5ms。 |
| 技术栈 | Akka Cluster + Cluster Sharding + AtLeastOnceDelivery + Consul服务发现。 |
| 核心难点 | ① 海量Actor下生命周期管理带来的GC压力；② 部分下游不可用导致消息积压；③ 跨数据中心监督策略差异化。 |
| 面试高频追问 | ① 如何设计路由器避免热点Actor？② 监督策略升级到AllForOne后怎样防止雪崩？③ 如何测试监督策略的正确性？（答案要点：用TestKit模拟异常，验证重试次数和状态恢复） |
| 可迁移回答话术 | “在这个项目中，我们采用ConsistentHashing路由器将订单ID映射到特定分片Actor，同时为每个分片Actor配置OneForOne监督策略+指数退避。当下游服务返回临时失败时，子Actor自动重试；如果连续失败次数超过阈值，则Escalate到分片监护人进行灰度降级。这种设计复用到了后来的支付链路改造中。” |
面试提示：在项目介绍中，务必先说明“业务背景→技术挑战→具体Actor设计→监督策略选择→最终效果”，让面试官看到你从问题到方案的完整推演能力。