我們使用NATS並使用3+個節點的聚類。我們有幾個生產者和許多消費者。消息大小很小（〜100字節），但是我們的吞吐量有點高。 〜40K /秒。所有流量都在2x10gbps綁定的內部網絡上。NATS水平伸縮（吞吐量）
我很好奇，如果用更多節點擴展集羣將有助於集羣的吞吐量。隨着寫入更多消息/秒，我們有一些小延遲似乎會略有增長。
作爲輔助說明，是否有提示/技巧可以提高吞吐量？我們目前正在使用protobufs，但有沒有可以完成的服務器調整？
如果給定主題上存在許多匹配的訂閱，則吞吐量可能會受到影響。
例如，假設您使用1個連接並正在foo上發佈。 foo有100個訂閱。當服務器收到消息時，它會將其發送給所有匹配的訂閱。在這種情況下，它意味着TCP將此消息發送100次，無論訂閱是否屬於同一個連接。
在發送給訂閱者時，服務器不讀取由此連接發佈的其他消息。
通過添加服務器進行水平縮放如果還在羣集中分發訂閱的負載，則可能會提供幫助。在上面的例子中，假設有50個消費者在一個服務器上，另一個服務器上有50個消費者，那麼接收發布消息的服務器現在只需要發送該消息50 + 1次（其本地訂戶爲50，路由爲1）。另一臺服務器會發送50條消息給本地用戶。
但是，僅僅添加服務器將不會提高單個連接吞吐量，如果只有一個（或沒有）匹配的訂閱。
提高酒吧吞吐量的另一種方法是使用更多的連接。由於服務器每個連接使用一個go例程（從套接字讀取數據然後發送到訂閱），因此可以將一些工作並行化。
我可以運行一些包含在回購中的基準，以獲得您的機器上可以獲得的上限。例如，服務器臺架測試通常將數據直接寫入套接字而不是使用NATS客戶端。這是衡量服務器的性能，而無需在客戶端執行施加的任何限制：
go test -v -run=xxx -bench=. ./test
請一定要看看你發送消息的方式以及它們是如何在訂閱回調處理。你可以做的任何事情來提高績效將會有更大的價值。
希望這會有所幫助。