NATS JetStream 性能问题分析与优化实践

问题背景

在NATS JetStream消息系统中，近期版本(2.10.17及以上)出现了一个值得关注的性能问题。当用户在高负载情况下向采用WorkQueue保留策略的流发布消息时，系统操作会逐渐变慢并最终超时。这一现象在2.10.12版本中并不存在，表明这是新引入的问题。

问题重现与测试环境

通过一个精心设计的测试用例可以稳定复现此问题。测试场景创建了一个包含10万条消息的WorkQueue流，并建立了一个持久化消费者。该消费者执行以下循环操作：

1. 从队列获取下一条消息
2. 确认(ack)该消息
3. 将消息重新发布回队列

测试环境配置如下：

• 操作系统：Ubuntu 22.04.1 LTS (WSL2)
• 处理器：Intel Core i3-3220 @ 3.30GHz
• 内存：8GB
• 测试版本：2.10.12(正常)、2.10.17/2.10.18/2.11.0-dev(存在问题)

问题根源分析

深入分析后发现两个关键问题：

1. 过度压缩问题

问题源于对空块处理的优化。当块中第一个非空序列被移除(由于ack操作)时，系统会在块末尾写入一个墓碑标记。但在高负载情况下，这导致了几乎每条消息都会触发压缩操作，严重影响了性能。

根本原因是压缩逻辑中未正确计算墓碑标记的字节数，导致系统误判需要频繁压缩。修复方法是在写入墓碑标记时正确统计字节数。

2. 过早ACK确认问题

第二个问题涉及ACK确认的时序。服务器在真正从状态中移除消息之前就发送了ACK响应，这导致在某些情况下，新版本的消息可能在旧版本被移除前就已到达，违反了"每个主题最多一条消息"的限制。

这一问题是在单服务器模式或非集群资产中引入的，源于ACK响应发送逻辑的修改。服务器先发送ACK响应，再执行实际的消息移除操作，造成了竞态条件。

解决方案与优化

针对上述问题，开发团队采取了以下措施：

1. 压缩优化：修正了墓碑标记的字节统计逻辑，避免了不必要的频繁压缩操作。这一修改显著提升了高负载下的性能表现。

2. ACK时序调整：正在考虑对ACK确认逻辑进行调整，确保只有在消息真正从状态中移除后才发送ACK响应，从根本上解决竞态条件问题。

性能对比与验证

在2.10.12版本中，测试用例能够顺利完成，最终流大小保持为10万条消息。而在问题版本中，会出现大量超时错误，如：

• "error fetching from workqueue nats: timeout"
• "error acking msg from workqueue nats: timeout"

此外，还会出现"maximum messages per subject exceeded"的错误，这正是过早ACK确认问题的直接表现。

最佳实践建议

对于使用NATS JetStream的用户，特别是在高负载场景下使用WorkQueue策略时，建议：

1. 如果性能至关重要，可暂时使用2.10.12版本
2. 密切关注官方修复版本的发布
3. 在测试环境中充分验证新版本的表现
4. 对于关键业务系统，考虑实施适当的监控和告警机制

总结

这次性能问题的分析和解决过程展示了分布式消息系统中微妙的时序和状态管理挑战。NATS团队通过深入的技术分析和严谨的修复方案，确保了系统的稳定性和可靠性。对于用户而言，理解这些底层机制有助于更好地设计和优化自己的消息处理架构。