Kafka 总结

Kafka是一种高吞吐量的分布式、发布订阅消息系统。它可以处理消费者规模网站的所有的动作流数据。
Kafka是基于zookeeper协调的分布式消息系统，它最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于Hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/Nginx日志、访问日志、消息服务等等。
1. Kafka特性
- 高吞吐量、低延迟：Kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分为多个partition，consumer group 对partition进行consumer操作。
- 可扩展性：Kafka集群支持热扩展
- 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
- 容错性：允许集群中节点失败(若副本数量为n，则允许n-1 个节点失败 )
- 高并发：支持数千个客户端同时读写

1. Kafka 设计思想：
   Kafka主要有四部分组成：
   生产者： 发布消息到1个或多个topic中。Producer直接发送消息到broker上的leader Partition，不需要经过任何中介或其他路由转发。为了实现这个特性，Kafka集群中的每个broker都可以响应到producer的请求，并返回topic的一些元信息，这些元信息包括哪些机器是存活的，topic的leader Partition 都在哪，现阶段哪些；leader Partition是可以直接被访问的。

   **消费者：**  订阅一个或多个topic 。在Kafka中，当前读到哪条消息的offset值是由consumer来维护的，因此，consumer可以自己觉得如何读到kafka中的数据。比如，consumer可以通过重设offset值来重新消费已消费过的数据。不管有没有被消费，kafka会保存数据一段时间，这个时间周期是可配置的，只有到了过期时间，kafka才会删除这些数据。
   
   
   **topic:**消息以topic为类别记录，Kafka将消息种子(Feed)分门别类，每一类消息称之为一个主题(Topic)。
   
   **borker(服务代理)：**以集群方式运行，可以由一个或多个服务组成，每个服务叫做一个broker；消费者可以订阅一个或者多个主题，并从Broker拉数据，从而消费这些已发布的消息。 Broker是无状态的，意味着消费者必须维护已消费的状态信息，这些信息由消费者自己维护，broker完全不管(有offset managerBroler管理)
   

   每个消息(也叫做record记录，也被成为称为消息)是由key、一个value和时间戳构成。

2. Kafka 有四个核心API介绍：

   • 应用程序使用producer API发布消息到1个或多个topic中
   • 应用程序使用consumer API来订阅一个或多个topic，并处理产生的消息
   • 应用程序使用stream API 充当一个流数据处理器，从1个或多个topic消费输入流，并产生一个输出流到1个或多个topic，有效的输入流转换到输出流。
   • connector API 允许构建或运行可重复使用的生产者或消费者，将topic链接到现有的应用程序或数据系统。

3. 一般来说，（1）一个Topic的Partition数量大于等于Broker的数量，可以提高吞吐率。（2）同一个Partition的Replica尽量分散到不同的机器，高可用。

4. 当add a new partition的时候，partition里面的message不会重新进行分配，原来的partition里面的message数据不会变，新加的这个partition刚开始是空的，随后进入这个topic的message就会重新参与所有partition的load balance
5. Partition Replica：每个partition可以在其他的kafka broker节点上存副本，以便某个kafka broker节点宕机不会影响这个kafka集群。存replica副本的方式是按照kafka broker的顺序存。例如有5个kafka broker节点，某个topic有3个partition，每个partition存2个副本，那么partition1存broker1,broker2，partition2存broker2,broker3。。。以此类推（replica副本数目不能大于kafka broker节点的数目，否则报错。这里的replica数其实就是partition的副本总数，其中包括一个leader，其他的就是copy副本）。这样如果某个broker宕机，其实整个kafka内数据依然是完整的。但是，replica副本数越高，系统虽然越稳定，但是回来带资源和性能上的下降；replica副本少的话，也会造成系统丢数据的风险。

6. partition 中文件存储方式

   • 每个partition(目录)相当于一个巨型文件被平均分配到多个大小相等的segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。
   • 每个partition只需要支持顺序读写就行了，segment 文件什么周期由服务端配置参数决定。
     这样做的好处就是能快速删除无用文件，有效提高磁盘利用率。

7. 副本分配逻辑规则如下：

   • 在Kafka集群中，每个broker都有均等分配partition的Leander机会。
   • 在Broker Partition中，箭头指向为副本

9.副本分配算法如下：
- 将所有N Broker 和 待分配 的I个Partition 排序
- 将第I个Partition 分配到第(i mod n) 个Broker上。
- 将第I个Partition 的第j个副本分配到第 (i + j )个Broker上。

1. Kafka Broker 一些特性
   无状态的Kafka Broker
   
   • Broker没有副本，一旦Broker宕机，该broker的消息都将不可用
   • Broker不保存订阅者的状态，由订阅者自己保存
   • 无状态导致消息的删除称为难题(可能删除的消息正在被订阅)，Kafka采用基于时间的SLA(服务水平保证)，消息保存一定时间(通常为7天)后会被删除
   • 消息订阅者可以rewind back到任意位置重新进行消费，当订阅者故障时，可以选择最小的offset进行重新读取消费消息。

2. 因每个partition只会被consumer group内的一个consumer消费，故kafka保证每个partition内的消息会被顺序的订阅。

3. 从Producer端看：Kafka是这么处理的，当一个消息被发送后，Producer会等待broker成功接收到消息的反馈（可通过参数控制等待时间），如果消息在途中丢失或是其中一个broker挂掉，Producer会重新发送（我们知道Kafka有备份机制，可以通过参数控制是否等待所有备份节点都收到消息）。

4. 从Consumer端看：前面讲到过partition，broker端记录了partition中的一个offset值，这个值指向Consumer下一个即将消费message。当Consumer收到了消息，但却在处理过程中挂掉，此时Consumer可以通过这个offset值重新找到上一个消息再进行处理。Consumer还有权限控制这个offset值，对持久化到broker端的消息做任意处理。

5. Consumer 与 Partition 的关系：

   • 如果 consumer 比 Partition 多，是浪费，因为kafka的设计是在一个Partition上 是不允许并发的，所以consumer 数不要大于Partition数。
   • 如果consumer 数比Partition 少，一个consumer 会对应于多个Partitions，这里主要合理分配consumer数和Partition数，否则会导致Partition里面的数据被取得不均匀。
   • 如果consumer从多个Partition读到数据，不保证数据间的顺序性，kafka只保证在一个Partition 上数据是有序的，但多个Partition，根据你读的顺会有不同。
   • 增减consumer，broker，Partition会导致rebalance，所以rebalance后consumer对应的Partition会发生变化

6. Kafka 与 Zookeeper
   3.1 Zookeeper 协调控制
   1. 管理broker 与consumer 的动态加入与离开。(Producer 不需要管理，随便一台计算机都可以作为 Producer 向 Kafka Broker 发消息 )
   2. 触发负载均衡，当Broker 或 consumer 加入或离开时会触发负载均衡算法，使得一个consumer group内的多个consumer 的消费 负载平衡。(因为一个 consumer 消费一个或多个 Partition ，一个Partition 只能被一个 consumer 消费 )
   3. 维护消费关系以及每个Partition 的消费信息
   3.2 Zookeeper上的细节：
   1. 每个Broker 启动后会在Zookeeper 是上注册一个临时的broker registy，包含broker 的 ip地址和端口号，所存储的topics和Partitions信息
   2. 每个consumer 启动后会在Zookeeper 上注册一个临时的 consumer registy：包含 consumer 所属的consumer group 以及订阅的 topics
   3. 每个consumer group 关联一个临时的owner registy 和 一个持久的offset registy。对于被订阅的每个Partition 包含一个owner group registy，内容为订阅这个partition的consumer id；同时包含一个offset registry，内容为上一次订阅的offset。