[RFC] 将 Orleans 与 Event Sourcing 持久化后端从 Garnet 切换为 MongoDB

[jason-aelf]

背景

目前 Aevatar 的部分 Orleans runtime state 和 Event Sourcing state 由 Garnet / Redis-compatible provider 承载。本讨论评估是否将这些非缓存持久化状态切换为 MongoDB，并明确开源 provider 的覆盖范围、当前实施阻塞项以及测试环境的切换边界。

当前 Garnet 中的数据全部属于测试数据，可以整体丢弃。本讨论不设计生产数据迁移，也不建议为这些测试数据建设 export/import、双写、回填或兼容读取能力。

TL;DR

• Garnet Cluster 使用异步 primary-replica replication，非计划故障转移不是严格 RPO=0：客户端已经收到成功响应的写入仍可能位于尚未复制的 AOF tail 中。
• Garnet Cluster 是 passive cluster，leader election、故障检测、promotion、topology convergence 和 fencing 依赖外部 control plane。
• 本文涉及的六类状态都不是普通缓存；未来用于生产时，丢失会破坏 actor 恢复、持久化调度、stream control plane、membership 或 committed domain events。
• 当前数据只是测试数据，因此建议整体清空 Garnet 状态，以空 MongoDB database 启动并重新创建测试 workload，不做历史数据迁移。
• Orleans.Providers.MongoDB 可以覆盖 named grain storage、reminders 和 clustering，但当前 Orleans 10 兼容性与 Protobuf serialization 尚未验证。
• Aevatar IEventStore 没有可直接替换的 MongoDB 开源实现，需要实现 MongoDB adapter 并通过与现有 Garnet 实现共享的 contract tests。

为什么考虑替换 Garnet

Garnet Cluster 的数据丢失窗口

Garnet Cluster 的 sharding 与 replication 解决的是不同问题：sharding 只分布 key space，不会自动为每个 shard 提供冗余；每个 primary 仍需要单独配置 replica。

replica 通过异步复制跟随 primary 的 AOF offset，因此存在两类确认窗口：

1. 启用 AOF 但未启用 WaitForCommit 时，primary 返回成功不代表写入已经完成本地 AOF commit。
2. 即使启用 WaitForCommit，它也只等待 primary 本地 AOF commit，不等待 replica 确认。

Garnet 当前不支持 Redis WAIT 和 WAITAOF，应用无法通过标准命令要求 replica 或多个 AOF 实例确认后再把写入视为成功。因此 primary 突然不可恢复时，已确认但尚未复制的 AOF tail 可能丢失，promotion 后的 replica 会表现为状态或版本水位回退。

故障转移能力边界

Garnet Cluster 是 passive cluster。Garnet 节点维护 slot、primary-replica 和 replication 状态，但完整的故障检测、选主、promotion、fencing 与客户端 topology convergence 需要由 Kubernetes operator 或其他外部 control plane 负责。

当原 primary 仍可访问时，普通 CLUSTER FAILOVER 可以暂停写入并等待 replica offset 追平后再 promotion，从而降低计划切换的数据丢失风险。但 primary 突然故障或使用 CLUSTER FAILOVER FORCE 时，无法保证复制尾部已经追平。

因此 Garnet Cluster 可以提供分片、副本和故障恢复基础，但不能单独承诺“客户端确认成功的写入绝不丢失”。这与 committed domain events、actor state 等业务权威持久态的目标存在差距。

MongoDB 本身也不自动等于零数据丢失。未来生产部署仍必须明确 replica set、journaling、write concern、read concern、transaction、故障转移以及备份恢复策略。

哪些状态需要切换

当前用途	状态性质	丢失后的主要影响	MongoDB 替换路径
Orleans grain state	长期 actor 权威与恢复状态	actor identity、topology、Protobuf snapshot、snapshot version 和 publication checkpoint 丢失，actor 无法正确恢复	Mongo named grain storage；需要验证 Orleans 10 和 Protobuf serializer
Runtime callback scheduler state	长期或调度生命周期内的持久态	callback payload、generation、next-due time 等丢失，timeout、retry 和周期任务无法恢复	Mongo named grain storage；必须提供专用 Protobuf serializer
Orleans Reminder	持久化调度注册表	reminder 丢失后，即使保留 callback state，scheduler grain 也可能永远不会被唤醒	UseMongoDBReminders(...)；需要验证 Orleans 10、多 silo ownership、重启与注销行为
Orleans PubSubStore	运行时控制面持久态	producer/subscription rendezvous 和 ETag 状态丢失或冲突，可能阻断 stream 与 projection pipeline	Mongo named grain storage；必须替换 Redis-specific maintenance 实现
Orleans clustering/membership	运行期权威协调状态	运行中丢失或分裂会造成 membership 异常、短暂分裂或不可用	UseMongoDBClustering(...)；生产环境要求 MongoDB replica set 与 transaction 支持
GarnetEventStore	最重要的业务权威持久态	committed domain events 丢失后 actor state 无法完整重放，生产环境中属于不可恢复的数据损失	没有直接兼容的开源实现，需要自研 MongoDB IEventStore adapter

这些状态在生产语义上都不能当作普通缓存。但当前 Garnet 数据只是测试数据，所以“状态很重要”与“本次必须保留旧数据”是两个不同问题。

建议的测试环境切换边界

建议将六类状态作为同一个测试环境重置边界处理：

• 丢弃全部旧 grain state、callback state、reminder、PubSubStore、membership 和 event stream；
• 不实现 Garnet 到 MongoDB 的 export/import、dual-write、backfill、legacy-read fallback 或反向同步；
• 不校验旧 event payload hash、stream version、snapshot version 或 publication checkpoint；
• 停止所有旧 silo、client 和 gateway，确保旧 backend 不再接受写入；
• 初始化空 MongoDB collection、index 和 provider schema；
• 启动只使用 MongoDB 的新集群，再重新创建测试 agent、event、callback、reminder 和 stream subscription。

不能保留旧 grain snapshot 却清空 event stream，也不能保留 callback state 却清空 reminder registration。即使旧数据没有保留价值，这类混合状态仍会制造版本、恢复和调度不一致。

如果未来出现必须保留的生产数据，应另行编写生产切换 ADR 和数据迁移方案，不应为当前测试数据提前建设迁移基础设施。

开源支持与实施阻塞项

仓库当前使用 Microsoft Orleans 10.0.1，中央包版本声明了 Orleans.Providers.MongoDB 9.5.0，但尚未实际引用。当前已知边界如下：

• Mongo provider 覆盖 named grain storage、reminders 和 clustering。
• Mongo provider 9.5.0 依赖 Orleans 9.0.1 相关包；上游 Orleans 10 WIP PR #158 已关闭且未合并。
• Mongo provider 默认 serializer 不能直接替代仓库要求的 Protobuf state contract，需要实现或适配 named storage serializer。
• PubSubStore 可以由 Mongo named grain storage 承载，但现有 Redis-specific cleanup/maintenance 逻辑必须替换。
• Orleans.Providers.MongoDB 不实现 Aevatar IEventStore；MongoDB adapter 必须保持 optimistic concurrency、atomic batch append、ordered read、Protobuf payload、corruption detection 和 compaction contract。

采用 MongoDB 前需要验证

• Orleans 10.0.1 下 provider 可以编译、启动并通过 multi-silo integration tests。
• Named grain storage 支持 provider isolation、ETag optimistic concurrency 和 Protobuf round trip。
• Callback state 在重启后保持 generation、payload 和 next-due time，reminder 能正确触发、对账和注销。
• Mongo PubSubStore 可以从空 store 完成 producer/subscriber registration，并具备新的 maintenance 实现。
• Mongo clustering 在 replica set 上通过 membership、gateway discovery、完整重启和 primary failure 测试。
• Mongo IEventStore adapter 通过与 Garnet 实现共享的 contract tests。
• 空库创建新 agent 和 event 后，完整重启可以正确恢复 grain state、event version、snapshot 和 publication checkpoint。
• MongoDB 使用明确的 journaling、write concern 和 transaction 设置，并验证实际 durability 与 failover 语义。

本次希望确认的问题

1. 是否同意将上述六类非缓存状态统一切换到 MongoDB backend？
2. 是否接受当前测试数据整体丢弃、MongoDB 空库启动，并明确不建设数据迁移工具？
3. 对 Orleans.Providers.MongoDB，应优先完成 Orleans 10 兼容性验证，还是直接维护仓库内可控的适配/fork？
4. 是否同意将 MongoDB IEventStore adapter 作为独立实现，并要求它与 GarnetEventStore 共享同一组 contract tests？

范围外

IRuntimeSecretStore、tool admission ledger、identity assertion replay guard 和 workflow webhook replay admission 不属于本讨论范围。这些 secret 或 TTL admission/replay state 需要按各自的一致性、过期和故障转移要求单独评估。

参考资料

• Garnet Cluster overview
• Garnet Cluster replication
• Garnet compatibility and durability options
• Garnet Redis command compatibility
• Orleans.Providers.MongoDB
• Orleans.Providers.MongoDB 9.5.0
• Orleans 10 WIP pull request #158