nautilus-event-store 深度解析NautilusTrader 确定性交易引擎的嵌入式事件日志、校验与回放【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader事件溯源Event Sourcing是 NautilusTrader 确定性架构的基石nautilus-event-storecrate 在消息总线边界捕获所有影响状态的消息命令、生成事件、原始交易所回报、对账输出、请求/响应流量将其持久化为按运行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阶段READMEAPI 不稳定可能在版本间变更当前工作重心是事件捕获、回放与校验工作流。在使用与引用时应注意这一前提。二、设计契约确定性从何而来事件存储是确定性引擎历史的持久化边界其设计契约README定义了整套系统的信任模型同步核心是确定性的The synchronous core is deterministic缓存是直写投影write-through projection不是真相源——cache 回答现在是什么事件存储回答Nautilus 是如何走到这一步的回放从捕获历史与命名的确定性回放规则中推导状态事件存储记录有序的输入与生成的状态影响消息任何未被记录的内容要么是非状态影响的要么被命名为确定性回放规则外部 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在总线分发包装器内、消息到达下游处理器之前调用captureEventStoreLifecycleOptions仅运行时的生命周期策略用于自定义编码器注册表与后端开启器backend openerEventStoreWriter追加路径负责批处理batching、推进高水位high-watermark、fail-stop 信号EventStoreReader只读的区间扫描range scan、单点查询与面向回放的表面RedbBackend默认磁盘后端每个运行一个 redb 文件MemoryBackend进程内后端用于聚焦测试与模拟式捕获Verifier针对单次运行做完整性检查的库级接口verify独立的可执行文件用于对密封运行文件的进程隔离校验plan_redb_retention针对密封运行文件回收候选的非破坏性规划器ReplayInputPlan按seq排序的计划事件存储条目可选附带类型化 catalog 切片计划ReplayInputs已加载的按seq排序回放条目可选附带按所选切片分组的 catalog 记录这些构件在源码中的组织为backend/EventStoretrait 与两种后端实现、capture/总线捕获适配器、编码器与注册表、writer/写入器、批处理器与 halt 回调、reader/只读读取器、verifier/完整性校验、replay/回放输入规划与目录桥接、retention/保留规划、markers/数据标记侧车等模块入口见 lib.rs。四、捕获流水线从消息总线到磁盘捕获发生在消息总线分发边界message bus dispatch boundary因此tap能看到每个状态影响消息在被下游处理器观察到之前的形态docs/concepts/event_sourcing.md捕获分支与分发同源但捕获是异步的不是分发上的接受门一次成功的捕获只是把条目入队给写入器写入器线程随后分配下一个seq、提交一个批次并在后端确认持久化之后推进高水位。读者则通过一个不暴露任何追加操作append的只读表面来扫描密封或运行中的后端。写入器有界通道、批处理与 fail-stopEventStoreWriter在源码中拥有一个后端实例并通过有界sync_channel接收提交writer/mod.rs。WriterConfig的默认参数writer/mod.rs配置项默认值含义channel_capacity10_000提交与写入线程之间待处理条目的有界通道容量max_batch_entries100强制提交前最多累积的条目数max_batch_latency5ms批次最长累积时间到时强制提交halt_threshold250ms提交侧停滞上限超过即触发 halt 回调背压契约docs/concepts/event_sourcing.md背压永远不会静默丢弃一个已接受的条目——一个停滞超过halt_threshold的提交会触发 halt 信号而后端提交失败是另一回事它会确实丢失排队中的批次写入器触发 halt 信号、丢弃待处理批次并结束循环因此这些条目永远不会持久化。fail-stop 不中断运行docs/concepts/event_sourcing.mdtap 记录失败日志消息仍到达其处理器halt 后 tap 停止记录本次会话剩余部分不再被捕获。没有任何运行时组件轮询 halt 信号来停止交易器是下次启动时的恢复扫描recovery sweep负责封存该运行——若尾部干净则封存为CrashedRecovered。去重同一个逻辑消息只落一条某些消息会合法地跨多个 tap 可见的边界执行引擎把订单事件发往投资组合端点、又在策略 topic 上发布同一事件交易命令从策略到风控再到执行多次跳转。由于同一消息的重复分发发生在单个引擎周期内捕获适配器用一个有界窗口去重最近捕获的消息身份事件 id、命令 iddocs/concepts/event_sourcing.md。源码中该窗口实现在 capture/adapter.rsRECENT_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为键的条目entriesclient_order_id与venue_order_id二级索引运行开始时写入、运行结束时封存的 manifest用于缓存恢复的可选快照锚点snapshot anchor。redb 后端的表结构在源码中定义明确backend/redb.rsconst ENTRIES_TABLE: TableDefinitionu64, [u8] TableDefinition::new(entries); const MANIFEST_TABLE: TableDefinitionstr, [u8] TableDefinition::new(manifest); const CLIENT_ORDER_INDEX: TableDefinitionstr, u64 TableDefinition::new(client_order_id_idx); const VENUE_ORDER_INDEX: TableDefinitionstr, u64 TableDefinition::new(venue_order_id_idx); const SNAPSHOT_ANCHOR_TABLE: TableDefinitionstr, [u8] TableDefinition::new(snapshot_anchor);每次提交使用Durability::Immediatebackend/redb.rs崩溃的写入器绝不能在重新打开后让未完成的尾部可见高水位只在后端确认持久化之后才推进。可互换的后端抽象EventStoretraitbackend/mod.rs让后端可互换模拟场景用进程内MemoryBackend生产用redb未来也可替换为自定义 WAL 或分段日志而不触及消费者。trait 表面不出现redb::Database等后端专属类型。后端负责每运行的磁盘/内存组织、持久化提交语义、高水位推进、以及把后端错误映射为EventStoreError。trait 不拥有批处理与线程管理策略——那是写入器的职责。AppendEntry把条目与其侧车索引键放在一次事务中原子提交backend/mod.rs读者永远不会观察到已提交seq却缺少二级索引的状态。批次的首个seq必须是high_watermark 1且批次内连续否则后端拒绝EventStoreError::OutOfOrder。值得注意的源码细节backend/redb.rsRedbBackend::open_sealed_file是后端专属的只读入口——标准open_run路径拒绝已密封文件这是崩溃恢复防护后继者不得静默重开前任日志而不经过封存而事件存储回放是合法读取密封文件的场景因此读者使用该构造函数。它持有只读数据库句柄对append_batch返回EventStoreError::Closed。六、条目模型、索引与哈希每条事件存储条目是一次捕获的消息加元数据。EventStoreEntryentry.rs字段字段含义entry_hash对前面所有字段的规范化哈希seq每次运行的单调序号回放顺序的唯一权威headers一级关联correlation/causation元数据topic捕获该条目的总线 topic复用nautilus_common::msgbus::MStrTopic幻影类型句柄payload_type规范化负载类型标签标识哪个编码器产生了payloadpayload规范化编码后的消息字节ts_init来自共享AtomicTime的域时间戳ts_publish总线接受或写入器接收的时间戳时间戳只用于解释运行不覆盖seq的顺序权威docs/concepts/event_sourcing.md。二级索引只覆盖按client_order_id与venue_order_id的查询backend/mod.rscorrelation_id索引在出现具体检查调用方需要时再添加目前关联扫描可以遍历捕获流。索引是可从规范的seq - entry表重建的投影而非权威存储——校验器正是重建它们并与存储行交叉核对。每个(IndexKind, key)对只记录首次出现backend/mod.rs因此lookup始终返回最早提到该键的seq。每条条目携带对整个内容的规范化哈希crate 依赖 blake3 与 ahash 等哈希原语见 Cargo.toml并有专门的 hash 基准读者与校验器在每次读取时重算哈希不匹配即报告并可能导致运行被隔离。七、Manifest 与运行生命周期RunManifestmanifest.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.rsRunning打开并接受写入、Ended优雅关闭并附RunEnded条目后封存、CrashedRecovered启动时发现无RunEnded条目而封存、Quarantined完整性检查失败不可安全回放。is_sealed()即status ! Runningmanifest.rs。运行生命周期docs/concepts/event_sourcing.md新运行的第一个条目是RunStartedmanifest 为Running期间总线 tap 记录状态影响条目、缓存快照可针对持久化高水位记录锚点干净关闭、内核 drop 或 reset/rerun 封存会追加RunEnded并将 manifest 封存为Endedfail-stophalt的会话跳过进程内封存由下次启动的恢复扫描处理——且 halt 信号是按运行作用域的之后的open()会重新武装新信号一次 halt 不会污染同进程的后续运行。恢复封存Recovery sealing前任predecessor是同一实例的旧运行文件其 manifest 仍为Running意味着上一次进程没有完成正常生命周期或写入器在 manifest 封存完成前已停机。启动恢复扫描会为每个Running前任依据持久化尾部选择最终 manifest 状态docs/concepts/event_sourcing.md持久化尾部封存状态是否可作父运行无条目CrashedRecovered是干净、无RunEndedCrashedRecovered是干净、以RunEnded结尾Ended否哈希不匹配、缺口或结构失败Quarantined否该扫描绝不会因为一个运行文件损坏就让交易器无法启动。被硬杀死SIGKILL、OOM、断电的进程留下的文件 redb 会拒绝只读打开列出时会回退到可写打开先执行 redb 的修复流程再继续恢复。仍无法打开或缺少 manifest 的文件以日志错误跳过并在下次启动重试因此恢复与保留操作可以继续覆盖健康运行。只有CrashedRecovered前任会成为parent_run_id配置的replay_from_run_id在验证后覆盖恢复出的父运行。八、实战校验密封运行文件verifyverify是独立的二进制用于对密封运行文件做进程隔离的校验READMEcargo run -p nautilus-event-store --bin verify -- /path/to/run.redb退出码语义0运行干净1运行存在损坏发现或校验工作进程中止/超时2校验器无法打开或无法对指定文件运行。为什么必须进程隔离README 与 verifier/mod.rs某些损坏的 redb 文件在打开或首次读取时会 panic而 release 构建使用panic abortverify二进制把扫描委托给一个工作子进程坏文件中止的是工作进程而不是调用方。校验器通过只读 redb 句柄打开运行并报告quarantinenot-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_id1700000000-cafe0001 statusEnded high_watermark3 entries_scanned3 markersabsent损坏输出则含corrupt ... findings1 ... quarantinenot-performed与- hash mismatch at seq 2之类的具体发现。markers字段报告侧车扫描结果absent无侧车文件、clean/corrupt含快照、高保真、缺口与字典计数、error侧车存在但无法打开或扫描。大文件超时调整env NAUTILUS_EVENT_STORE_VERIFY_TIMEOUT_SECS120 \ cargo run -p nautilus-event-store --bin verify -- ./event_store/trader-001/1700000000-cafe0001.redb需要留意干净判定的边界docs/concepts/event_sourcing.mdclean只证明结构完整性不证明可恢复性或捕获完整性——校验器检查快照锚点但不加载/哈希其 blob标记校验把已记录的缺口计为覆盖中途 fail-stop 的运行仅对其已捕获部分校验干净对 halt 之后的消息不置一词。九、从 Rust 读取密封运行EventStoreReader是只读回放、审计与校验扫描的规范入口reader/mod.rs它持有后端、暴露分块迭代的区间扫描、单seq点查、二级索引查询与 manifest 访问对运行中与已密封的后端一视同仁且没有append_batch表面。README 的完整示例READMEuse nautilus_event_store::{EventStoreReader, RedbBackend, ScanDirection}; fn inspect_run() - Result(), Boxdyn 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_024reader/mod.rs让百万级条目的取证扫描保持有界的工作集同时摊薄每次调用的事务开销可通过scan_range_chunked调整。十、生命周期选项自定义编码器与后端开启器EventStoreLifecycle::boot(...)保持默认行为打开RedbBackend并安装default_registry()。高级调用方可通过EventStoreLifecycle::boot_with_options(...)传入仅运行时选项EventStoreLifecycleOptions而无需改动可序列化的EventStoreConfigREADME。在生命周期打开运行前注册自定义总线负载编码器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_iddocs/concepts/event_sourcing.md设置后内核从密封运行恢复缓存状态、把该运行记录为新鲜子运行的父运行、并跳过实时引擎/客户端/启动/交易所对账Quarantined运行被拒绝。回放还要求load_statetrue否则内核记录错误并直接返回。缓存回放加载器是仅状态的恢复缓存拥有的快照按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.tomldefi启用 DeFi去中心化金融支持live通过nautilus-common启用实时运行支持persistence通过nautilus-persistence启用 Parquet catalog 回放支持。依赖方面Cargo.tomlcrate 构建在nautilus-common、nautilus-core、nautilus-execution、nautilus-model、nautilus-system之上使用redb持久化、blake3/ahash哈希、bytes、rmp-serdeMessagePack 序列化、serde、ustr与indexmap等依赖库目标为rlibCargo.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从研究到实盘语义一致这一整体架构的关键一环。【免费下载链接】nautilus_traderProduction-grade Rust-native trading engine with deterministic event-driven architecture项目地址: https://gitcode.com/GitHub_Trending/na/nautilus_trader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考