2017-08-06 57 views
2

我們正在使用kafka 0.10.x,我正在尋找,如果有一種方法可以阻止發佈商kafka在某個消息/限制達到一小時後停止發送消息。這裏的目標是限制用戶只發送特定的號碼消息,並在每小時/每天? 如果有人遇到類似的用例,請分享您的發現。 在此先感謝......發佈者的KAFKA郵件限制?

+0

一個可能的選擇是跳過在消費者一方的額外信息(無論是應該對它們進行處理)。 – Thilo

回答

1

,您可以利用券商CONFIGS的:

message.max.bytes(默認:1000000) - 消息代理將接受的最大尺寸。這必須小於消費者的fetch.message.max.bytes,否則代理將擁有無法使用的消息,導致消費者掛起。

log.segment.bytes(默認:1GB) - Kafka數據文件的大小。確保其大於1條消息。默認情況下應該沒問題(例如,大消息在任何情況下都不應該超過1GB,它是一個消息系統,而不是文件系統)

replica.fetch.max.bytes(默認值:1MB) - 數據的最大大小一個經紀人可以複製。這必須大於message.max.bytes,否則代理將接受消息並且無法複製它們。導致潛在的數據丟失。

我想你可以調整配置,做你想做

1

什麼卡夫卡有一些限制和配額機制,但他們都不完全符合您的要求,嚴格限制基於郵件數每天都在生產商。

從Apache的卡夫卡0.11.0.0文檔在https://kafka.apache.org/documentation/#design_quotas

卡夫卡集羣具有強制執行的請求配額來控制 客戶端使用的代理資源的能力。有兩種類型的客戶端的配額可以 卡夫卡經紀人對每個組的客戶端共享 配額的強制執行:

  • 網絡帶寬配額限定字節速率閾值(自0.9)

  • 請求配額限定CPU利用率閾值以百分比網絡的 和I/O線程(因爲0.11)

CLIEN t配額首先在卡夫卡0.9.0.0中引入。強制執行生產者和消費者的費率限制,以防止客戶飽和網絡或壟斷經紀人資源。

見KIP-13的詳細信息:https://cwiki.apache.org/confluence/display/KAFKA/KIP-13+-+Quotas

上0.9引入的配額機制是基於client.id在客戶端配置設置,它可以很容易被改變。理想情況下,配額應設置在已驗證的用戶名上,以便在0.10.1.0中避免這種情況並不容易,因此添加了Authenticated Quota功能。

見KIP-55的詳細信息:https://cwiki.apache.org/confluence/display/KAFKA/KIP-55%3A+Secure+Quotas+for+Authenticated+Users

兩個以上的數據量(即,帶寬限制),而不是對消息也不請求的數目的數目上工作中描述的配額的機制。如果客戶端發送大量小消息或發出大量不返回消息的請求(例如,min.byte配置爲0的消費者),它仍然可能壓倒代理。爲了解決這個問題,0.11.0.0增加了額外的支持通過請求速率限制。

見KIP-124的詳細信息:https://cwiki.apache.org/confluence/display/KAFKA/KIP-124+-+Request+rate+quotas

有了這些作爲背景,然後,如果你知道你的製片人總是出版了一定規模的消息,則可以計算表示以MB爲單位,也是一個漲停速率限制,以MB /秒錶示,您可以將其配置爲配額。這並不適合您的需要,因爲製片人可能會在12小時內發送任何內容,然後嘗試以更快的速度發送很短的時間,並且配額仍會將發行速率限制爲較低,因爲限制是每秒執行的,而且不是每天。

如果您不知道郵件大小或其變化很大,則由於郵件是使用產品請求發佈的,因此您可以使用請求速率限制來稍微控制允許經過身份驗證的用戶發佈郵件的速率它不會成爲消息/日期限制,甚至不是帶寬限制,而是作爲「CPU利用率閾值佔網絡和I/O線程的百分比」。這有助於避免DoS問題,而不是真正限制郵件數量。

如果您希望看到添加到卡夫卡的消息計數配額或消息存儲配額,那麼顯然卡夫卡改進建議(KIP)過程可以正常工作,並且我們鼓勵您在此區域或任何其他區域提交改進建議。

詳情參見KIP過程:https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals