Apache kafka 生產集群設置問題

Question

我們一直在嘗試在 AWS Linux 機器上建立一個生產級別的 Kafka 集群，但直到現在我們還沒有成功。

卡夫卡版本：2.1.0

機器：

5 r5.xlarge machines for 5 Kafka brokers.
3 t2.medium zookeeper nodes
1 t2.medium node for schema-registry and related tools. (a Single instance of each)
1 m5.xlarge machine for Debezium.

默認經紀人配置：

num.partitions=15
min.insync.replicas=1
group.max.session.timeout.ms=2000000 
log.cleanup.policy=compact
default.replication.factor=3
zookeeper.session.timeout.ms=30000

我們的問題主要與海量數據有關。 我們正在嘗試使用 debezium 將我們現有的表轉移到 kafka 主題中。 其中許多表都非常龐大，超過 50000000 行。

到目前為止，我們已經嘗試了很多事情，但是我們的集群每次都因為一個或多個原因而失敗。

計划任務 'isr-expiration' (kafka.utils.KafkaScheduler) org.apache.zookeeper.KeeperException$SessionExpiredException 中的錯誤未捕獲異常：KeeperErrorCode = org.apache 的 /brokers/topics/__consumer_offsets/partitions/0/state 會話已過期。 zookeeper.KeeperException.create(KeeperException.java:130) 在 org.apache.zookeeper.KeeperException.create(KeeperException.java:54)..

錯誤二：

] INFO [Partition xxx.public.driver_operation-14 broker=3] Cached zkVersion [21] 不等於 zookeeper 中的版本，跳過更新 ISR (kafka.cluster.Partition) [2018-12-12 14:07:26,551] INFO [Partition xxx.public.hub-14 broker=3] 將 ISR 從 1,3 縮小到 3 (kafka.cluster.Partition) [2018-12-12 14:07:26,556] INFO [Partition xxx.public.hub-14 broker=3] 緩存的 zkVersion [3] 不等於 zookeeper 中的版本，跳過更新 ISR (kafka.cluster.Partition) [2018-12-12 14:07:26,556] INFO [Partition xxx.public.field_data_12_2018-7 broker= 3] 將 ISR 從 1,3 縮小到 3 (kafka.cluster.Partition)

錯誤三：

isolationLevel=READ_UNCOMMITTED, toForget=, metadata=(sessionId=888665879, epoch=INITIAL)) (kafka.server.ReplicaFetcherThread) java.io.IOException: 在 org.apache.kafka.clients 讀取響應之前斷開與 3 的連接.NetworkClientUtils.sendAndReceive(NetworkClientUtils.java:97)

還有一些錯誤：

1. broker 之間經常斷開連接，這可能是 ISR 不停地收縮和擴展而沒有自動恢復的原因。
2. 架構注冊表超時。 我不知道模式注冊表是如何受到影響的。 我沒有看到該服務器上有太多負載。 我錯過了什么嗎？ 我應該為模式注冊表的多個實例使用負載平衡器作為故障轉移嗎？ . 主題 __schemas 中只有 28 條消息。 確切的錯誤消息是 RestClientException：注冊操作超時。 錯誤代碼：50002

3. 有時消息傳輸速率超過每秒 100000 條消息，有時會下降到每秒 2000 條消息？ 消息大小可能導致這個？

   為了解決上面的一些問題，我們增加了 broker 的數量，增加了 zookeeper.session.timeout.ms=30000 但我不確定它是否真的解決了我們的問題，如果解決了，又是如何解決的？

我有幾個問題：

1. 我們的集群是否足以處理這么多數據。
2. 有什么明顯的我們遺漏的嗎？
3. 在進入生產級別之前如何對我的設置進行負載測試？
4. 什么可能導致代理和模式注冊表之間的會話超時。
5. 處理架構注冊表問題的最佳方法。

我們的一位經紀人的網絡負載。

隨時詢問更多信息。

Answer 1

請使用最新官方版本的Confluent for you 集群。

實際上，您可以通過增加主題的分區數量並增加連接器中的tasks.max （當然在您的接收器連接器中）超過 1 來使其更好地同時工作並更快地工作。

請增加 Kafka-Connect 主題的數量並使用Kafka-Connect 分布式模式來提高 Kafka-connect 集群的高可用性。 您可以通過在Kafka-Connect和Schema-Registry配置中設置復制因子的數量來實現，例如：

config.storage.replication.factor=2
status.storage.replication.factor=2
offset.storage.replication.factor=2

請為您的大表將topic compression設置為snappy 。 它將增加主題的吞吐量，這有助於Debezium連接器更快地工作並且不使用JSON 轉換器，建議使用Avro 轉換器！

另外請為您的模式注冊表使用負載平衡器

為了測試集群，您可以使用database.whitelist創建一個只有一個表（我的意思是一個大表！）的連接器，並將snapshot.mode設置為initial

關於架構注冊表！ Schema-registry 使用Kafka和Zookeeper設置這些配置：

bootstrap.servers
kafkastore.connection.url

這就是 shema-registry 集群停機的原因