KAFKA官方教程笔记-introduction

介绍

 apache kafka是一个分布式流式处理平台，一个流式平台该有的三个关键能力：

1. 发布、订阅流式数据。从这个角度讲相似消息队列或者企业消息系统；
2. 容错的数据存储机制；
3. 实时处理数据。

kafka的优势:

1. 在系统、应用之间建立可靠的实时流式数据管道；
2. 建立实时流式数据处理应用。

为了解kafka如何实现以上几点，咱们深刻探讨kafka能力。

首先是了解一些概念:

• kafka做为集群运行在一台或者多台服务器上
• kafka按分类存储数据（被称为topic）
• 每条数据由key，value，时间戳组成.

一些术语

Broker
　　Kafka集群包含一个或多个服务器，这种服务器被称为broker

• Topic
  　　每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不一样Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic便可生产或消费数据而没必要关心数据存于何处）Topic在逻辑上能够被认为是一个queue，每条消费都必须指定它的Topic，能够简单理解为必须指明把这条消息放进哪一个queue里。为了使得Kafka的吞吐率能够线性提升，物理上把Topic分红一个或多个Partition，每一个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的全部消息和索引文件。
• Partition
  　　Parition是物理上的概念，每一个Topic包含一个或多个Partition.每一个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的全部消息和索引文件。对于一个topic，3个分区，则同一组消费者数量应当<=3，不然有消费者接受不到数据；
• Producer
  　　负责发布消息到Kafka broker
• Consumer
  　　消息消费者，向Kafka broker读取消息的客户端。
• Consumer Group
  　　每一个Consumer属于一个特定的Consumer Group（可为每一个Consumer指定group name，若不指定group name则属于默认的group）。

kafka的四个核心api

• 生产者api
• 消费者api
• 流式处理api
• 链接api，将topic链接到现有的应用程序或数据系统。

 在kafka中连通服务器和客户端使用的是简单、高效、语言无关的tcp协议。目前的协议和旧版本协议兼容，咱们提供java等多语言客户端。

Topics和Logs

 topic就是消息分类，一个topic能够有0-n个消息订阅者。

如图，每一个分区是有序的数据接二连三的追加到日志文件结构末尾。分区中的记录被赋予一个分区内惟一的值，这个值被称做offset。

在kafka集群中保留全部发布的数据-不管是否被消费过-经过配置设置保留时间。好比，保留策略设置为两天，那么等记录分布两天内，这条数据是可消费的，以后数据将被删除以用来释放空间。kafka读写性能稳定和数据大小无关（这个是kafka牛逼的地方）。

实际上，消费者保留的惟一元数据就是offset，一般offset由0线性增加，可是实际上由于这个值是消费者可控的，因此能够从0开始，也能够从最新一条数据的offset开始。

分布式

数据的分区被集群分布在kafka的多个服务器上，每一个服务器处理它分到的分区，并向共同的分区请求数据。分区数经过配置文件设置，每一个分区复制数据。（这就是所谓的容错机制，和hadoop优势像）

每一个分区中有个服务器做为leader,其他0-n个服务器做为followers。leader处理全部的读写请求，其他的follow被动的复制leader的数据。若是leader服务器挂了，followers 中的一台服务器会被选举成新leader。一台服务器可能同时是一个分区的leader，另外一个分区的follower。这样作到负载均衡，避免全部的请求都只让一台或少数几台服务器处理。

若是leader不挂，followers没有存在的意义。但lead挂了时，咱们须要从followers节点中选出一个主。

note：一个topic能够有多个复制版本（replication-factor 指定具体broker数目），一个broker多个分区（partitions  数目），broker之间数据应该是相同的，而同一个broker每一个分区数据应该是不同的

broker-0

broker-1

brokerid=2

------------------------------------------------------------------------------------

 

生产者

生产者向本身指定的topic写数据，生产者的主要职责是选择发布到topic的哪一个分区。最简单的方式从分区列表中轮流选择。也能够根据某种算法依照权重选择分区。开发者负责如何选择分区的算法。
消费者

消费者以组名被标记，若是全部消费者共有一个消费者组名，那么记录将在消费者中高效平衡的均匀发布。若是全部消费者都使用不一样的组名，那就是一个消息广播。

2个kafka集群托管4个分区（P0-P3），2个消费者组，消费组A有2个消费者实例，消费组B有4个。

正像传统的消息系统同样，Kafka保证消息的顺序不变。 再详细扯几句。传统的队列模型保持消息，而且保证它们的前后顺序不变。可是， 尽管服务器保证了消息的顺序，消息仍是异步的发送给各个消费者，消费者收到消息的前后顺序不能保证了。这也意味着并行消费将不能保证消息的前后顺序。用过传统的消息系统的同窗确定清楚，消息的顺序处理很让人头痛。若是只让一个消费者处理消息，又违背了并行处理的初衷。 在这一点上Kafka作的更好，尽管并无彻底解决上述问题。 Kafka采用了一种分而治之的策略：分区。 由于Topic分区中消息只能由消费者组中的惟一一个消费者处理，因此消息确定是按照前后顺序进行处理的。可是它也仅仅是保证Topic的一个分区顺序处理，不能保证跨分区的消息前后处理顺序。 因此，若是你想要顺序的处理Topic的全部消息，那就只提供一个分区。

保证

消息的发送顺序就是消息的保存顺序，也就是消费者接收消息的顺序。一个topic的 replication factor若是设置为n，那么即便n-1台服务器挂了，数据也不会丢失。

• 以时间复杂度为O(1)的方式提供消息持久化能力，即便对TB级以上数据也能保证常数时间的访问性能.一个持久化的队列能够构建在对一个文件的读和追加上，就像通常状况下的日志解决方案。尽管和B树相比，这种结构不能支持丰富的语义，可是它有一个优势，全部的操做都是常数时间，而且读写之间不会相互阻塞。这种设计具备极大的性能优点：最终系统性能和数据大小彻底无关，服务器能够充分利用廉价的硬盘来提供高效的消息服务。 
• 高吞吐率。即便在很是廉价的商用机器上也能作到单机支持每秒100K条消息的传输
• 支持Kafka Server间的消息分区，及分布式消费，同时保证每一个partition内的消息顺序传输
• 同时支持离线数据处理和实时数据处理

kefka能够做为消息系统，存储系统，流式处理系统。也能够把它们整合起来。