5

我们一直在尝试在 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)..

错误2：

] INFO [Partition xxx.public.driver_operation-14 broker=3] 缓存的 zkVersion [21] 不等于 zookeeper 中的，跳过更新 ISR (kafka.cluster.Partition) [2018-12-12 14:07:26,551] INFO [分区 xxx.public.hub-14 broker=3] 将 ISR 从 1,3 缩小到 3 (kafka.cluster.Partition) [2018-12-12 14:07:26,556] INFO [分区 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)

错误 3：

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. 代理之间经常断开连接，这可能是 ISR 不断收缩和扩展而没有自动恢复的原因。
  2. 架构注册表超时。我不知道模式注册表是如何受到影响的。我没有看到该服务器上的负载过多。我错过了什么吗？我应该为架构注册表的多个实例使用负载均衡器作为故障转移吗？. __schemas 主题中只有 28 条消息。确切的错误消息是 RestClientException: Register operation timed out。错误代码：50002

  3. 有时消息传输率超过 100000 条消息/秒，有时它下降到 2000 条消息/秒？消息大小可能会导致这种情况？

    为了解决上面的一些问题，我们增加了brokers的数量并增加了zookeeper.session.timeout.ms=30000，但我不确定它是否真的解决了我们的问题，如果解决了，如何解决？

我有几个问题：

  1. 我们的集群是否足以处理这么多数据。
  2. 有什么明显的我们遗漏的吗？
  3. 如何在进入生产级别之前对我的设置进行负载测试？
  4. 什么可能导致代理和模式注册表之间的会话超时。
  5. 处理模式注册表问题的最佳方法。

我们的一位经纪人的网络负载。

网络字节在我们的一位经纪人中

随时询问更多信息。

4

1 回答 1

0

请为您的集群使用最新的官方版本的Confluent。

实际上，您可以通过增加主题的分区数量并在连接器中增加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.whitelistand 设置snapshot.mode 为initial

关于模式注册表！Schema-registry 用户同时使用Kafka和Zookeeper设置这些配置：

bootstrap.servers
kafkastore.connection.url

这就是你的 shema-registry 集群停机的原因

于 2020-04-05T17:08:45.797 回答