Kafka滚动重启:数据丢失

时间:2015-09-28 16:10:10

标签: apache-kafka high-availability

作为我们当前Kafka集群的一部分,正在进行高可用性测试(HA)。目标是,当生产者工作将数据推送到主题的特定分区时,Kafka集群中的所有代理将按顺序重新启动(Stop-first broker-重新启动它,在第一个代理启动后,为第二个代理执行相同的步骤,不久)。在进行此项测试时,生产者工作正在推动约700万条记录约30分钟。在工作结束时,人们注意到大约有1000个记录缺失。

以下是我们Kafka群集的具体信息:(kafka_2.10-0.8.2.0)

-3 Kafka经纪人,每人有2个100GB坐骑

使用以下内容创建主题 - 复原因子3 -min.insync.replica = 2

server.properties:

broker.id=1
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=1048576
socket.receive.buffer.bytes=1048576
socket.request.max.bytes=104857600
log.dirs=/drive1,/drive2
num.partitions=1
num.recovery.threads.per.data.dir=1
log.flush.interval.messages=10000
log.retention.hours=1
log.segment.bytes=1073741824
log.retention.check.interval.ms=1800000
log.cleaner.enable=false
zookeeper.connect=ZK1:2181,ZK2:2181,ZK3:2181
zookeeper.connection.timeout.ms=10000
advertised.host.name=XXXX
auto.leader.rebalance.enable=true
auto.create.topics.enable=false
queued.max.requests=500
delete.topic.enable=true
controlled.shutdown.enable=true
unclean.leader.election=false
num.replica.fetchers=4
controller.message.queue.size=10

Producer.properties(具有新生产者API的aync生产者)

bootstrap.servers=broker1:9092,broker2:9092,broker3:9092
acks=all
buffer.memory=33554432
compression.type=snappy
batch.size=32768
linger.ms=5
max.request.size=1048576
block.on.buffer.full=true
reconnect.backoff.ms=10
retry.backoff.ms=100
key.serializer=org.apache.kafka.common.serialization.ByteArraySerializer
value.serializer=org.apache.kafka.common.serialization.ByteArraySerializer

有人可以共享有关Kafka-cluster和HA的任何信息,以确保在重新启动Kafka经纪人时不会丢失数据吗?

此外,这是我的生产者代码。这是一场火灾,忘了那种生产者。我们目前没有明确处理故障。适用于几乎数百万条记录。我看到问题,只有当Kafka经纪人重新启动时,如上所述。

public void sendMessage(List<byte[]> messages, String destination, Integer parition, String kafkaDBKey) {

    for(byte[] message : messages) {

        producer.send(new ProducerRecord<byte[], byte[]>(destination, parition, kafkaDBKey.getBytes(), message));

    }

}

1 个答案:

答案 0 :(得分:1)

通过在生产者端将默认重试值从0增加到4000,我们可以成功发送数据而不会丢失。 retries=4000

  • 由于此设置,有可能两次发送相同的消息,并且消费者收到消息时消息不按顺序(第二个msg可能在第一个消息之前到达)。但对于我们当前的问题,这不是一个问题,并在消费者一方面处理,以确保一切正常。