我们正在使用 NATS 并使用 3 个以上节点的集群。我们有几个生产者和许多消费者。消息大小很小（~100bytes）但是我们的吞吐量有点高。 ~40k/秒。所有流量都在 2x10gbps 绑定的内部网络上。
我很好奇使用更多节点扩展集群是否有助于集群的吞吐量。我们有一些小的延迟，随着每秒写入更多消息，它似乎略有增长。
作为次要说明，是否有可以提高吞吐量的提示/技巧？我们目前正在使用 protobuf，但是否可以进行服务器调整？
【问题讨论】：
标签： messagebroker nats.io
如果给定主题有很多匹配的订阅，吞吐量可能会受到影响。
例如，假设您使用 1 个连接并在 foo 上发布。 foo 有 100 个订阅。当服务器收到一条消息时，它将把它传递给所有匹配的订阅。在这种情况下，这意味着 TCP 发送此消息 100 次，无论订阅是否属于同一个连接。
在向订阅者发送消息时，服务器没有读取此连接发布的其他消息。
如果您还在集群中分配订阅负载，则通过添加服务器进行水平扩展可能会有所帮助。在上面的示例中，假设 50 个消费者在一台服务器上，50 个在另一台服务器上，那么接收发布消息的服务器现在只需发送该消息 50+1 次（本地订阅者为 50 次，路由为 1 次）。然后，另一台服务器将向其本地订阅者发送 50 条消息。
但如果有一个（或没有）匹配订阅，仅仅添加服务器不会提高单个连接的吞吐量。
提高 pub 吞吐量的另一种方法是使用更多连接。由于服务器对每个连接使用 go 例程（从套接字读取数据然后发送到订阅），因此可以并行化一些工作。
我可以运行 repo 中包含的一些基准测试来获得你可以在你的机器上获得的上限。例如，服务器基准测试通常将数据直接写入套接字，而不是使用 NATS 客户端。这是为了衡量服务器性能，不受客户端实现的任何限制：
go test -v -run=xxx -bench=. ./test
请务必查看您发送消息的方式以及它们在订阅回调中的处理方式。你可以做的任何事情来提高性能都会有更大的价值。
希望这会有所帮助。
【讨论】：