StackSaga 事件存储 (Event Store)
事件存储 (Event Store) 是一种专门设计用于存储连续状态变更事件（Events）而非仅保留最终状态的日志或数据库。 在 StackSaga 中，您可以直接通过划分独立 Schema 的方式复用您现有的主业务数据库作为事件存储，而无需单独维护一套全新独立的数据库系统。 这极大地降低了运维开销以及维护多套异构数据库的管理复杂度。
在 StackSaga 中，您可以按照每个微服务独立数据库 (Database per Service) 的标准微服务模式来配置事件存储。
| 尽管技术上允许多个服务共用同一个集中式事件存储，但在生产环境中并不推荐这样做，因为这会引入潜在的性能瓶颈、单点故障风险，并且违背了微服务自治的设计原则。 |
为什么要在事件存储中持久化事务状态？
-
可靠的重试机制 (Reliable Retries)
当执行因抛出
RetryableExecutorException（例如网络暂时闪断）而失败时，StackSaga 能够进行安全可靠的重试。 在微服务架构中，诸如网络波动之类的瞬态故障绝不应直接视为不可挽回的最终异常，因为分布式事务通常横跨多个服务，任何下游服务都可能出现短时间不可用。 通过在事件存储中持久化每个事务的中间执行状态，StackSaga 确保失败的执行能够可靠地断点重播重试，从而彻底规避数据丢失或状态不一致的风险。 -
追踪分析与监控审计 (Analysis and Monitoring)
StackSaga 提供了专门的可视化控制台——StackSaga Trace-Window 链路追踪窗口——用于实时监控事务追踪链路并审查排查错误。 界面上展示的所有事务拓扑数据均源自事件存储，事务执行记录安全持久化于其中，供随时进行审计、分析与故障诊断。
StackSaga 数据库支持模块体系 (Database Support Modules)
stacksaga-database-support 模块家族为基于 StackSaga 框架构建的应用程序提供了可插拔的持久化层抽象。
它将特定数据库的底层细节进行了抽象封装（包括 Schema 结构管理、数据库连接管理、幂等性 Saga 状态存储、补偿操作回滚日志、Outbox/事件持久化等），使得 StackSaga 的核心功能（流程编排、重试调度、补偿回滚、可观测性）能够在不同的底层存储引擎上完全一致地运行。
同时，它还为 StackSaga TraceWindow 链路追踪控制台 (Dashboard) 提供了访问链路追踪详情所必需的内置 REST API。
官方推荐的做法是：根据您编排器服务所采用的主业务数据库类型，选用对应的数据库支持模块。
例如，如果编排器服务的主业务数据库是 MySQL，那么对应的支持模块即为 stacksaga-mysql-support。
|
正如架构图所示，重试子系统 (Retry Subsystem) 会向编排器服务下发重试请求。 为了连通编排器服务，相关的内置管理端点均由数据库支持模块负责提供。详情请参阅各具体数据库支持实现的文档。 |
目前支持的数据库实现 (Implementations of Database Support)
目前 StackSaga 提供以下数据库支持实现：
| 数据库 (Database) | 支持模块 (Module) | 描述说明 (Description) | 数据库类型 (Type) |
|---|---|---|---|
MySQL |
针对 MySQL 关系型数据库的支持实现 |
SQL |
|
PostgreSQL |
针对 PostgreSQL 关系型数据库的支持实现 |
SQL |
|
Oracle |
针对 Oracle 企业级数据库的支持实现 |
SQL |
|
SQL 分区支持 |
SQL 数据库（MySQL 与 PostgreSQL）的集中式自动化分区维护支持 |
SQL |
|
Cassandra |
针对 Apache Cassandra 分布式 NoSQL 数据库的支持实现 |
NoSQL |
|
ScyllaDB |
针对 ScyllaDB 超高性能 NoSQL 数据库的支持实现 |
NoSQL |