3 回答

TA贡献1895条经验 获得超3个赞
在 NATS JetStream 中发布与在 Core NATS 中发布略有不同。是的,您可以将核心 NATS 消息发布到由流记录的主题,并且该消息确实会在流中被捕获,但在核心 NATS 发布的情况下,发布应用程序不期望从nats-server,而在 JetStream 发布调用的情况下,有一个确认从 nats-server 发送回客户端,表明消息确实已成功保存和复制(或没有)。
因此,当您执行 js.Publish() 时,您实际上是在进行同步的相对较高延迟的请求-回复(特别是如果您的复制是 3 或 5,如果您的流被持久保存到文件中,则更是如此,并且取决于客户端应用程序和 nats-server),这意味着如果您只是背靠背地执行那些同步发布调用,您的吞吐量将受到限制。
如果您想要将消息发布到流的吞吐量,您应该改用 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 能够实现的吞吐量。验证或测量性能的一种简单方法是使用nats
CLI 工具 ( https://github.com/nats-io/natscli ) 运行基准测试。
例如,您可以从一个简单的测试开始:(nats bench foo --js --pub 4 --msgs 1000000 --replicas 3
在具有 3 个副本的内存流中,4 个 go-routines 每个都有自己的连接,以 100 个批次发布 128 字节消息),您应该每秒获得的消息远远超过几千条消息。
有关如何使用该nats bench
命令的更多信息和示例,您可以观看此视频:https ://youtu.be/HwwvFeUHAyo

TA贡献1840条经验 获得超5个赞
最好能就此发表意见。我有类似的行为,为发布者实现更高吞吐量的唯一方法是降低复制(从 3 到 1),但这不是可接受的解决方案。
我尝试添加更多资源(cpu/ram),但没有成功提高发布率。
此外,水平缩放没有任何区别。
在我的情况下,我正在使用 Bench 工具发布到 js。

TA贡献1794条经验 获得超8个赞
对于 R3 文件存储,您可以预期每秒约 250k 小消息。如果您使用将由 RTT 主导的同步发布,从应用程序到系统,从流领导者到最近的追随者。您可以使用窗口化智能异步发布来获得更好的性能。
您可以通过内存存储获得更高的数字,但在整个系统中仍将由 RTT 主导。
如果您让我了解您的消息有多大,我们可以向您展示 nats bench 针对演示服务器 (R1) 和 NGS (R1 & R3) 的一些结果。
对于关于过滤消费者的原始问题, >= 2.8.x 不会进行线性扫描来检索foo.baz。如果有帮助,我们也可以举一个例子。
随意加入 slack 频道 (slack.nats.io),这是一个非常活跃的社区。甚至可以直接私信我,很乐意提供帮助。
- 3 回答
- 0 关注
- 736 浏览
添加回答
举报