3.1kafka基础解析，运行原理.

1.基础概念

• Broker：消息中间件处理结点，一个Kafka节点就是一个broker。
• Topic：主题，一个主题一般会有多个消息的订阅者
• Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列，用于记录每个消费者消费的消息队列。
• Segment：partition物理上由多个segment组成，存储消息，每个segment大小相同
• Producer：负责发布消息到Kafka broker。
• Consumer：消息消费者，向Kafka broker读取消息的客户端。
• Consumer Group：每个Consumer属于一个特定的Consumer Group。

注意点：每一个broker里面只能有一个worker获取到Message

2.Kafka数据传输的事务特点

at most once：最多一次，这个和JMS中"非持久化"消息类似，发送一次，无论成败，将不会重发。

at least once：消息至少发送一次，如果producer超时或收到错误，并且request.required.acks配置的不是-1，则会重试发送消息，客户端会认为该消息未写入Kafka。如果broker在发送Ack之前失败，但在消息成功写入Kafka之后，这一次重试将会导致我们的消息会被写入两次，所以消息就不止一次地传递给最终consumer，如果consumer处理逻辑没有保证幂等的话就会得到不正确的结果。,我们需要设置Prouducer的参数max.in.flight.requests.per.connection，flight.requests是Producer端用来保存发送请求且没有响应的队列，保证Producer端未响应的请求个数为1

exactly once：消息只会发送一次。

3.kafka消息存储格式

  Kafka文件存储中，同一个topic下有多个不同partition，每个partion(相当于一个巨型文件)被分配成多个大小相等segment（段）。但每个段segment file消息数量不一定相等。

• 每个partition为一个目录，partiton命名规则为topic名称+有序序号(由0开始)
• 每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。
• 每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。(能快速删除无用文件，有效提高磁盘利用率)

  segment file组成：由2大部分组成，分别为index file和data file,(segment索引文件、数据文件.) 一一对应，成对出现.

segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。

message

4.副本（replication）策略

Kafka的高可靠性的保障来源于其健壮的副本（replication）策略。

1) 数据同步

kafka在0.8版本前没有提供Partition的Replication机制，一旦Broker宕机，其上的所有Partition就都无法提供服务，而Partition又没有备份数据，数据的可用性就大大降低了。所以0.8后提供了Replication机制来保证Broker的failover。

引入Replication之后，同一个Partition可能会有多个Replica，而这时需要在这些Replication之间选出一个Leader，Producer和Consumer只与这个Leader交互，其它Replica作为Follower从Leader中复制数据。

2) 副本放置策略

  为了更好的做负载均衡，Kafka尽量将所有的Partition均匀分配到整个集群上。Kafka分配Replica的算法如下：

1. 将所有存活的N个Brokers和待分配的Partition排序
2. 将第i个Partition分配到第(i mod
   n)个Broker上，这个Partition的第一个Replica存在于这个分配的Broker上，并且会作为partition的优先副本
3. 将第i个Partition的第j个Replica分配到第((i + j) mod n)个Broker上

3) 同步策略
  对于Kafka而言，定义一个Broker是否“活着”包含两个条件：

• 一是它必须维护与ZooKeeper的session（这个通过ZooKeeper的Heartbeat机制来实现）。
• 二是Follower必须能够及时将Leader的消息复制过来，不能“落后太多”

  同步流程：

1. Producer在发布消息到某个Partition时，先通过ZooKeeper找到该Partition的Leader，
2. 无论Topic的Replication Factor为多少，Producer只将该消息发送到该Partition的Leader。Leader会将该消息写入其本地Log。每个Follower都从Leader pull数据。
3. Follower存储的数据顺序与Leader保持一致。Follower在收到该消息并写入其Log后，向Leader发送ACK。
4. 一旦Leader收到了ISR中的所有Replica的ACK，该消息就被认为已经commit了，Leader将增加HW并且向Producer发送ACK。

  注意事项：为了提高性能，每个Follower在接收到数据后就立马向Leader发送ACK，而非等到数据写入Log中。因此，对于已经commit的消息，Kafka只能保证它被存于多个Replica的内存中，而不能保证它们被持久化到磁盘中，也就不能完全保证异常发生后该条消息一定能被Consumer消费。Consumer读消息也是从Leader读取，只有被commit过的消息才会暴露给Consumer。

4) leader选举

  Leader选举本质上是一个分布式锁，有两种方式实现基于ZooKeeper的分布式锁：

• 节点名称唯一性：多个客户端创建一个节点，只有成功创建节点的客户端才能获得锁
• 临时顺序节点：所有客户端在某个目录下创建自己的临时顺序节点，只有序号最小的才获得锁

kafka消费模型

 推送模型(psuh)和拉取模型(pull)

  push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成Consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据Consumer的消费能力以适当的速率消费消息。
  pull模式可简化broker的设计，Consumer可自主控制消费消息的速率，同时Consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义