持久化Actor何时会被脱水/终止？ReceivePersistentActor生命周期问询

官方文档说明 #

Akka 官方提供了完整的 ReceivePersistentActor 生命周期、持久化机制相关的内置说明，你可以直接在对应版本的 Akka 官方文档的持久化模块、集群分片模块查询到所有规则定义。

非活动时长阈值规则说明 #

你提到的「非活动时长触发终止」是可配置的能力：

对应配置项为 akka.persistence.passivation-timeout，默认状态为关闭，只有显式配置了正数值才会生效
当该配置开启后，超过设定时长没有收到任何消息、也没有执行任何持久化操作的 ReceivePersistentActor 会被系统自动终止（脱水），释放内存资源给其他Actor使用。

其他触发持久化Actor终止的条件 #

• 显式终止操作：代码中调用context.stop(self)主动停止、父Actor停止时连带终止子级持久化Actor、收到PoisonPill/Kill系统内置终止消息，都会触发Actor终止，终止前会完成当前正在处理的持久化事件刷写，不会丢失已确认的持久化数据
• 持久化失败触发终止：如果事件写入持久化日志、快照写入快照存储失败，且达到配置的重试次数上限，Actor会自动抛出异常并终止，避免出现数据不一致的问题
• 集群分片被动清理：如果你的持久化Actor是通过集群分片管理的，开启了分片 passivation 策略的前提下，要么达到分片配置的单分片Actor数量上限、要么节点内存占用达到阈值，系统会按照最近最少使用规则，把最久未调用的持久化Actor自动终止（脱水）
• 集群节点异常：如果Actor所在集群节点主动下线、或者因为网络问题被集群判定为下线，该节点上所有运行的持久化Actor都会被直接终止

dehydrated与常规停止的差异 #

*dehydrated（脱水）*本质是仅销毁内存中的Actor实例，所有持久化日志、快照数据都会完整保留，后续再有消息发给该Actor时，系统会自动重新实例化该Actor、重放历史事件恢复状态，不会影响业务逻辑；而主动杀死/删除的持久化Actor如果同时清理了持久化数据，后续无法再恢复原有状态。

非预期Terminated状态排查建议 #

• 首先核查你的应用Akka配置中是否开启了akka.persistence.passivation-timeout，如果开启了确认阈值设置是否符合业务场景，大量低频次调用的持久化Actor很容易触发该规则被自动终止
• 检索对应Terminated Actor的业务日志，排查是否有持久化写入失败的报错日志，这类异常终止都会伴随明确的持久化错误堆栈
• 如果使用了集群分片管理持久化Actor，核查分片的passivation策略配置，以及对应时段节点的内存、CPU占用情况，确认是否是资源压力触发的被动清理

内容的提问来源于stack exchange，提问作者Brian Sain