背景

之前kafka集群都是采用配置较低的方式部署，当集群到达瓶颈的时候三两台加，对集群维护带来很难度，所以决定使用高配机替换低配机，固定一个集群的标准节点在20-30个之内，每个topic分配分区的时候根据节点数来分配，确保每个节点都有一个分区，保证集群节点的资源均衡。

最好集群的副本数为3。如果是2的话，小心isr队列剩下1个的情况。

迁移的方式采用相老机器的brokerID与新机器的brokerID相同的方式，kafka自动完成数据同步复制

kafka机器迁移，broker会重启，leader会切换，producer可能会在重启瞬间发送失败，如producer无重试机制，数据将丢失。


建议配置

生产者客户端建议加入如下配置，防止kafka服务器维护时出现数据丢失的情况：

config

默认值

建议值

acks

1

all或-1 

消息副本确认数

0：消费发送无需确认，消息会丢失，retries失效

1：Leader确认收到即发送成功，消息可能会丢失

-1 或 all：所有副本确认收到消息后才返回成功，消息丢失可能性很小
retries

0

 Integer.MAX_VALUE

重试次数，生产者发送消息失败后的重试次数，默认值为0

当节点故障或维护时，消息可能会丢失
max.in.flight.requests.per.connection

5

1

该参数指定了生产者在收到服务器响应之前可以发送多少个消息。它的值越高，就会占用越多的内存，不过也会提升吞吐量。把它设为 1 可以保证消息是按照发送的顺序写入服务器的，即使发生了重试。




retries参数说明

参数的设置通常是一种取舍，看下retries参数在版本0.11.3说明：

Setting a value greater than zero will cause the client to resend

any record whose send fails with a potentially transient error.

Note that this retry is no different than if the client resent the

record upon receiving the error.

Allowing retries without setting max.in.flight.requests.per.connection to 1 will potentially change 

the ordering of records because if two batches are sent to a single

partition, and the first fails and is retried but the second succeeds,

then the records in the second batch may appear first.


备注：当发送失败时客户端会进行重试，重试的次数由retries指定，此参数默认设置为0。即：快速失败模式，当发送失败时由客户端来处理后续是否要进行继续发送。如果设置retries大于0而没有设置max.in.flight.requests.per.connection=1则意味着放弃发送消息的顺序性。


retries使用建议

使用retries的默认值交给使用方自己去控制，结果往往是不处理。所以通用设置建议设置如下：


retries = Integer.MAX_VALUE

max.in.flight.requests.per.connection = 1

备注：这样设置后，发送客户端会一直进行重试直到broker返回ack；同时只有一个连接向broker发送数据保证了数据的顺序性。在Leader选举、集群中一个broker挂掉时，发送端会一直重试直到Leader选举结束。避免由于客户端对异常未处理造成的数据丢失，例如：遇到类似“This server is not the leader for that topic-partition”会自动恢复。


retries后续发展

该参数的设置已经在kafka 2.4版本中默认设置为Integer.MAX_VALUE；同时增加了delivery.timeout.ms的参数设置。


The default value for the producer's retries config was changed to

Integer.MAX_VALUE, as we introduced delivery.timeout.ms in KIP-91,

which sets an upper bound on the total time between sending a

record and receiving acknowledgement from the broker.

By default, the delivery timeout is set to 2 minutes.


KIP-91: https://cwiki.apache.org/confluence/display/KAFKA/KIP-91+Provide+Intuitive+User+Timeouts+in+Th