架构师之路-如何建立高可用消息中间件kafka？( 八 )

文章插图
测试结果分析（与情景1一致）：
副本数越多。TPS越低；
客户端的acks策略对发送的TPS有较大的影响。TPS：acks_0 > acks_1 > ack_-1 。
场景4：通过将集群中部分broker设置成不可服务状态。测试对客户端以及消息落盘的影响。
具体配置：一个producer；消息体大小1KB;发送方式为sync；topic副本数为4；min.insync.replicas设置为2；acks=-1；retries=0/100000000；partition数为12 。
具体测试数据如下表：

文章插图
出错信息：
错误1：客户端返回异常。部分数据可落盘。部分失败：org.apache.kafka.common.errors.NetworkException: The server disconnected before a response was received.
错误2：[WARN]internals.Sender - Got error produce response with correlation id 19369 on topic-partition default_channel_replicas_4_1-3, retrying (999999999 attempts left). Error: NETWORK_EXCEPTION
错误3： [WARN]internals.Sender - Got error produce response with correlation id 77890 on topic-partition default_channel_replicas_4_1-8, retrying (999999859 attempts left). Error: NOT_ENOUGH_REPLICAS
错误4： [WARN]internals.Sender - Got error produce response with correlation id 77705 on topic-partition default_channel_replicas_4_1-3, retrying (999999999 attempts left). Error: NOT_ENOUGH_REPLICAS_AFTER_APPEND
测试结果分析：
kill两台broker后。客户端可以继续发送。broker减少后。partition的leader分布在剩余的两台broker上。造成了TPS的减小；
kill三台broker后。客户端无法继续发送。Kafka的自动重试功能开始起作用。当大于等于min.insync.replicas数量的broker恢复后。可以继续发送；
当retries不为0时。消息有重复落盘；客户端成功返回的消息都成功落盘。异常时部分消息可以落盘。
场景5：测试单个producer的发送延迟。以及端到端的延迟。
具体配置：：一个producer；消息体大小1KB；发送方式为sync；topic副本数为4；min.insync.replicas设置为2；acks=-1；partition数为12 。
测试数据及结果（单位为ms）：

文章插图
各场景测试总结：
当acks=-1时。Kafka发送端的TPS受限于topic的副本数量（ISR中）。副本越多TPS越低；
acks=0时。TPS最高。其次为1 。最差为-1 。即TPS：acks_0 > acks_1 > ack_-1；
min.insync.replicas参数不影响TPS；
partition的不同会影响TPS 。随着partition的个数的增长TPS会有所增长。但并不是一直成正比关系。到达一定临界值时。partition数量的增加反而会使TPS略微降低；
【架构师之路-如何建立高可用消息中间件kafka？】Kafka在acks=-1,min.insync.replicas>=1时。具有高可靠性。所有成功返回的消息都可以落盘。