SierraDB 是一款用 Rust 构建的分布式事件存储数据库，专为事件溯源设计，支持水平扩展、无间隙序列、跨流事务与 RESP3 协议，开箱即用，适合高一致性要求的现代应用。
告别 Kafka 和 Postgres！Rust 打造的下一代事件溯源数据库 SierraDB 横空出世，原生支持原子跨流写入与零驱动接入！
一个系统真正的“记忆”应该是什么样子？不是一堆冷冰冰的日志，也不是靠拼凑出来的状态快照，而是每一步操作、每一个决策，都被完整、不可篡改地记录下来——这就是事件溯源（Event Sourcing）的魅力。
但问题来了：市面上那些通用数据库，比如 PostgreSQL 或 Kafka，真的适合干这活吗？答案是：不太行。它们要么太重，要么缺关键功能，比如真正的只追加存储、无间隙的序列号、高效的流读取，还有内置的订阅机制。
于是，一位深耕分布式系统多年的开发者，决定亲手打造一款专为事件溯源而生的数据库——SierraDB，而且是用 Rust 从零写起！
这位作者可不是临时起意。他长期研究事件驱动架构，在多个高并发系统中踩过坑、填过雷，深知通用数据库在事件溯源场景下的种种掣肘。更关键的是，他坚信：高性能数据库不该依赖垃圾回收机制。正因如此，他选择了 Rust——这门以零成本抽象、内存安全和无 GC 停顿著称的语言，来构建 SierraDB。目标很明确：打造一个可水平扩展、低延迟、强一致性的分布式事件存储引擎。
SierraDB 的设计灵感来自 Cassandra 的分区扩展能力，也借鉴了 AxonServer 的分段只追加文件结构，但全部用 Rust 重写，彻底摆脱了 JVM 或 .NET 带来的不可预测延迟。
更妙的是，它直接采用 Redis 的 RESP3 协议作为通信标准！这意味着什么？意味着你不需要写任何新驱动——只要你的语言有 Redis 客户端（几乎每种主流语言都有），就能立刻连接 SierraDB。甚至用 redis-cli 就能调试事件流，开发体验直接拉满。
那 SierraDB 的核心架构到底长啥样？
简单说，它把事件存进固定数量的逻辑分区（partitions）里。比如单节点起步用 32 个分区，大规模集群可扩展到 1024 个以上。每个分区独立处理写入，保证单调递增且无间隙的序列号——这是事件溯源的命脉！
为什么不能有“跳号”？因为版本号一旦断层，就意味着事件丢失，整个乐观锁机制就崩了。SierraDB 通过分区级序列号，既避免了全局计数器的性能瓶颈，又确保了每个流内的严格顺序。
数据在磁盘上怎么组织？每个节点有若干桶（buckets），每个桶管理多个分区，而每个分区的数据被写入一个个 256MB 的不可变段文件（segments）。一旦写满，就滚到下一个新段。这种设计让索引可以一次性构建并永久缓存，既高效又安全。每个段包含四种文件：原始事件数据（.evts）、事件 ID 索引（.eidx）、分区索引（.pidx）和流索引（.sidx）——查询时快如闪电。
更厉害的是它的跨流事务支持。默认情况下，每个流（比如 user-123）会通过 UUIDv5 映射到某个分区。但你可以手动指定多个流共享同一个分区键（partition key）。这样一来，user-123 和 account-456 如果共用一个分区键，它们就会落在同一个分区里，你就能在一个原子操作中同时往两个流写事件！无需分布式事务协调，天然保证一致性。这简直是领域驱动设计（DDD）聚合根跨边界操作的福音。
说到分布式，SierraDB 的复制机制也相当聪明。每个分区按你设定的复制因子（比如 3）在多个节点上存副本。写入需要多数派确认（quorum）才成功，确保高可用。但读取呢？不需要再跑一轮共识！每个事件自带“确认计数”，后台进程会异步广播确认状态。节点本地维护一个水位线（watermark）——只暴露那些“连续已确认”的事件。比如序列 1-98 和 100-102 都确认了，但 99 还没到，那水位线就卡在 98，绝不让你看到断层。等 99 一确认，水位线瞬间跳到 102，保证你读到的永远是完整、连续的历史。
领导选举也不搞复杂投票。SierraDB 采用基于集群拓扑的确定性选主，灵感来自 Raft，但省去了昂贵的选举过程。哪个节点当 leader，完全由集群结构决定，稳定又高效。
底层技术栈更是站在巨人肩膀上：RESP3 提供开箱即用的客户端生态；libp2p（IPFS 背后的网络库）负责节点发现、连接管理和 gossip 协议；而整个系统用作者自研的 Kameo Actor 框架构建——每个分区 leader、复制协调器都是独立 Actor，崩溃自动重启，互不影响。这种设计让 SierraDB 在部分节点故障时依然坚挺。
为了让开发者用得爽，SierraDB 所有命令都以 E 开头（如 EAPPEND、ESCAN、ESUB），避免和 Redis 命令冲突。它原生支持订阅机制：客户端可以指定从哪个分区、哪个序列号开始订阅，SierraDB 会先回放历史事件，再推送新事件，彻底告别轮询。Rust 用户还能用配套库 kameo_es 快速定义聚合根和命令处理器，省去大量样板代码。
更贴心的是，作者还做了个叫 SierraDB Inspector 的 Web 界面！用 JavaScript 写投影、可视化事件流、实时调试——再也不用对着命令行猜数据。想试试？一行 Docker 命令搞定：
bash
docker run -p 9090:9090 tqwewe/sierradb
然后用 redis-cli 连上去：
bash
redis-cli -p 9090
> EAPPEND user-123 UserCreated '{"name": "Alice"}'
> ESCAN user-123 - +
是不是超简单？
目前 SierraDB 已通过长期压力测试，核心架构稳定，虽在性能优化和文档完善上还有空间，但基础打得非常扎实。作者的目标很清晰：打造一个真正生产就绪、开源、可扩展的现代事件存储系统。他欢迎社区贡献，尤其是文档和测试方面的帮助。
如果你正在构建需要强审计、高可追溯、灵活投影的系统——比如金融交易、医疗记录、IoT 状态追踪或复杂业务流程引擎——那么 SierraDB 值得你认真关注。它不只是一个数据库，更是一种对系统“记忆”本质的重新思考。