kafka介绍_卡夫卡数据库什么意思

Kafka被用于两类应用场景：

1.  在系统和应用之间构建可靠的实时数据流管道，获取数据

2.  构建用于转换或者处理数据流的实施数据流应用

kafka的几个概念：

1. kafka作为一个集群运行在一个或者多个服务器

2. kafka集群基于topic的分类存储数据流

3. 每个数据记录都由键、值、时间戳构成

kafka包含四个核心的api：

1. Producer API允许应用发布数据流记录到一个或者多个kafa topics;

2. Consumer API允许应用订阅一个或者多个tpics并且处理接收到的数据流记录

3. Steam API应用作为一个数据流处理器，消费从一个或者多个topics产生的数据流，并且生成输出数据流

4. Connector API创建、运行可重用的生产者或者消费者，通过topics连接到存在的应用或者系统。例如，一个连接到可以捕获所有表变动的关系数据库连接。

Topics and Logs

topic 是作为应用发布消息的分类。一个topic通常由一个或者多个订阅者。对于每个topic，kafka集群维护着一个分段日志，格式如下：

每个分段都是有序的，记录不断追加的不可变序列，即一个机构化的提交日志。分段中的每个记录都被分配一个唯一的有序数字id，成为offset用于唯一定位分区中的一条记录。

kafka集群保留所有有效期内的发布记录，不管是否被消费。有效期通过配置保留期限。例如，如果保留策略设置为两天，在两天之内的发布记录都可用，当超过两天将会作废，并且释放空间。kafka的性能不受数据大小影响，因此保留长的时间不会存在性能问题。

实际上，对于每个消费者唯一保留的元数据是当前消费者在日志中记录的当前处理到的offset或者位置。offset是由消费者记录的。消费者可以以任何顺序消费消息记录。例如一个消费者可以重置重新处理之前的数据或者忽略掉前面所有数据，直接从当前位置处理。

由于这些特性，使得kafka的消费者非常灵活，增加或者移除对于集群或者别的消费者，没有影响

分布

日志分段分布在每个处理数据并且请求分段共享的kafka服务集群服务器中。每个分段可以复制到多个配置的服务器中，用于容灾。每个分段包含一个leader的服务器，其余的零个或者多个服务器作为“follower”，leader处理所有分段的读写请求，follower只是被动的从leader复制。如果leader失败，其中的一个follower会转变成leader。别个服务器都在其中的部分分段中扮演leader的角色，用于更好的在集群中作负载均衡。

生产者

生产者用于有选择的发布数据大对应的topics。生产者负责决定哪个记录要发布到topic中的哪个分段中。

消费者

消费者为自己打上消费者分组标签名称，每个记录被发布到topic，都会传递到订阅消费者分组的其中一个消费者实例。消费者实例可以位于不同的进程或者不同的机器。

如果所有的消费者实例由相同的消费者分组，将会通过记录有效的进行消费者实例的负载均衡。

如果所有的消费者实例在不同的消费者分组，那么每个记录都会被广播到所有的消费者进程。

Guarantees

kafka给出了高层次的保障：

1. 生产者发送到指定topic分段的消息将会按照发送顺序在分段中追加。如果m1,m2是由同一个生产者发送，m1先发送，那么m1在分段中的offset值将小于m2的offset 值，并且在日志中出现也会早于m2;

2.  每个消费者实例可见的记录和它们在日志中存储的完全一致。

3.  每个复制因子为N的topic，都有n-1个不丢失日志记录的服务器失败的容错

Kafka as a Messaging System

在传统的消息机制模型：队列和订阅者。在一个队列中，一个消费者池可能从一个服务器读取数据，并且消息只到达其中一个消费者；在订阅者模式中，消息发不给所有的消费者。这两种模式各有利弊。

消息队列模式的优点在于将数据处理分配至多个消费者实例，从而处理。但是队列模式并不支持多订阅者模式，其中一个进程读取到数bu据之后，数据就从队列中移除。

订阅者模式将消息发不给多个进程，但是没有办法规模化的处理，因为每个消息到达不同的订阅者。

kafka中消费者组的概念泛化了这两个概念。通过一个 consumer group队列将处理查分到一个进程（成员时消费者组）集合中。当有发布订阅，将会广播消息到多个消费者分组。

kafka模型的优势在于对于每个topic都有两个属性：能够模式化处理，并且是多订阅者，不需要在两个中间作这种。

kafka比传统的消息系统有更强的顺序保证。

传统的消息队列在服务器上是顺序的保留消息记录，并且如果多个消费者消费这个队列时，服务器按照保存的顺序传出消息记录。但是，尽管服务器传出数据是有序的，消息发送到消费者是异步的，所以她们到达到消费者端仍然可能是无序的。消息系统通常使用专属消费者来规避这个问题，只允许一个消费者处理一个队列，但是这意味着不能够并行处理。

在kafka中，通过分段来实现兵法的概念：在topic中，kafka能够保证有序并且在消费者处理池中保持负载均衡。实现原理：通过给topic消费者分组中的每个消费者分配一个对应的partition,通过这样处理，保证消费者读取对应partition并且有序的处理消息。因为有多个partition，所以需要平衡消费者实例。需要注意的是消费者的个数不能多余消费者分组中的partition个数

Kafka作为一个存储系统

对于动态消息来说，任何一个允许发布消息和消费消息有效解耦的消息队列都是一个存储系统，不同之处在于kafka是一个优秀的存储系统。

写入kafka的数据是被写入硬盘的，并且进行容错复制。kafka允许生产者等待数据写入、复制保证数据正确处理的确认消息。保证数据写入服务器完全成功。

kafka很好的处理磁盘结构，不管服务端数据是50kb或者是50TB,kafka处理效率相同。

由于对存储的认真处理，并且允许客户端控制读取的位置，可以将kafka看作一个致力于高效能、低延时，提交日志，可复制，以及可推广的文件系统。

kfka用于流处理

只是用于读、写一集存储数据流是不够的，主要目的是能够实时的处理数据流。

在kafka 系统中，流处理器是持续的从topic接受数据流，对输入进行处理，并且持续的生成数据流到结果topic。

例如，一个零售应用系统，销售和运输作为数据输入流，基于对这些数据的处理，计算出重订购一集价格调整的结果。

对于简单的处理可以直接调用生产者消费者的api 进行处理。但是对于更复杂的处理，kafka提供了全集成的Stream API。这样就可以不用烦琐的处理就可以计算聚合数据流和这合并数据流。

这些能力帮助解决了应用面对的如下问题：处理无序数据，当代码变更时冲处理输入数据，执行有状态计算等问题。

streams api 基于kafka核心基础模型构建：把生产者和消费者的api作为输入，使用 Kafka的有状态存储，并且在流处理实例负载均衡使用相同的分组机制。

putting the pieces together

把消息，存储和流处理合并到一起或许看起来不一般，但是对于kafka作为一个流平台至关重要。

分布式文件系统，如hdfs存储静态文件用于批处理。实际上，这样的文件系统能够存储和处理过往的历史数据。

传统的企业消息系统，能够处理订阅的未来到来的消息。这样的应用能够处理将来的消息。

kafka结合了这两种能力，两种能力对于kafka用作流应用平台以及数据流管道都只管重要。

通过结合存储，低延时订阅，流应用能够用相同的方式处理过去和未来的数据。这种数据流的处理概念包含批处理以及数据驱动应用。