messagebroker - NATS 是否水平扩展(吞吐量)

Question

我们正在使用 NATS 并使用 3+ 节点的集群。我们有几个生产者和许多消费者。消息大小很小 (~100bytes) 但是我们的吞吐量有点高。 ~40k/秒。所有流量都在 2x10gbps 绑定(bind)的内部网络上。

我很好奇用更多节点扩展集群是否有助于提高集群的吞吐量。我们有一些小的延迟，随着每秒写入更多消息，延迟似乎会略有增加。

作为次要说明，是否有可以提高吞吐量的提示/技巧？我们目前正在使用 protobufs，但是否可以对服务器进行调整？

Answer 1

如果给定主题有很多匹配订阅，吞吐量可能会受到影响。

例如，假设您使用 1 个连接并在 foo 上发布。 foo 上有 100 个订阅。当服务器收到一条消息时，它会将它传递给所有匹配的订阅。在这种情况下，这意味着 TCP 发送此消息 100 次，无论订阅是否属于同一连接。

在向订阅者发送消息时，服务器不会读取此连接发布的其他消息。

如果您还在集群中分配订阅负载，则通过添加服务器进行水平扩展可能会有所帮助。在上面的示例中，假设一台服务器上有 50 个消费者，另一台服务器上有 50 个，那么接收已发布消息的服务器现在只需发送该消息 50+1 次(本地订阅者 50 次，路由 1 次)。然后，另一台服务器将向其本地订阅者发送 50 条消息。

但是如果只有一个(或没有)匹配的订阅，仅仅添加服务器不会提高单个连接的吞吐量。

另一种提高发布吞吐量的方法是使用更多连接。由于服务器为每个连接使用一个 go 例程(从套接字读取数据然后发送到订阅)，一些工作可以并行化。

我可以运行存储库中包含的一些基准测试来获得您可以在您的机器上获得的上限。例如，服务器基准测试通常将数据直接写入套接字，而不是使用 NATS 客户端。这是为了衡量服务器性能，不受客户端实现的任何限制:

    go test -v -run=xxx -bench=. ./test

确保查看您发送消息的方式以及它们在订阅回调中的处理方式。您可以为提高性能所做的任何事情都将具有更大的值(value)。

希望这对您有所帮助。