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條經驗 獲得超7個贊
對于 R3 文件存儲,您可以預期每秒約 250k 小消息。如果您使用將由 RTT 主導的同步發布,從應用程序到系統,從流領導者到最近的追隨者。您可以使用窗口化智能異步發布來獲得更好的性能。
您可以通過內存存儲獲得更高的數字,但在整個系統中仍將由 RTT 主導。
如果您讓我了解您的消息有多大,我們可以向您展示 nats bench 針對演示服務器 (R1) 和 NGS (R1 & R3) 的一些結果。
對于關于過濾消費者的原始問題, >= 2.8.x 不會進行線性掃描來檢索foo.baz。如果有幫助,我們也可以舉一個例子。
隨意加入 slack 頻道 (slack.nats.io),這是一個非?;钴S的社區。甚至可以直接私信我,很樂意提供幫助。
- 3 回答
- 0 關注
- 614 瀏覽
添加回答
舉報