Nats Jetstream的性能

Question

我试图了解Nats Jetstream是如何扩展的，并且有几个问题。

1. 按历史信息订阅的效率有多高？例如，假设有一个流foo，它包含1亿条带有foo.bar主题的消息，然后是带有subject foo.baz的单个消息。如果我从流一开始就订阅了foo.baz，那么服务器上的某些内容必须对foo中的所有消息执行线性扫描，或者它是否能够立即查找foo.baz消息.

1. 系统水平的规模有多大？我之所以问这个问题，是因为无论我向它扔了多少台机器，Jetstream每秒都不能扩展到几千条消息。测试参数如下：

- Nats Server `2.6.3` running on 4 core 8GB nodes
- Single Stream replicated 3 times (disk or in-memory appears  to make no  difference)
- 500 byte message payloads
- `n` publishers each publishing 1k messages per second The bottleneck appears to be on the publishing side as I can retrieve messages at least as fast as I can publish them.

Answer 1

NATS JetStream中的发布与核心NATS中的发布略有不同。是的，您可以将Core消息发布到由流记录的主题，并且该消息确实将在流中捕获，但对于Core发布，发布应用程序并不期望从NATS -服务器返回确认，而对于JetStream发布调用，有一个从NATS -服务器发送回客户端的确认，该确认指示消息确实成功地持久化和复制(或不成功)。

因此，当您执行js.Publish()时，您实际上提出了一个相对较高的同步延迟请求--回复(特别是如果您的复制为3或5，如果您的流被持久化为文件，并且取决于客户机应用程序和nats-server之间的网络延迟)，这意味着如果您只是背对背地执行那些同步发布调用，您的吞吐量将受到限制。

如果您希望将消息发布到流的吞吐量，则应该使用异步版本的JetStream发布调用(也就是说，您应该使用返回PubAckFuture的js.AsyncPublish() )。

但是，在这种情况下，您还必须记住引入一定量的流控制，方法是限制您希望在任何给定时间拥有的“在役”异步发布应用程序的数量(这是因为您始终可以远快于nats服务器复制和持久消息的速度。

如果您要继续以最快的速度异步发布(例如，当发布某种批处理的结果时)，那么最终您将淹没服务器，这是您真正想要避免的。

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

当获取您的js = nc.JetStream(nats.PublishAsyncMaxPending(100))

• Do上下文时，
• 指定最大的在轨异步发布请求数作为选项:即，是一种简单的批处理机制，用于每隔这么多异步发布检查发布的PubAcks，就像nats bench做的那样：

关于预期的性能:使用异步发布允许您真正获得NATS和JetStream能够实现的吞吐量。验证或度量性能的一种简单方法是使用nats CLI工具(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

Answer 2

如果能对此有意见就好了。我也有类似的行为，对于发行商来说，实现更高的吞吐量的唯一方法是降低复制(从3到1)，但这不是一个可以接受的解决方案。

我尝试增加了更多的资源(cpu/ram)，但在提高发布率方面没有成功。

此外，水平缩放没有任何区别。

在我的情况下，我使用工作台工具发布到js。

Answer 3

对于R3文件，您可以预期每秒大约250 k小味精。如果使用同步发布，则将由RTT主导，从应用程序到系统，从流领导到最近的跟随者。您可以使用加窗的智能异步发布来获得更好的性能。

使用内存存储可以获得更高的数字，但在整个系统中，RTT将再次占据主导地位。

如果您告诉我您的消息有多大，我们可以向您展示nats针对演示服务器(R1)和NGS (R1 & R3)的一些结果。

对于有关过滤消费者的最初问题，>= 2.8.x不会进行线性扫描来检索foo.baz。如果它有帮助的话，我们也可以给出一个例子。

欢迎加入松弛通道(slack.nats.io)，这是一个非常活跃的社区。甚至可以直接给我发短信，很乐意帮忙。