永久终止Actor的EntityStoppedManifest日志条目清理最佳实践

你遇到的EntityStoppedManifest（"CD"条目）残留不属于设计缺陷，是Akka（Akka.NET）集群分片开启remember-entities功能后的默认内置行为：该标记是分片管理器用来记录实体已终止的标识，避免集群脑裂、分片重平衡时，意外复活你明确要求钝化且不复用的GUID会话实体，你主动调用DeleteSnapshots、DeleteMessages接口只会清理实体自身的业务快照和事件，不会触及分片层生成的系统标记条目。

• 首选内置自动清理策略
  绝大部分场景不需要自行实现清理逻辑，集群分片插件本身提供了已终止实体的 retention 配置，可直接在HOCON配置中指定已终止实体标记的保留时长，系统会后台自动异步清理过期的CD条目，参考配置示例：

  akka.cluster.sharding {
    remember-entities = on
    entity-retention = 7d # 可根据你的会话归档需求自定义时长
  }
  

  该方案无需改动业务代码，性能损耗可忽略，是官方推荐的标准处理方式。
• Janitor Actor手动清理的适用场景
  只有当你需要自定义清理规则（例如需要关联业务侧的会话归档逻辑、使用的是自研的事件日志存储不支持内置retention策略）时，再单独实现Janitor Actor做手动清理，实现时需遵守两个核心规则：
  • 仅清理已经完成业务数据清理（即已经调用过DeleteSnapshots、DeleteMessages返回成功）的实体对应的CD条目，避免误删正常运行中、或者正在执行钝化流程的实体标记
  • 批量清理任务必须做限流、错峰处理，避免大流量扫表打满事件日志的IO资源，影响线上正常业务
• 根源性优化方案（符合你的业务场景）
  因为你的会话实体用唯一GUID标识、终止后完全不会复用，不需要分片管理器记录实体状态做恢复，可直接关闭remember-entities配置：

  akka.cluster.sharding.remember-entities = off
  

  注意：关闭后分片重平衡、集群重启时不会自动恢复已经钝化的实体，刚好匹配你的业务特性，关闭后系统完全不会生成CD条目，从根源上避免了残留问题，是成本最低的优化方案。

你的现有业务逻辑是符合规范的：一次性会话绑定唯一GUID、终止时主动清理持久化数据、调用Context.Parent.Tell(new Passivate(PoisonPill.Instance))通知分片管理器回收资源，整套流程没有设计缺陷，CD条目残留是分片组件的默认系统行为，不需要调整业务侧的会话处理逻辑。

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