2.kafka架构深入—

一个topic有多个partition，每个partition又有多个副本，在这些副本中又有一个leader和多个follower。

1）分区的原因

（1）方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；

（2）可以提高并发，因为可以以Partition为单位读写了。

2）分区的原则

我们需要将producer发送的数据封装成一个ProducerRecord对象。

（1）指明 partition 的情况下，直接将指明的值直接作为 partiton 值；

（2）没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值；

（3）既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition 值，也就是常说的 round-robin 算法。

生产者发送到topic的数据可靠性保证

为保证producer发送的数据，能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要向producer发送ack（acknowledgement确认收到），如果producer收到ack，就会进行下一轮的发送，否则重新发送数据。

设想这样一种场景：

Producer向partition中的leader发送消息，在leader收到消息后，向Producer发送ack表示已经收到消息。然后leader开始准备向同一个partition中的其他的follower同步消息，假如这个时候leader突然挂掉，那么集群中开始选举其他的follower成为leader，其他的follower成为leader之后，内部并没有刚刚发来的那条消息，而producer已经收到了之前leader发来的ack，也不会发送这条消息了，这就造成了消息漏消费的情况，那如何解决这个问题呢？很简单，等leader给follower同步消息之后再给Producer发送ack确认通知就可以了，那么就产生一个问题：同步到什么地步或者说同步几台follower之后发送ack？

多少个folower同步完成之后发送ask？有两个方案：

第一个方案：半数以上的follower同步完成，即可发送ack

第二个方案：不用选举，全部的follower同步完成，才可以发送ack

1、为什么要获取半数以上的投票才能成为新的leader？

防止脑裂。半数以上的话只能有一个

2、参与投票的至少几个？

半数以上

3、如何才能确保一定能够选出一个合格的leader

半数以上的同步完成。

9个副本，有5个同步完成的，如果挂掉4个节点，根据2中可知：参与投票的至少是5个，里面至少会有一个同步完成的，（选举的规则是选举同步完成的），那肯定可以保证选举成功。

所以说第一个方案：半数以上的follower同步完成，即可发送ack

第一种方案：优点：延迟低
缺点：选举新的leader时，容忍n台节点的故障，需要2n+1个副本。（如果集群有2n+1台机器，选举leader的时候至少需要半数以上即n+1台机器投票，那么能容忍的故障，最多就是n台机器发生故障）容错率：1/2

第二种方案：优点：选举新的leader时，容忍n台节点的故障，需要n+1个副本。（如果集群有n+1台机器，选举leader的时候只要有一个副本就可以了）容错率：1

缺点：延迟高

Kafka选择了第二种方案，原因如下：

1.同样为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。

2.虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka的影响较小。

2）ISR

采用第二种方案之后，设想以下情景：leader收到数据，所有follower都开始同步数据，但有一个follower，因为某种故障，迟迟不能与leader进行同步，那leader就要一直等下去，直到它完成同步，才能发送ack。这个问题怎么解决呢？

Leader维护了一个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给producer发送ack。如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后，就会从ISR中选举新的leader。

3）ack应答机制

对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。
所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。
acks参数配置：
acks：
0：producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；
1：producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；

-1（all）：producer等待broker的ack，partition的leader和ISR中的follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。

4）故障处理细节

Log文件中的HW和LEO

LEO:(Log End Offset)每个副本的最后一个offset

HW：(High Watermark)所有副本中最小的LEO

（1）follower故障

follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。

（2）leader故障

leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。

注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

生产者幂等性

将服务器的ACK级别设置为-1，可以保证Producer到Server之间不会丢失数据，即At Least Once语义。相对的，将服务器ACK级别设置为0，可以保证生产者每条消息只会被发送一次，即At Most Once语义。

At Least Once可以保证数据不丢失，但是不能保证数据不重复；相对的，At Most Once可以保证数据不重复，但是不能保证数据不丢失。但是，对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据既不重复也不丢失，即Exactly Once语义。在0.11版本以前的Kafka，对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局去重。对于多个下游应用的情况，每个都需要单独做全局去重，这就对性能造成了很大影响。

0.11版本的Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指Producer不论向Server发送多少次重复数据，Server端都只会持久化一条。幂等性结合At Least Once语义，就构成了Kafka的Exactly Once语义。即：

At Least Once + 幂等性 = Exactly Once

要启用幂等性，只需要将Producer的参数中enable.idompotence设置为true即可（kafka自动将acks属性设为-1，并将retries属性设为Integer.MAX_VALUE。）。Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的Producer在初始化的时候会被分配一个PID，发往同一Partition的消息会附带Sequence Number。而Broker端会对<PID, Partition, SeqNumber>做缓存，当具有相同主键的消息提交时，Broker只会持久化一条。

Producer重启，PID就会变化，所以幂等性只能保证单会话的Exactly Once。

Kafka生产者事务

Kafka从0.11版本开始引入了生产者事务，事务可以实现生产者向不同分区、不同topic发送的多条消息的原子性。

为了实现跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID，并将Producer获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的Transaction ID获得原来的PID，开启事务后，生产者能够实现跨会话的幂等性。