wadjdkdkdjjd的博客

首先groupId对50取模，看最后的结果是哪个分区节点，假如是1分区，那么1分区的协调器就是本次消费者组的老大，消费者纷纷向该协调器进行注册，协调器从中随机选择一个消费者作为本次消费的Leader，然后把本次消费的具体情况发送给Leader，让其制定一个消费计划（就是哪个消费者消费哪个分区），然后Leader发送给协调器，协调器再进行群发，将计划公布，各个消费者按照这个计划进行消费。Range、RoundRobin（轮询）、Sticky（粘性）、CooperativeSticky（配合的粘性）。

Kafka在将分区分配给消费者实例时，会遵循一定的分区分配策略。当消费者组内的消费者实例数量与分区数量相匹配时，每个消费者实例都可以处理一个或多个分区的数据，从而大大提高数据的处理效率。当多个消费者实例存在于同一个消费者组中时，Kafka会将主题的不同分区分配给这些消费者实例，以确保每个消费者实例都能处理到一部分数据，从而实现负载均衡。Topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是Producer生产的数据。

假如broker0中的controller中抢到了，那它就是说了算的人。假如Follower挂掉了，Leader和其他的Follower 继续往前存储数据，挂掉的节点从ISR集合中剔除，此时挂掉的Follower又重启了，它会先从上一次挂掉的节点的HW（最高水位线）开始同步数据，直到追上最后一个Follower为止,此时会重新回归ISR。3）选举规则是：在ISR中存活为前提，按照AR中排在前面的优先，比如：ar[1,0,2] ,isr[1,0,2],那么Leader会按照1，0，2 进行顺序的轮询。

由于数据同步的时候先进入Leader,随后同步给Follower，假如Follower挂掉了，Leader和其他的Follower 继续往前存储数据，挂掉的节点从ISR集合中剔除，此时挂掉的Follower又重启了，它会先从上一次挂掉的节点的HW开始同步数据，直到追上最后一个Follower为止,此时会重新回归ISR。HW(高水位线 High Water) 演示：所有副本中，最小的LEO。LEO演示-- 每一个副本最后的偏移量offset + 1。

（3）创建副本存储计划（所有副本存储在 broker0、broker1、broker2、broker3 中）。（7）启动 bigdata01、bigdata02、bigdata03 上的 kafka 集群。（3）创建副本存储计划（所有副本存储在 broker0、broker1、broker2 中）。由于我之前创建first这个主题的时候只有一个副本，不是三个副本，所以呢，演示效果不佳。（3）在 bigdata04 上，修改主机名称为 bigdata04。（2）开启 bigdata04，并修改 IP 地址。

1）生产者在发送3请求的时候，发生异常，发生异常需要重新发送，所以排在了后面，在进行落盘的时候，先落盘1，2 ，落盘3的时候发现是4，需要等，等到3出现为止，然后将 3，4 ，5排序，排序后再进行落盘。原因说明：因为在kafka1.x以后，启用幂等后，kafka服务端会缓存producer发来的最近5个request的元数据， 故无论如何，都可以保证最近5个request的数据都是有序的。顺序错乱了，会自动排序（开启幂等性）。=1（不需要考虑是否开启幂等性）。

Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader，负责管理集群broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。（4）停止掉 hadoop14 的 kafka 进程，并查看 Leader 分区情况。（3）停止掉 hadoop13 的 kafka 进程，并查看 Leader 分区情况。Controller 的信息同步工作是依赖于 Zookeeper 的。（1）创建一个新的 topic，4 个分区，4 个副本。

Zookeeper 存储的 Kafka 信息（1）启动 Zookeeper 客户端。（2）通过 ls 命令可以查看 kafka 相关信息。zk中有一个节点 consumers 这个里面，老版本0.9版本之前，存放的是消费者的偏移量（offset，这次消费者消费到哪个地方了，下次从这个地方继续消费），新版本的根本没放在zk中，直接放在集群中了。可以借助一个工具：漂亮的zoo，通过图形化界面查看zk中的消息。

②在 IDEA 中执行代码，观察 hadoop102 控制台中是否接收到消息。4、 RecordAccumulator：缓冲区大小，修改为64m。2、linger.ms：等待时间，修改为5-100ms。3、compression.type：压缩snappy。①在 bigdata01 上开启 Kafka 消费者。1、batch.size：批次大小，默认16k。

At Least Once可以保证数据不丢失，但是不能保证数据不重复；At Most Once可以保证数据不重复，但是不能保证数据不丢失。•。

2、Kafka Broker 服务端丢失消息。1 、生产者丢失消息。

如果我们要往 Kafka 对应的主题发送消息，我们需要通过 Producer 完成。把选项提供给用户自己去选择，我们可以通过配置来决定消息发送到对应分区的几个副本才算消息发送成功。另外，Producer 发送消息还可以选择同步（默认，通过 producer.type=sync 配置） 或者异步（producer.type=async）模式。如果设置成异步，虽然会极大的提高消息发送的性能，但是这样会增加丢失数据的风险。根据实际的应用场景，我们设置不同的 acks，以此保证数据的可靠性。

ISR 是动态调整的，根据副本的同步状态和延迟情况而变化。1）生产者在发送3请求的时候，发生异常，发生异常需要重新发送，所以排在了后面，在进行落盘的时候，先落盘1，2 ，落盘3的时候发现是4，需要等，等到3出现为止，然后将 3，4 ，5排序，排序后再进行落盘。生产者发送的数据，单分区内可以做到有序，多分区，无法保证，除非把多个分区的数据拉到消费者端，进行排序，但这样做需要等，效率很低，还不如直接设置一个分区。每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 Leader。