From 62b6840fe72f31640d0c4fd4995846e24a4d4290 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=BD=97=E7=A5=A5?= <1366971433@qq.com> Date: Mon, 3 Jun 2019 17:52:58 +0800 Subject: [PATCH] =?UTF-8?q?=E6=B7=B1=E5=85=A5=E7=90=86=E8=A7=A3Kafka?= =?UTF-8?q?=E5=89=AF=E6=9C=AC=E6=9C=BA=E5=88=B6?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- notes/Kafka深入理解分区副本机制.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/notes/Kafka深入理解分区副本机制.md b/notes/Kafka深入理解分区副本机制.md index b75798e..1452bb4 100644 --- a/notes/Kafka深入理解分区副本机制.md +++ b/notes/Kafka深入理解分区副本机制.md @@ -53,7 +53,7 @@ Kafka 的主题被分为多个分区 ，分区是Kafka最基本的存储单位 ### 2.3 不完全的首领选举 -对于副本机制，在broker级别有一个可选的配置参数`unclean.leader.election.enable`，默认值为fasle，代表禁止不完全的首领选举。这是针对当首领副本挂掉且ISR中没有其他可用副本时，是否允许某个不完全同步的副本成为首领副本，这可以会导致数据丢失或者数据不一致，在某些对数据一致性要求较高的场景(如金融领域)，这可能无法容忍的，所以其默认值为false，如果你能够允许部分数据不一致的话，可以配置为true。 +对于副本机制，在broker级别有一个可选的配置参数`unclean.leader.election.enable`，默认值为fasle，代表禁止不完全的首领选举。这是针对当首领副本挂掉且ISR中没有其他可用副本时，是否允许某个不完全同步的副本成为首领副本，这可能会导致数据丢失或者数据不一致，在某些对数据一致性要求较高的场景(如金融领域)，这可能无法容忍的，所以其默认值为false，如果你能够允许部分数据不一致的话，可以配置为true。 ### 2.4 最少同步副本 @@ -61,11 +61,11 @@ ISR机制的另外一个相关参数是`min.insync.replicas` , 可以在broker ### 2.5 发送确认 -Kafka在生产者上有一个可选的参数ack，该参数指定了必须要有多少个分区副本收到消息，生产者才会认为消息写入是成功的： +Kafka在生产者上有一个可选的参数ack，该参数指定了必须要有多少个分区副本收到消息，生产者才会认为消息写入成功： -- acks=0 ：消息发送出去就认为已经成功了，不会等待任何来自服务器的响应； -- acks=1 ： 只要集群的首领节点收到消息，生产者就会收到一个来自服务器成功响应； -- acks=all ：只有当所有参与复制的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应。 +- **acks=0** ：消息发送出去就认为已经成功了，不会等待任何来自服务器的响应； +- **acks=1** ： 只要集群的首领节点收到消息，生产者就会收到一个来自服务器成功响应； +- **acks=all** ：只有当所有参与复制的节点全部收到消息时，生产者才会收到一个来自服务器的成功响应。 ## 三、数据请求 @@ -73,9 +73,9 @@ Kafka在生产者上有一个可选的参数ack，该参数指定了必须要有 在所有副本中，只有领导副本才能进行消息的读写处理。由于不同分区的领导副本可能在不同的broker上，如果某个broker收到了一个分区请求，但是该分区的领导副本并不在该broker上，那么它就会向客户端返回一个`Not a Leader for Partition`的错误响应。 为了解决这个问题，Kafka提供了元数据请求机制。 -首先集群中的每个broker都会缓存所有主题的分区副本信息，客户端会定期发送发送元数据请求，然后将获取的元数据进行缓存。定时刷新元数据的时间间隔可以通过为客户端配置`metadata.max.age.ms`来进行指定。 +首先集群中的每个broker都会缓存所有主题的分区副本信息，客户端会定期发送发送元数据请求，然后将获取的元数据进行缓存。定时刷新元数据的时间间隔可以通过为客户端配置`metadata.max.age.ms`来进行指定。有了元数据信息后，客户端就知道了领导副本所在的broker，之后直接将读写请求发送给对应的broker即可。 -如果在定时请求的时间间隔内发生的分区副本的选举，则意味着原来缓存的信息可能已经过时了，此时有可能会收到`Not a Leader for Partition`的错误响应，这种情况下客户端会再次求发出元数据请求，然后刷新本地缓存，之后再去正确的broker上执行对应的操作，过程如下图： +如果在定时请求的时间间隔内发生的分区副本的选举，则意味着原来缓存的信息可能已经过时了，此时还有可能会收到`Not a Leader for Partition`的错误响应，这种情况下客户端会再次求发出元数据请求，然后刷新本地缓存，之后再去正确的broker上执行对应的操作，过程如下图：
@@ -153,10 +153,9 @@ Exception: Replication factor: 3 larger than available brokers: 1.
-### + ## 参考资料 1. Neha Narkhede, Gwen Shapira ,Todd Palino(著) , 薛命灯(译) . Kafka权威指南 . 人民邮电出版社 . 2017-12-26 - 2. [Kafka高性能架构之道](http://www.jasongj.com/kafka/high_throughput/)