Kafka_kafka发送数据指定partition

Kafka

Kafka 是否会弄丢数据？

主要取决于我们如何使用。

消费端弄丢了数据？

• 只要关闭自动提交 offset ，在处理完之后自己手动提交 offset ，就可以保证数据不会丢。可能会有重复消费，需要保证幂等性

Broker 弄丢了数据？

• replication.factor 参数：这个值必须大于 1要求每个 partition 必须有至少 2 个副本。
• min.insync.replicas 参数：这个值必须大于 1 ，要求一个 leader 至少感知到有至少一个 follower 还跟自己保持联系，没掉队
• 在 Producer 端设置 acks=all：这个是要求每条数据，必须是写入所有 replica 之后，才能认为是写成功了
• 在 Producer 端设置 retries=MAX，这个是要求一旦写入失败，就无限重试，卡在这里了
• 生产环境就是按照上述要求配置的，可以保证在 leader 所在 Broker 发生故障，进行 leader 切换时，数据不会丢失。

生产者会不会弄丢数据？

• 按照上述的思路设置了 acks=all ，一定不会丢，要求是，你的 leader 接收到消息，所有的 follower 都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。

Kafka 如何保证消息的顺序性？

方式一，Consumer ，对每个 Partition 内部单线程消费，单线程吞吐量太低，一般不会用这个。

方式二，Consumer ，拉取到消息后，写到 N 个内存 queue，具有相同 key 的数据都到同一个内存 queue 。然后，对于 N 个线程，每个线程分别消费一个内存 queue 即可，这样就能保证顺序性。

实际情况也不太需要考虑消息的顺序性，基本没有业务需要。

ZooKeeper 在 Kafka 中起到什么作用？

Broker、Producer、Consumer 和 Zookeeper 的交互。

• Broker 在 ZooKeeper 中的注册。
• Topic 在 ZooKeeper 中的注册。
• Consumer 在 ZooKeeper 中的注册。
• Consumer 负载均衡。

相应的状态存储到 Zookeeper 中。

• Producer 负载均衡。

  • Producer 从 Zookeeper 拉取 Topic 元数据，从而能够将消息发送负载均衡到对应 Topic 的分区中

• 记录消费进度 Offset 。

• 记录 Partition 与 Consumer 的关系。