Jepsen测试发现NATS JetStream 2.12.1版本存在数据丢失问题：当少数节点数据文件被截断或损坏时，系统可能丢失已提交的写入；协调电源故障或单节点崩溃结合网络延迟也可能导致持久性脑裂。问题部分源于默认每2分钟才刷新磁盘写入的设置。NATS已记录其默认fsync策略的风险，相关问题仍在调查中。此前2.10.22版本因进程崩溃导致数据丢失的问题已在2.10.23修复。

Jepsen对NATS 2.12.1的测试分析报告

核心发现

1. 数据丢失问题

   • 版本2.10.22：进程崩溃会导致JetStream流及其所有数据完全丢失（已通过2.10.23版本修复）。
   • 版本2.12.1：
     • 少数节点的.blk文件损坏（如单比特错误或截断）可能导致大量已确认写入丢失（#7549）。
     • 快照文件损坏可能触发节点误判流被孤立，进而删除所有数据文件（#7556）。
     • 默认每2分钟执行一次fsync的策略使得已确认但未刷盘的写入在协调性断电或系统崩溃时丢失（#7564）。

2. 脑裂问题

   • 单个节点操作系统崩溃结合网络延迟或进程暂停，可能导致已提交写入丢失和持久性脑裂（不同节点返回不同消息集，#7567）。

测试方法

• 故障模拟：包括进程崩溃、网络分区、文件损坏（使用LazyFS模拟断电后未刷盘的写入丢失）。
• 验证指标：检查已确认消息是否被至少一个消费者读取，以及节点间消息集是否一致。

关键问题分析

• 文件损坏漏洞：NATS的校验机制未能完全防止少数节点文件损坏引发的数据丢失。
• 默认fsync策略风险：
  • 与多数分布式系统（如MongoDB、etcd）不同，NATS默认延迟刷盘，导致其对协调性故障敏感。
  • 文档中仅两处提及此行为，且未明确警告数据丢失风险。

建议与改进

1. 配置调整：将fsync默认值改为always，或显著标注延迟刷盘的风险。
2. 文档修正：
   • 澄清CAP定理下“完全可用性”与线性一致性的矛盾。
   • 修正节点成员变更的误导性说明（如错误的节点移除命令）。

待解决问题

• 文件损坏引发的数据丢失（#7549、#7556）和单节点崩溃导致的脑裂（#7567）仍在调查中。
• 未来需测试消费者级别的消息丢失、顺序一致性及“精确一次”语义。

测试局限性

• 实验性测试仅能证伪，无法证明系统绝对正确。
• 未覆盖节点动态增删场景（因文档不完整）。

报告由Jepsen独立完成，遵循其伦理政策。

（注：本文为技术摘要，省略了部分测试细节和学术引用，完整分析请参阅原文。）

总结评论内容：

1. 关于NATS软件的批评：

• 默认配置不安全，可能导致数据丢失（评分：无）

  • "By default, NATS only flushes data to disk every two minutes... can lead to the loss of committed writes"（默认情况下，NATS每两分钟才将数据刷新到磁盘...可能导致已提交写入丢失）
  • "I wouldn't trust a product that doesn't default to safest options"（我不信任不默认采用最安全选项的产品）

• 文档不完善（评分：无）

  • "doc's unpractical and half backed"（文档不实用且不完整）
  • "required to retro engineer the software from GitHub"（需要从GitHub反向工程软件）

2. 性能与安全性的权衡讨论（评分：无）：

• 关于fsync性能改进可能性的讨论
  • "Couldn't you still run fsync on an interval and queue up writes?"（不能以一定间隔运行fsync并排队写入吗？）
  • "batches throughput could be preserved to some extent"（批量吞吐量可以在一定程度上保留）

3. 其他观点：

• 对Jepsen术语表的推荐（评分：无）

  • "a fantastic reference"（极好的参考资料）

• 对报告的积极评价（评分：无）

  • "always a quiet pleasure to read"（阅读总是种安静的享受）