nautilus-event-store 深度解析：NautilusTrader 确定性交易引擎的嵌入式事件日志、校验与回放

事件溯源（Event Sourcing）是 NautilusTrader 确定性架构的基石：nautilus-event-store crate 在消息总线边界捕获所有影响状态的消息（命令、生成事件、原始交易所回报、对账输出、请求/响应流量），将其持久化为按运行（run）组织的只读日志，并据此支撑回放、审计与完整性校验。本文以该 crate 的 README 为主线，结合仓库源码与 事件溯源概念指南，系统讲解其设计契约、存储模型、写入/回放/校验链路、生命周期选项与实操命令，帮助你掌握在 NautilusTrader 中"以日志重建确定性状态"的完整工程方法。

一、定位：嵌入式事件存储与权威状态日志

nautilus-event-store 是一个单节点、嵌入式的事件存储，服务于一个交易实例（one trading instance）的一次运行。它不是独立的数据库服务，而是以 Rust crate 的形式内嵌在交易进程内，作为"影响引擎状态的消息的权威日志（authoritative log）"。

它捕获的四类流量（见 README）：

• 命令（commands）：提交、修改、撤销订单等执行命令；
• 生成事件（generated events）：引擎内部生成并跨总线分发的各类事件；
• 原始交易所回报（raw venue reports）：对账（reconciliation）合成派生事件之前的原始执行回报；
• 请求/响应流量（request/response traffic）：跨总线且影响状态的请求与响应消息，以及对账输出。

这些消息被持久化为"每次运行的持久日志（durable per-run log）"，并对外暴露只读的校验与回放接口。

需要特别强调的是（README 明示的边界，crates/event_store/README.md）：

• 它不替代数据目录（data catalog）——流式行情数据仍留在 catalog 中；
• 它不提供 OLAP 查询或分析；
• 它不把多个交易实例聚合成共识日志。

另外，README 明确标注该 crate 目前处于 Early alpha 阶段（README）：API 不稳定，可能在版本间变更，当前工作重心是事件捕获、回放与校验工作流。在使用与引用时应注意这一前提。

二、设计契约：确定性从何而来

事件存储是"确定性引擎历史"的持久化边界，其设计契约（README）定义了整套系统的信任模型：

1. 同步核心是确定性的（The synchronous core is deterministic）；
2. 缓存是直写投影（write-through projection），不是真相源——cache 回答"现在是什么"，事件存储回答"Nautilus 是如何走到这一步的"；
3. 回放从捕获历史与命名的确定性回放规则中推导状态；
4. 事件存储记录有序的输入与生成的状态影响消息；
5. 任何未被记录的内容，要么是非状态影响的，要么被命名为确定性回放规则；
6. 外部 I/O 只有被捕获为原始回报（raw reports）或命令（commands）后才变得可回放。

这套契约在 事件溯源概念指南 中被进一步阐述为"为什么需要事件溯源"：缓存只能回答"现在为真的是什么"，而事件存储能让读者、回放工具和校验器在不依赖策略逻辑、交易所查询或活动缓存的情况下，解释过去的状态是如何形成的。它提供了持久化的能力基础：证明密封运行文件在回放/归档前是否干净、检查某个订单/组件意图背后的确切命令与回报序列、从快照锚点加运行尾部重建缓存状态、追踪一个意图引发的引擎侧消息链、以及在进程退出或写入器停机后封存过期的运行文件。

与 DST（确定性模拟测试）的关系

事件存储与确定性模拟测试（DST）解决回放的不同侧面（docs/concepts/event_sourcing.md）：

• 事件存储提供捕获的输入历史；
• DST 控制调度、时间、种子化随机数等范围内的非确定性。

两者结合，可以让一次运行在确定性模拟范围内复现引擎行为。Manifest 中记录的 seed、binary_hash、config_hash、schema_version 正是识别此类可复现运行的输入。在 cfg(madsim) 下，写入器以同步方式提交（不再衍生写入线程），配合通过生命周期选项注入的 MemoryBackend 开启器，捕获可完全在进程内完成、无需 redb 文件——这为模拟场景提供了确定性的 seq 顺序。

三、组件地图：这个 crate 提供什么

根据 README 与 lib.rs 公共导出，crate 提供以下核心构件：

组件	职责
BusCaptureAdapter	消息总线分发与写入器之间的接缝（seam），在总线分发包装器内、消息到达下游处理器之前调用 capture
EventStoreLifecycleOptions	仅运行时的生命周期策略，用于自定义编码器注册表与后端开启器（backend opener）
EventStoreWriter	追加路径：负责批处理（batching）、推进高水位（high-watermark）、fail-stop 信号
EventStoreReader	只读的区间扫描（range scan）、单点查询与面向回放的表面
RedbBackend	默认磁盘后端，每个运行一个 redb 文件
MemoryBackend	进程内后端，用于聚焦测试与模拟式捕获
Verifier	针对单次运行做完整性检查的库级接口
verify	独立的可执行文件，用于对密封运行文件的进程隔离校验
plan_redb_retention	针对密封运行文件回收候选的非破坏性规划器
ReplayInputPlan	按 seq 排序的计划事件存储条目，可选附带类型化 catalog 切片计划
ReplayInputs	已加载的按 seq 排序回放条目，可选附带按所选切片分组的 catalog 记录

这些构件在源码中的组织为：backend/（EventStore trait 与两种后端实现）、capture/（总线捕获适配器、编码器与注册表）、writer/（写入器、批处理器与 halt 回调）、reader/（只读读取器）、verifier/（完整性校验）、replay/（回放输入规划与目录桥接）、retention/（保留规划）、markers/（数据标记侧车）等模块，入口见 lib.rs。

四、捕获流水线：从消息总线到磁盘

捕获发生在消息总线分发边界（message bus dispatch boundary），因此"tap"能看到每个状态影响消息在被下游处理器观察到之前的形态（docs/concepts/event_sourcing.md）：

flowchart LR
    Producer["Engine, adapter, strategy, or component"] --> Bus["MessageBus publish/send"]
    Bus --> Tap["Capture tap"]
    Tap --> Adapter["BusCaptureAdapter"]
    Adapter --> Writer["EventStoreWriter"]
    Writer --> Backend["redb run file"]
    Bus --> Handlers["Downstream handlers"]
    Backend --> Reader["Reader, replay, verifier"]

捕获分支与分发同源，但捕获是异步的，不是分发上的接受门：一次成功的捕获只是把条目入队给写入器；写入器线程随后分配下一个 seq、提交一个批次，并在后端确认持久化之后推进高水位。读者则通过一个不暴露任何追加操作（append）的只读表面来扫描密封或运行中的后端。

写入器：有界通道、批处理与 fail-stop

EventStoreWriter 在源码中拥有一个后端实例，并通过有界 sync_channel 接收提交（writer/mod.rs）。WriterConfig 的默认参数（writer/mod.rs）：

配置项	默认值	含义
channel_capacity	10_000	提交与写入线程之间待处理条目的有界通道容量
max_batch_entries	100	强制提交前最多累积的条目数
max_batch_latency	5ms	批次最长累积时间，到时强制提交
halt_threshold	250ms	提交侧停滞上限，超过即触发 halt 回调

背压契约（docs/concepts/event_sourcing.md）：背压永远不会静默丢弃一个已接受的条目——一个停滞超过 halt_threshold 的提交会触发 halt 信号；而后端提交失败是另一回事，它会确实丢失排队中的批次：写入器触发 halt 信号、丢弃待处理批次并结束循环，因此这些条目永远不会持久化。

fail-stop 不中断运行（docs/concepts/event_sourcing.md）：tap 记录失败日志，消息仍到达其处理器；halt 后 tap 停止记录，本次会话剩余部分不再被捕获。没有任何运行时组件轮询 halt 信号来停止交易器；是下次启动时的恢复扫描（recovery sweep）负责封存该运行——若尾部干净则封存为 CrashedRecovered。

去重：同一个逻辑消息只落一条

某些消息会合法地跨多个 tap 可见的边界：执行引擎把订单事件发往投资组合端点、又在策略 topic 上发布同一事件；交易命令从策略到风控再到执行多次跳转。由于同一消息的重复分发发生在单个引擎周期内，捕获适配器用一个有界窗口去重最近捕获的消息身份（事件 id、命令 id）（docs/concepts/event_sourcing.md）。

源码中该窗口实现在 capture/adapter.rs：RECENT_IDENTITY_CAPACITY = 128 的插入有序队列 + AHashSet，采用 FIFO 淘汰（note_fresh 对已见身份返回 false 以跳过重复）。每个逻辑消息最终只成为一条条目，回放不会把同一事件应用两次。

no-drop 契约

适配器的 no-drop 契约（capture/adapter.rs）：来自写入器的任何 SubmitError 都会恰好触发一次适配器的 halt 回调（即使写入器自身的 halt 路径尚未触发，例如调用方在外部关闭了写入器），并作为 CaptureError::Submit 呈现；随后的捕获调用以 CaptureError::Halted 短路，不再重新进入写入器，从而保证卡死或已关闭的写入器不会静默吞掉捕获。

五、存储模型：redb 后端与"每运行一文件"

默认后端是 redb——一个纯 Rust 的 ACID 键值存储（README 如此描述；README）。后端使用每个运行一个文件的布局：

<base>/<instance_id>/<run_id>.redb

每个文件存储（README）：

• 以单调 seq 为键的条目（entries）；
• client_order_id 与 venue_order_id 二级索引；
• 运行开始时写入、运行结束时封存的 manifest；
• 用于缓存恢复的可选快照锚点（snapshot anchor）。

redb 后端的表结构在源码中定义明确（backend/redb.rs）：

const ENTRIES_TABLE: TableDefinition<u64, &[u8]> = TableDefinition::new("entries");
const MANIFEST_TABLE: TableDefinition<&str, &[u8]> = TableDefinition::new("manifest");
const CLIENT_ORDER_INDEX: TableDefinition<&str, u64> = TableDefinition::new("client_order_id_idx");
const VENUE_ORDER_INDEX: TableDefinition<&str, u64> = TableDefinition::new("venue_order_id_idx");
const SNAPSHOT_ANCHOR_TABLE: TableDefinition<&str, &[u8]> = TableDefinition::new("snapshot_anchor");

每次提交使用 Durability::Immediate（backend/redb.rs）：崩溃的写入器绝不能在重新打开后让未完成的尾部可见；高水位只在后端确认持久化之后才推进。

可互换的后端抽象

EventStore trait（backend/mod.rs）让后端可互换：模拟场景用进程内 MemoryBackend，生产用 redb，未来也可替换为自定义 WAL 或分段日志而不触及消费者。trait 表面不出现 redb::Database 等后端专属类型。后端负责：每运行的磁盘/内存组织、持久化提交语义、高水位推进、以及把后端错误映射为 EventStoreError。trait 不拥有批处理与线程管理策略——那是写入器的职责。

AppendEntry 把条目与其侧车索引键放在一次事务中原子提交（backend/mod.rs），读者永远不会观察到已提交 seq 却缺少二级索引的状态。批次的首个 seq 必须是 high_watermark + 1 且批次内连续，否则后端拒绝（EventStoreError::OutOfOrder）。

值得注意的源码细节（backend/redb.rs）：RedbBackend::open_sealed_file 是后端专属的只读入口——标准 open_run 路径拒绝已密封文件（这是崩溃恢复防护，后继者不得静默重开前任日志而不经过封存），而事件存储回放是合法读取密封文件的场景，因此读者使用该构造函数。它持有只读数据库句柄，对 append_batch 返回 EventStoreError::Closed。

六、条目模型、索引与哈希

每条事件存储条目是一次捕获的消息加元数据。EventStoreEntry（entry.rs）字段：

字段	含义
entry_hash	对前面所有字段的规范化哈希
seq	每次运行的单调序号，回放顺序的唯一权威
headers	一级关联（correlation/causation）元数据
topic	捕获该条目的总线 topic（复用 nautilus_common::msgbus::MStr<Topic> 幻影类型句柄）
payload_type	规范化负载类型标签（标识哪个编码器产生了 payload）
payload	规范化编码后的消息字节
ts_init	来自共享 AtomicTime 的域时间戳
ts_publish	总线接受或写入器接收的时间戳

时间戳只用于解释运行，不覆盖 seq 的顺序权威（docs/concepts/event_sourcing.md）。

二级索引只覆盖按 client_order_id 与 venue_order_id 的查询（backend/mod.rs）；correlation_id 索引在出现具体检查调用方需要时再添加，目前关联扫描可以遍历捕获流。索引是可从规范的 seq -> entry 表重建的投影而非权威存储——校验器正是重建它们并与存储行交叉核对。每个 (IndexKind, key) 对只记录首次出现（backend/mod.rs），因此 lookup 始终返回最早提到该键的 seq。

每条条目携带对整个内容的规范化哈希（crate 依赖 blake3 与 ahash 等哈希原语，见 Cargo.toml，并有专门的 hash 基准）；读者与校验器在每次读取时重算哈希，不匹配即报告（并可能导致运行被隔离）。

七、Manifest 与运行生命周期

RunManifest（manifest.rs）记录运行身份与可复现性输入，分为四组（详见 docs/concepts/event_sourcing.md）：

• 运行身份：run_id、parent_run_id、instance_id；
• 构建身份：binary_hash、schema_version、crate_versions、feature_flags、adapter_versions；
• 配置身份：config_hash、registered_components、seed；
• 生命周期状态：start_ts_init、end_ts_init、high_watermark、status。

RunStatus 有四种状态（manifest.rs）：Running（打开并接受写入）、Ended（优雅关闭并附 RunEnded 条目后封存）、CrashedRecovered（启动时发现无 RunEnded 条目而封存）、Quarantined（完整性检查失败，不可安全回放）。is_sealed() 即 status != Running（manifest.rs）。

运行生命周期（docs/concepts/event_sourcing.md）：新运行的第一个条目是 RunStarted；manifest 为 Running 期间，总线 tap 记录状态影响条目、缓存快照可针对持久化高水位记录锚点；干净关闭、内核 drop 或 reset/rerun 封存会追加 RunEnded 并将 manifest 封存为 Ended；fail-stop（halt）的会话跳过进程内封存，由下次启动的恢复扫描处理——且 halt 信号是按运行作用域的，之后的 open() 会重新武装新信号，一次 halt 不会污染同进程的后续运行。

恢复封存（Recovery sealing）

前任（predecessor）是同一实例的旧运行文件，其 manifest 仍为 Running，意味着上一次进程没有完成正常生命周期，或写入器在 manifest 封存完成前已停机。启动恢复扫描会为每个 Running 前任依据持久化尾部选择最终 manifest 状态（docs/concepts/event_sourcing.md）：

持久化尾部	封存状态	是否可作父运行
无条目	CrashedRecovered	是
干净、无 RunEnded	CrashedRecovered	是
干净、以 RunEnded 结尾	Ended	否
哈希不匹配、缺口或结构失败	Quarantined	否

该扫描绝不会因为一个运行文件损坏就让交易器无法启动。被硬杀死（SIGKILL、OOM、断电）的进程留下的文件 redb 会拒绝只读打开；列出时会回退到可写打开，先执行 redb 的修复流程再继续恢复。仍无法打开或缺少 manifest 的文件以日志错误跳过并在下次启动重试，因此恢复与保留操作可以继续覆盖健康运行。只有 CrashedRecovered 前任会成为 parent_run_id；配置的 replay_from_run_id 在验证后覆盖恢复出的父运行。

八、实战：校验密封运行文件（verify）

verify 是独立的二进制，用于对密封运行文件做进程隔离的校验（README）：

cargo run -p nautilus-event-store --bin verify -- /path/to/run.redb

退出码语义：

• 0：运行干净；
• 1：运行存在损坏发现，或校验工作进程中止/超时；
• 2：校验器无法打开或无法对指定文件运行。

为什么必须进程隔离（README 与 verifier/mod.rs）：某些损坏的 redb 文件在打开或首次读取时会 panic，而 release 构建使用 panic = "abort"；verify 二进制把扫描委托给一个工作子进程，坏文件中止的是工作进程而不是调用方。校验器通过只读 redb 句柄打开运行，并报告 quarantine=not-performed——隔离策略由主管（supervisor）或操作进程负责，校验器自身只报告、不突变运行文件。

完整性检查清单（README 与 verifier/mod.rs）：

• 重算每条条目的哈希；
• 检测高水位内部的缺口（gap）；
• 检查表键与内嵌 seq 的一致性；
• 将二级索引与条目交叉核对；
• 校验 manifest 状态与高水位字段（high_watermark 必须与持久化的最后一个 seq 一致，start_ts_init/end_ts_init 必须包住条目流，密封 manifest 的状态必须是终态）。

概念指南给出了输出示例（docs/concepts/event_sourcing.md）：干净输出如 clean run_id=1700000000-cafe0001 status=Ended high_watermark=3 entries_scanned=3 markers=absent；损坏输出则含 corrupt ... findings=1 ... quarantine=not-performed 与 - hash mismatch at seq 2 之类的具体发现。markers= 字段报告侧车扫描结果：absent（无侧车文件）、clean/corrupt（含快照、高保真、缺口与字典计数）、error（侧车存在但无法打开或扫描）。

大文件超时调整：

env NAUTILUS_EVENT_STORE_VERIFY_TIMEOUT_SECS=120 \
    cargo run -p nautilus-event-store --bin verify -- ./event_store/trader-001/1700000000-cafe0001.redb

需要留意"干净"判定的边界（docs/concepts/event_sourcing.md）：clean 只证明结构完整性，不证明可恢复性或捕获完整性——校验器检查快照锚点但不加载/哈希其 blob；标记校验把已记录的缺口计为覆盖；中途 fail-stop 的运行仅对其已捕获部分校验干净，对 halt 之后的消息不置一词。

九、从 Rust 读取密封运行

EventStoreReader 是只读回放、审计与校验扫描的规范入口（reader/mod.rs）：它持有后端、暴露分块迭代的区间扫描、单 seq 点查、二级索引查询与 manifest 访问，对运行中与已密封的后端一视同仁，且没有 append_batch 表面。

README 的完整示例（README）：

use nautilus_event_store::{EventStoreReader, RedbBackend, ScanDirection};

fn inspect_run() -> Result<(), Box<dyn std::error::Error>> {
    let backend =
        RedbBackend::open_sealed_file("./event_store/trader-001/1700000000-cafe0001.redb")?;
    let reader = EventStoreReader::new(backend);
    let high_watermark = reader.high_watermark()?;

    for entry in reader.scan_range(1, high_watermark, ScanDirection::Forward) {
        let entry = entry?;
        println!("{} {}", entry.seq, entry.topic);
    }

    Ok(())
}

源码细节：scan_range 支持 ScanDirection::Forward 与 Reverse 两个方向（backend/mod.rs）；分块扫描的默认块大小为 DEFAULT_SCAN_CHUNK_SIZE = 1_024（reader/mod.rs），让百万级条目的取证扫描保持有界的工作集，同时摊薄每次调用的事务开销，可通过 scan_range_chunked 调整。

十、生命周期选项：自定义编码器与后端开启器

EventStoreLifecycle::boot(...) 保持默认行为：打开 RedbBackend 并安装 default_registry()。高级调用方可通过 EventStoreLifecycle::boot_with_options(...) 传入仅运行时选项（EventStoreLifecycleOptions），而无需改动可序列化的 EventStoreConfig（README）。

在生命周期打开运行前注册自定义总线负载编码器：

use bytes::Bytes;
use nautilus_event_store::{
    EncodedPayload, EncoderRegistry, EventStoreLifecycleOptions,
};
use ustr::Ustr;

#[derive(Debug)]
struct AuditRecord {
    payload: Bytes,
}

let mut registry = EncoderRegistry::new();
registry.register::<AuditRecord, _>(Ustr::from("AuditRecord"), |record| {
    Ok(EncodedPayload::without_indices(record.payload.clone()))
});

let options = EventStoreLifecycleOptions::new().with_encoder_registry(registry);
// Pass `options` to EventStoreLifecycle::boot_with_options(...).

同一个选项类型还接受后端开启器（backend opener）：默认开启器保持 RedbBackend，而测试或模拟 harness 可以提供一个返回 MemoryBackend（或任何其他 EventStore 实现）的开启器。概念指南补充（docs/concepts/event_sourcing.md）：生命周期选项可替换三样东西——编码器注册表（或其按运行构建的工厂，在总线 tap 开始捕获前应用）、返回任意 EventStore 实现的后端开启器、以及数据标记提取器注册表工厂。MemoryBackend 开启器是模拟安全路径：DST harness 或聚焦测试可通过正常生命周期打开 MemoryBackend，保持同样的总线 tap 与写入器语义，封存后在进程内读取捕获条目，无需 redb 运行文件。

十一、回放：ReplayInputs 与缓存重建

回放遵循一条排序规则：按 seq 顺序应用事件存储条目。ts_init 与 ts_publish 解释消息发生时间，seq 才是持久的回放顺序（docs/concepts/event_sourcing.md）。

Rust 回放输入 API 把规划（planning）与执行（execution）分离：

• 仅事件存储的回放输入只返回条目；
• 目录连接（catalog-joined）的回放输入附加调用方选择的 catalog 切片以支持上下文分析。

Catalog 规划器接受显式 CatalogSliceSelector 值与只读 ReplayCatalog；规划从事件存储扫描解析 catalog 时间边界（除非选择器提供了显式边界）、报告缺失的 catalog 切片、并保持 seq 作为条目排序权威。加载返回 ReplayInputs：按 seq 排序的事件存储条目，加上按所选切片分组的 catalog 记录。

Rust 调用方可启用默认关闭的 persistence 特性，用 nautilus_event_store::ParquetReplayCatalog 包装 ParquetDataCatalog 来规划所选 catalog 文件与文件名派生的时间区间；桥接把 quotes、trades、bars 加载为类型化的 CatalogReplayRecord。注意该桥接是只读的：它使用 catalog 的发现与查询 API，但不写入 catalog；不支持的 catalog 类在回放为该类增加类型化负载契约之前会加载失败。

这些 API 不会（docs/concepts/event_sourcing.md）：打开实时交易所客户端、运行策略或 actor、重跑对账、删除文件、或回放时钟注册/取消生命周期。

内核管理的缓存回放与快照锚定恢复

内核管理回放使用 EventStoreConfig::replay_from_run_id（docs/concepts/event_sourcing.md）：设置后，内核从密封运行恢复缓存状态、把该运行记录为新鲜子运行的父运行、并跳过实时引擎/客户端/启动/交易所对账；Quarantined 运行被拒绝。回放还要求 load_state=true，否则内核记录错误并直接返回。缓存回放加载器是仅状态的：恢复缓存拥有的快照，按 seq 顺序扫描事件存储尾部，解码支持的缓存影响负载并直接应用到 Cache——支持合成账户/订单/持仓事件、捕获的订单列表、以及 instrument/quote/trade/funding rate/bar 的完整数据响应。它不会把回放条目发布到实时总线、不运行策略代码、不查询交易所、不跑对账、不重新派生标识符、不重新武装时钟。

快照锚定恢复（docs/concepts/event_sourcing.md）：缓存快照归缓存所有，事件存储只存快照锚点——快照时刻的高水位、一个不透明的缓存所有 blob_ref 与缓存所有的 content_hash。恢复先加载锚点指名的快照，再只应用高水位之后的条目。恢复场景按消息推进距离排序：入队前（生产者重试策略）、入队后提交前（批次未持久化，高水位不推进）、提交后锚点前（加载旧快照并回放尾部）、锚点后（加载最新快照并回放锚点之后）。回放正确性依赖四条检查：条目用不可变的 seq 寻址、写入拒绝乱序提交、读者检测高水位内部缺口、快照回放计划拒绝指向持久化高水位之后的锚点。

十二、保留规划：plan_redb_retention

保留（retention）以整个运行文件为回收单元。plan_redb_retention（以及库级 plan_retention）是非破坏性规划器：列出密封运行的 manifest、检查它们的最新快照锚点状态、返回候选运行文件供之后的监督/操作进程回收（README 与 docs/concepts/event_sourcing.md）。

三种模式：

• Full：保留每个密封运行，不返回任何回收候选；
• Bounded { keep_last }：保留最新的若干密封运行，同时至少保留一个已知良好的恢复点；
• SnapshotAnchored：只回收比最新已知良好恢复点更旧的密封运行。

"已知良好的恢复点"是密封、非 Quarantined、且带有效快照锚点（其高水位不超过运行的持久化高水位）的运行。规划器对照磁盘上实际存在的最后一条条目而非 manifest 记录值，因此被尾部裁剪的运行无法冒充恢复点；Running 运行永远不会被列为密封运行或回收候选；缺失/损坏/无效的快照锚点不计为恢复点，因此在无法证明至少存在一个结构有效的恢复点时不返回任何候选。检查在锚点处停止——规划器从不加载快照 blob，因此无法排除因 blob 缺失/改动而失败的恢复。

十三、特性标志与构建

crate 提供三个特性标志控制编译期源码包含（README 与 Cargo.toml）：

• defi：启用 DeFi（去中心化金融）支持；
• live：通过 nautilus-common 启用实时运行支持；
• persistence：通过 nautilus-persistence 启用 Parquet catalog 回放支持。

依赖方面（Cargo.toml），crate 构建在 nautilus-common、nautilus-core、nautilus-execution、nautilus-model、nautilus-system 之上，使用 redb（持久化）、blake3/ahash（哈希）、bytes、rmp-serde（MessagePack 序列化）、serde、ustr 与 indexmap 等依赖；库目标为 rlib（Cargo.toml），并提供 hash 与 codec 两个基准。

十四、测试覆盖：被钉住的关键正确性保证

事件存储的测试套件钉住了当前 alpha 表面上承重的正确性保证（docs/concepts/event_sourcing.md），对应集成测试位于 crates/event_store/tests/integration/（capture.rs、envelope.rs、lifecycle.rs、reader.rs、redb.rs、replay.rs、retention.rs、verifier.rs、writer.rs）：

• 默认编码器注册表覆盖经审计的状态影响捕获表面；
• 触发的 TimeEvent 通过 TimeEventHandler::run 命中已安装的事件存储 tap；
• 写入器在有界背压下 halt 而非丢弃已接受条目；
• 条目哈希校验能检测字节级负载损坏；
• 进程隔离校验把截断或零尾的运行文件报告为损坏；
• 缓存回放对生成的捕获事件流重建出与实时缓存一致的账户/订单/持仓状态；
• 跨多个总线边界分发的同一订单事件只被捕获一次；
• 解码失败或指向持久化高水位之后的快照锚点会作为校验发现呈现而非通过校验；
• catalog 连接回放输入规划覆盖所选切片、缺失切片、时间边界与 seq 排序；
• 崩溃恢复依据持久化尾部把 Running 前任封存为 Ended/CrashedRecovered/Quarantined，且只有 CrashedRecovered 运行成为父运行；
• 启动恢复能修复硬崩溃的运行文件，跳过不可读文件而不让扫描失败。

十五、延伸阅读

• 事件溯源概念指南：设计模型、捕获边界、回放模式、恢复、保留规划与操作示例（本文大量细节源自于此文档）；
• 本 crate 的 README 与 lib.rs 公共 API 导出：API 参考；
• crates/event_store/src/：backend/、capture/、writer/、reader/、verifier/、replay/、retention/、markers/ 等模块源码；
• crates/event_store/tests/integration/：上述正确性保证的集成测试。

总体而言，nautilus-event-store 以"每运行一文件 + 规范化哈希 + 进程隔离校验 + 快照锚定回放"四个支柱，为 NautilusTrader 提供了可证明的、确定性的引擎历史：写入路径以 Durability::Immediate 保证高水位只前进于持久化确认之后，读取路径以只读表面支撑审计与取证，校验路径以独立子进程隔离坏文件的 panic 风险，回放路径则以 seq 为唯一排序权威重建缓存状态。它是理解 NautilusTrader"从研究到实盘语义一致"这一整体架构的关键一环。