（1）方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器，而一个 topic
又可以有多个 Partition 组成，因此整个集群就可以适应任意大小的数据了；
（2）可以提高并发，因为可以以 Partition 为单位读写了。分区的原则
我们需要将 producer 发送的数据封装成一个 ProducerRecord 对象。
2、数据的可靠性
为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic 的每个 partition 收到 producer 发送的数据后，都需要向 producer 发送 ack（acknowledgement 确认收到），如果 producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。
副本数据同步机制
Kafka 选择了第二种方案，原因如下：
同样为了容忍 n 台节点的故障，第一种方案需要 2n+1 个副本，而第二种方案只需要 n+1 个副本，而 Kafka 的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。虽然第二种方案的网络延迟会比较高，但网络延迟对 Kafka 的影响较小。 Leader选举（选取ISR表中follower 速度慢）
ISR（in-sync replicas）列表。每个分区的 leader 会维护一个 ISR 列表，ISR 列表里面就是 follower 副本的 Borker 编号，只有“跟得上” Leader 的 follower 副本才能加入到 ISR 里面，这个是通过 replica.lag.time.max.ms 参数配置的。只有 ISR 里的成员才有被选为 leader 的可能。
当 Leader 挂掉了，而且 unclean.leader.election.enable=false 的情况下，Kafka 会从 ISR 列表中选择第一个 follower 作为新的 Leader，因为这个分区拥有最新的已经 committed 的消息。通过这个可以保证已经 committed 的消息的数据可靠性。
因此，为了保证数据的可靠性，需要配置一下几个参数：
producer 级别：acks=all（或者 request.required.acks=-1），同时发生模式为同步producer.type=sync topic 级别：设置 replication.factor>=3，并且min.insync.replicas>=2；
broker 级别：关闭不完全的 Leader 选举，即 unclean.leader.election.enable=false；
即 ack机制设置为所有follower均收到消息才响应；（producer）发生模式设置为同步； 副本数设置大于等于3，最小同步数设置为2；关闭不完全的Leader选举。
总：leader会维持一个与其保持同步的replica集合，该集合就是ISR，每一个leader partition都有一个ISR，leader动态维护, 要保证kafka不丢失message，就要保证ISR这组集合存活(至少有一个存活)，并且消息commit成功,Partition leader 保持同步的 Partition Follower 集合, 当 ISR 中的Partition Follower ,完成数据的同步之后，就会给 leader 发送 ack 如果Partition follower长时间(replica.lag.time.max.ms) 未向leader同步数据，则该Partition Follower将被踢出ISR,Partition Leader 发生故障之后，就会从 ISR 中选举新的 Partition Leader。
Producer 往 Broker 发送消息ack应答机制：Kafka 在 Producer 里面提供了消息确认机制。也就是说我们可以通过配置来决定有几个副本收到这条消息才算消息发送成功。
对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，
所以没必要等 ISR 中的 follower 全部接收成功。
Kafka 为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡， 选择以下的配置。（在 0.8.2.X 版本之前是通过request.required.acks 参数设置的。
ack参数配置：
acks=0：producer不会等待任何来自服务器（broker）的响应(ack)。 这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢数据。
acks=1（默认值）：producer 等待brokerd的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据。
acks=-1（all）：producer 等待brokerd的ack，partition的leader和follower落盘成功后返回ack，但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。
Producer 发送消息还可以选择同步（默认，通过 producer.type=sync 配置） 或者异步（producer.type=async）模式。如果设置成异步，虽然会极大的提高消息发送的性能，但是这样会增加丢失数据的风险。如果需要确保消息的可靠性，必须将 producer.type 设置为 sync。
Topic 分区副本 (数据的冗余备份)在 Kafka 0.8.0 之前，Kafka 是没有副本的概念的，那时候人们只会用 Kafka 存储一些不重要的数据，因为没有副本，数据很可能会丢失。为了保证数据的可靠性，Kafka 从 0.8.0 版本开始引入了分区副本。
每个分区可以人为的配置几个副本（比如创建主题的时候指定 replication-factor，也可以在 Broker 级别进行配置 default.replication.factor），一般会设置为3。
Kafka 可以保证单个分区里的事件是有序的，分区可以在线（可用），也可以离线（不可用）。在众多的分区副本里面有一个副本是 Leader，其余的副本是 follower，所有的读写操作都是经过 Leader 进行的，同时 follower 会定期地去 leader 上复制数据。当 Leader 挂掉之后，其中一个 follower 会重新成为新的 Leader。通过分区副本，引入了数据冗余，同时也提供了 Kafka 的数据可靠性。