Marten事件存储中混合租户模式下的流版本冲突问题解析

问题背景

在使用Marten作为事件存储系统时，当项目同时采用单租户(Single Tenancy)和联合租户(Conjoined Tenancy)混合模式时，如果不同租户上下文中使用了相同的流ID(Stream ID)，在快速追加(Quick Append)模式下可能会出现内联投影(Inline Projection)停止更新的问题。

问题现象

具体表现为：

1. 系统同时存在单租户表和联合租户表
2. 在单租户表和某个租户的联合租户表中使用了相同的流ID
3. 当切换到快速追加模式后，单租户投影更新变得不可靠

根本原因分析

问题的根源在于Marten生成的upsert函数中对于流版本号的查询逻辑。对于单租户表，生成的SQL查询语句缺少租户ID过滤条件：

SELECT version into current_version FROM app.mt_streams WHERE id = docId;

而当事件存储配置为TenancyStyle.Conjoined时，mt_streams表中会存在多个租户的数据。如果不同租户上下文中使用了相同的流ID，这个查询会返回多行结果，而数据库返回的顺序是不确定的。

当查询返回的是其他租户的流版本号时，如果该版本号高于当前操作的版本号，投影更新就会静默失败，因为系统误认为当前版本已经高于要更新的版本。

技术细节

在快速追加模式下，Marten会为每个投影生成专门的upsert函数。对于联合租户表，生成的函数会包含租户ID过滤条件：

SELECT version into current_version FROM app.mt_streams WHERE id = docId AND tenant_id = tenantid;

但对于单租户表，生成的函数缺少这个关键过滤条件，导致在多租户环境下可能出现版本号获取错误的问题。

解决方案建议

1. 代码修复方案：

   • 对于标记为TenancyStyle.Single的文档，在事件存储配置为TenancyStyle.Conjoined时，生成的upsert函数应该在版本查询中显式限定租户为默认租户(*DEFAULT*)
   • 这可以确保单租户文档的版本查询不会与其他租户的流混淆

2. 架构设计建议：

   • 避免在不同租户上下文中重用相同的流ID
   • 考虑为单租户数据使用专门的ID命名空间
   • 如果必须混用，可以考虑在应用层添加前缀或后缀来区分不同租户上下文的数据

3. 临时解决方案：

   • 可以手动修改生成的upsert函数，添加租户过滤条件
   • 或者重构数据模型，确保流ID在全局范围内唯一

最佳实践

1. 流ID设计原则：

   • 即使在单租户场景下，也建议设计全局唯一的流ID
   • 可以考虑使用组合键(如租户ID+业务ID)作为流ID的基础

2. 租户隔离策略：

   • 明确区分单租户和联合租户数据的边界
   • 为不同类型的数据建立清晰的命名规范

3. 版本控制：

   • 在混合租户环境中，特别注意版本控制策略的一致性
   • 考虑添加额外的日志记录来监控版本更新过程

总结

这个问题揭示了在复杂租户环境下事件溯源系统设计的一些潜在陷阱。开发者在设计系统时应该：

1. 充分理解不同租户模式的特点和限制
2. 建立严格的ID生成和管理策略
3. 在混合租户环境中特别注意数据隔离和版本控制
4. 对关键操作添加适当的日志记录以便问题排查

通过遵循这些原则，可以避免类似问题的发生，构建更加健壮的事件溯源系统。