Kafka python 客戶端在分配和重新平衡之間交替而不處理數據
[英]Kafka python client alternating between assigned and rebalancing not processing data
問題描述
我有一個有 40 個分區的 Kafka 主題。 在 Kubernetes 集群中。 我還有一個使用這個主題的微服務。
有時，在批處理過程中，有時會出現一些分區未處理的數據，而大多數分區已完成。 使用kafka-consumer-groups.sh這看起來像這樣：
TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
- - - - - kafka-python-2.0.1-f1259971-c8ed-4d98-ba37-40f263b14a78/10.44.2.119 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-328f6a97-22ea-4f59-b702-4173feb9f025/10.44.0.29 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-9a2ea04e-3bf1-40f4-9262-6c14d0791dfc/10.44.7.35 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-81f5be15-535c-436c-996e-f8098d0613a1/10.44.4.26 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-ffcf76e2-f0ed-4894-bc70-ee73220881db/10.44.14.2 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-fc5709a0-a0b5-4324-92ff-02b6ee0f1232/10.44.2.123 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-c058418c-51ec-43e2-b666-21971480665b/10.44.15.2 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-0c14afab-af2a-4668-bb3c-015932fbfd13/10.44.14.5 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-1cb308f0-203f-43ae-9252-e0fc98eb87b8/10.44.14.4 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-42753a7f-80d0-481e-93a6-67445cb1bb5e/10.44.14.6 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-63e97395-e1ec-4cab-8edc-c5dd251932af/10.44.2.122 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-7116fdc2-809f-4f99-b5bd-60fbf2aba935/10.44.1.37 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-f5ef8ff1-f09c-498e-9b27-1bcac94b895b/10.44.2.125 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-8feec117-aa3a-42c0-91e8-0ccefac5f134/10.44.2.121 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-45cc5605-d3c8-4c77-8ca8-88afbde81a69/10.44.14.3 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-9a575ac4-1531-4b2a-b516-12ffa2496615/10.44.5.32 kafka-python-2.0.1
- - - - - kafka-python-2.0.1-d33e112b-a1f4-4699-8989-daee03a5021c/10.44.14.7 kafka-python-2.0.1
my-topic 20 890 890 0 - - -
my-topic 38 857 857 0 - - -
my-topic 28 918 918 0 - - -
my-topic 23 66 909 843 - - -
my-topic 10 888 888 0 - - -
my-topic 2 885 885 0 - - -
my-topic 7 853 853 0 - - -
my-topic 16 878 878 0 - - -
my-topic 15 47 901 854 - - -
my-topic 26 934 934 0 - - -
my-topic 32 898 898 0 - - -
my-topic 21 921 921 0 - - -
my-topic 13 933 933 0 - - -
my-topic 5 879 879 0 - - -
my-topic 12 945 945 0 - - -
my-topic 4 918 918 0 - - -
my-topic 29 924 924 0 - - -
my-topic 39 895 895 0 - - -
my-topic 25 30 926 896 - - -
my-topic 9 915 915 0 - - -
my-topic 35 31 890 859 - - -
my-topic 3 69 897 828 - - -
my-topic 1 911 911 0 - - -
my-topic 6 22 901 879 - - -
my-topic 14 41 881 840 - - -
my-topic 30 900 900 0 - - -
my-topic 22 847 847 0 - - -
my-topic 8 919 919 0 - - -
my-topic 0 902 902 0 - - -
my-topic 18 924 924 0 - - -
my-topic 36 864 864 0 - - -
my-topic 34 929 929 0 - - -
my-topic 24 864 864 0 - - -
my-topic 19 937 937 0 - - -
my-topic 27 859 859 0 - - -
my-topic 11 838 838 0 - - -
my-topic 31 49 922 873 - - -
my-topic 37 882 882 0 - - -
my-topic 17 942 942 0 - - -
my-topic 33 928 928 0 - - -
它還進一步指出，消費者群體正在rebalancing 。 這里要注意的一件事是，在CONSUMER-ID下，應有的消費者較少。 它應該是 20 個消費者，但在此輸出中，即使所有 pod 都在運行，也只顯示了 17 個。 這個數字各不相同，我不確定這是輸出問題還是它們真的不存在。 這也讓我感到困惑，因為當我最初開始（所有新的 Kafka 和消費者部署）時，這不會發生。 因此，它似乎確實與消費者部署的擴展或以其他方式被殺死有關。
然后會在短時間內分配消費者，大約半分鍾后，與上圖相同的圖片再次顯示消費者組正在重新平衡的位置。
當我縮小規模時也會發生這種情況。 例如，當我只有 4 個消費者時。 我不確定這里發生了什么。 Pod 都在運行，我在其他微服務中使用了相同類型的基本代碼和模式，在這些微服務中似乎可以正常工作。
我懷疑這與消費者 pod 被殺死有關，因為正如我所說，它最初可以在新部署中工作。 該批次也比我擁有的其他批次運行時間更長，因此在運行期間更有可能殺死 pod。 我也不確定它是否與大多數已經完成的分區有關，這也可能只是我的用例的一個怪癖。
我認識到這一點，因為處理似乎需要永遠，但仍在處理新數據。 所以我認為發生的事情是，在分配消費者的短暫時刻，他們處理數據，但在重新平衡之前他們從未提交偏移量，從而使他們處於無限循環中。 我發現的唯一稍微相關的事情是這個問題，但它來自之前的一些版本，並沒有完全描述我的情況。
我使用kafka-python 客戶端，我使用 kafka 圖像confluentinc/cp-kafka:5.0.1 。
我使用管理客戶端NewTopic(name='my-topic', num_partitions=40, replication_factor=1)創建NewTopic(name='my-topic', num_partitions=40, replication_factor=1)並像這樣創建客戶端：
consumer = KafkaConsumer(consume_topic,
bootstrap_servers=bootstrap_servers,
group_id=consume_group_id,
value_deserializer=lambda m: json.loads(m))
for message in consumer:
process(message)
這里出了什么問題？ 我有一些配置錯誤嗎？
任何幫助是極大的贊賞。
1 個解決方案
解決方案1
0 2020-10-22 12:33:16
問題出在心跳配置上。 事實證明，雖然大多數消息只需要幾秒鍾來處理，但很少有消息需要很長時間來處理。 在這些特殊情況下，某些消費者的心跳更新時間太長，導致代理假設消費者已關閉並開始重新平衡。
我假設接下來發生的事情是消費者被重新分配到同一條消息，再次處理它需要很長時間並觸發另一個重新平衡。 導致無限循環。
我最終通過增加消費者中的session_timeout_ms和heartbeat_interval_ms來解決它（記錄在這里）。 我還減少了批量大小，以便更定期地更新心跳。
Python 在分數之間交替使用 + 和 -
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.