Kafka架构深入

Kafka架构

Kafka工作流程及文件存储机制

Kafka中消息是以topic进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。而topic是逻辑上的概念，并没有真实存在，真实存在的式topic下的partition，是一个物理概念，每一个partition对应于一个log文件，用于存储producer生产的数据，producer生产的数据会不断追加到该log文件的末端，每条数据均有与之对应的offset。而消费者组中每一个消费者，都会实时记录自己的消费offset，解决发生故障时，出现数据重复问题。

由于生产者生产的消息会不断的追加至log文件中，为防止log文件过大导致数据定位效率低下，Kafka采取分片和索引机制，将每个partition分为多个segment，每个segment对应两个文件，index和log文件。这些文件位于一个文件夹下，该文件夹命名为topic+分区序号。

Kafka生产者

分区策略

（1） 分区原因

	1.方便再集群中拓展：每个partition可以通过调整以适应它所在的机器而一个topic又可以有多个partition组成，
	因此整个集群就可以适应任意大小的数据。
	2.提高并发度。Kafka以partition为单位进行读写操作。

（2） 分区原则

	[1] 在指明partition的情况下，直接将指明的partition作为分区。
	[2] 没有指明partition但有key的情况下,将key的hash值于topic的partition书进行取余得到partition值
	[3] 既没有partition值也没有key值，第一次调用生成一个随机数，之后每次调用在这个随机数上自增。
	将这个值于topic的partition个数取余计算得到partition值，即为round-robin算法

数据可靠性保证

为保证producer发送的数据，能够可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要想producer发送ack，如果producer收到ack，就会进行下一轮的发送，否则，从新发送数据。
（1） 副本数据同步策略

Kafka选择第二种方案，Kafka每个分区有大量的数据，第一种方案会造成数据冗余。
（2） ISR
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应答机制
Kafka 为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡， 选择以下的配置
acks：
0：producer不等待broker的ack，这一操作提供了一个最低延迟，broker接收到，还没有写入磁盘就已经返回，当broker故障时可能丢失数据。
1：producer等待broker的ack，partition的leader落盘成功后（不等待follower回复）返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据。
-1（all）：producer等待broker的ack，partition的leader和follower全部罗盘成功后返回ack，当follower同步万册灰姑娘，broker返送ack之前，leader故障，会发生数据重复。
（4） 故障处理

LEO：每个副本最大的offset
HW：消费者能见到的最大offset，ISR队列中最小的LEO

	【1】 follower故障
		follower发生故障后会被临时踢出ISR，待改follower恢复后，follower会读取本地磁盘记录的上次的HW，
		将log文件中高于HW的部分截取掉，从HW开始向leader进行同步，等待改follower的LEO大于等于partition的HW，
		就可以重新加入ISR。
	【2】 leader故障
		leader发生故障后，会从ISR中选出一个新的leader，将其余follower高于HW的部分截取掉，然后从新的leader中同步数据，
		直至LEO大于等于leader

Kafka消费者

Consumer消费模式

Consumer采取pull模式从broker中读取数据。
push模式很难处理消费速率不对等的问题，会造正Consumer来不及处理消息，而pull模式则可以分局Consumer自身消费能力，适当速率消费消息。
pull模式的不足之处在于如果Kafka没有数据，则Consumer则会陷入轮询循环，一直返回空数据。针对这一点，Kafka消费者在消费数据时会传入一个timeout，如果当前没有数据可供消费，Consumer则会等待一段时间之后返回，这段时间即为timeout

分区分配策略

一个Consumer Group中有多个Consumer，一个Topic中有多个partition，所以会涉及到partition的分配问题，Kafka有两种分配策略

   1.RoundRobin：消费者组订阅的主题一致，轮询分配。

   2.Range：按主题分配，可能会带来消费者数据不对等问题。

offset的维护

由于Consumer在消费过程中可能会出现断电宕机等故障，Consumer恢复后，需要从故障前的位置继续消费，所以Consumer需要实时记录自己消费到了那个offset，以便故障恢复之后继续消费。Kafka 0.9 版本之前，consumer 默认将 offset 保存在 Zookeeper 中，从 0.9 版本开始， consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为 __consumer_offsets-n。