NATS Jetstream 的性能

Question

我试图了解 NATS Jetstream 如何扩展并有几个问题。

1. 通过主题订阅历史消息的效率如何？例如，假设有一个流foo，其中包含 1 亿条主题为 的消息foo.bar，然后是一条主题为 的消息foo.baz。如果我从流的开头进行订阅，foo.baz服务器上的某些内容必须对所有消息执行线性扫描foo，或者它能够立即查找消息 foo.baz。

2. 系统的水平扩展能力如何？我问这个问题是因为我在让 Jetstream 扩展到每秒几千条消息以上时遇到问题，无论我向它投入多少台机器。测试参数如下：

   • Nats Server2.6.3运行在 4 核 8GB 节点上
   • 单个流复制 3 次（磁盘或内存中似乎没有区别）
   • 500 字节消息有效负载
   • n每个发布者每秒发布 1k 条消息瓶颈似乎出现在发布方面，因为我检索消息的速度至少与发布消息的速度一样快。

Answer 1

在 NATS JetStream 中发布与在 Core NATS 中发布略有不同。是的，您可以将 Core NATS 消息发布到由流记录的主题，并且该消息确实会在流中捕获，但在 Core NATS 发布的情况下，发布应用程序并不期望从流中返回确认。 nats-server，而在 JetStream 发布调用的情况下，有一个确认从 nats-server 发送回客户端，表明消息确实已成功持久化和复制（或未成功）。

因此，当您执行 js.Publish() 时，您实际上是在进行同步相对较高延迟的请求-回复（特别是如果您的复制是 3 或 5，如果您的流持久保存到文件，并且取决于数据流之间的网络延迟，则更是如此）客户端应用程序和 nats 服务器），这意味着如果您只是连续执行这些同步发布调用，那么您的吞吐量将受到限制。

如果您希望将消息发布到流的吞吐量，您应该使用 JetStream 发布调用的异步版本（即您应该使用js.AsyncPublish()返回 a 的函数PubAckFuture）。

然而，在这种情况下，您还必须记住通过限制您想要在任何给定时间拥有的“运行中”异步发布应用程序的数量来引入一定量的流量控制（这是因为您始终可以比异步发布快得多） nats-server(s) 可以复制和保存消息。

如果您要尽可能快地连续异步发布（例如，当发布某种批处理过程的结果时），那么您最终会压垮您的服务器，这是您真正想要避免的。

您有两个选项来控制 JetStream 异步发布的流量：

• 获取 JetStream 上下文时指定最大数量的正在进行的异步发布请求作为选项：即js = nc.JetStream(nats.PublishAsyncMaxPending(100))
• 执行一个简单的批处理机制来检查每个异步发布的发布的 PubAcks，如下所示nats bench： https: //github.com/nats-io/natscli/blob/e6b2b478dbc432a639fbf92c5c89570438c31ee7/cli/bench_command.go#L476

关于预期性能：使用异步发布可以让您真正获得 NATS 和 JetStream 能够达到的吞吐量。验证或测量性能的一个简单方法是使用natsCLI 工具 ( https://github.com/nats-io/natscli ) 运行基准测试。

例如，您可以从一个简单的测试开始：（nats bench foo --js --pub 4 --msgs 1000000 --replicas 3在内存流中，有 3 个副本，4 个 go 例程，每个副本都有自己的连接，以 100 条为批次发布 128 字节消息），您每秒应该会收到比几千条消息更多的消息。

有关如何使用该nats bench命令的更多信息和示例，您可以观看此视频： https: //youtu.be/HwwvFeUHAyo