想象一個場景，其中生產者每秒產生 100 條訊息，而我們正在開發一個系統，該系統需要盡快消??費訊息，即使延遲 5 秒也可能導致決定不再處理該訊息。此外，訊息的順序無關緊要。
所以我不想使用一個基本佇列和一個監聽單個磁區的單個 pod 來消費訊息，因為為了消費一條訊息，消費者需要進行多個遠程 API 呼叫，這可能需要一些時間。
在這種情況下，我正在考慮具有 100 個磁區的單個 Kafka 主題。對于每個磁區，我將有一臺單獨的機器（pod）監聽磁區 0 到 99。
我想對了嗎？這是我與 Kafka 的第一個專案。這對我來說似乎有點奇怪。
uj5u.com熱心網友回復：
對于您的用例，請考慮磁區 = 服務使用資料的最大實體數。如果您有 8 個實體，請不要創建額外的磁區。如果需要重新平衡消費者，這將產生負面影響，并且可能不會給您帶來任何性能改進。100 條訊息/秒也非常非常少，您幾乎可以使用任何技術來完成這項作業。
為了獲得最佳性能，我建議：
- 使用回圈磁區器
- 為您的平臺找到一個并行消費者實作（對于jvm）
您需要更改一些生產者和消費者屬性，但它們取決于您的環境。例如batch.size，linger.ms等。我還會檢查是否需要設定acks=all，因為如果由于舊資料沒有用，經紀人死亡，您可能會丟失資料。
一個警告：在 Java 中，標準的 kafka 消費者是單執行緒的。這讓很多人感到驚訝，我不確定其他平臺是否也是如此。因此，擁有 100 個磁區不會為這些消費者帶來任何性能優勢，這就是為什么使用并行消費者很重要的原因。
還有一個警告：Kafka 是一個復雜的代理。開始使用它是微不足道的，但正確使用它是一個非常坎坷的旅程。
請注意：Kafka 的一個好處是它保留訊息，而不是在訊息被使用后將其洗掉。如果超過 5 秒的訊息對您來說毫無用處，Kafka 可能是錯誤的技術，使用更傳統的代理可能更容易（activeMQ、rabbitMQ 或去像 zeromq 之類的極速的代理）
uj5u.com熱心網友回復：
您的瓶頸是您的應用程式處理事件，而不是 Kafka。當您有十個消費者時，將每個消費者連接到 Kafka 會產生開銷，因此會降低性能。我建議關注您的應用程式性能而不是訊息代理。
Kafka p99 延遲為 5 毫秒，負載為 200 MB/秒。
https://developer.confluent.io/learn/kafka-performance/
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/523601.html