kafka运行机制

kafka学习入门 什么是kafka - 简书

1.什么是kafka

kafka的目标是实现一个为处理实时数据提供一个统一、高吞吐、低延迟的平台。是分布式发布-订阅消息系统，是一个分布式的，可划分的，冗余备份的持久性的日志服务。

2.基本概念

1.kafka作为集群运行在一个或者多个服务器上
2.kafka集群存储的消息是以topic为类别记录的
3.kafka存储的消息是k-v键值对，k是offset偏移量，v就是消息的内容
4.topic：kafka将消息分门别类，每一类的消息称之为topic
5.broker：已发布的消息保存在一组服务器中，称之为Kafka集群。集群中的每一个服务器都是一个代理(Broker). 消费者可以订阅一个或多个主题（topic），并从Broker拉数据，从而消费这些已发布的消息。
6.消息：kafka会保存消息直到它过期，无论是否被消费了。
7.producer：发布消息的对象，往某个topic中发布消息，也负责选择发布到topic中的哪个分区
8.consumer：订阅消息并处理发布的消息的对象

9.patition：topic是逻辑上的概念，patition是物理概念。

每个分区都是一个顺序的，不可变的消息队列，并且可以持续添加，producer生产的消息都会append到队列的末尾，而不是随机读写的。分区中的消息都会被分了一个序列号，这个序列号在分区内是唯一的，也就是分区内的偏移量。

10.如何消费：
kafka的生产者没有保持消息消费的顺序，消费的顺序是通过偏移量交给消费者的，消费者持有的元数据就是消息的offset，消费者通过控制offset的移动来决定读取哪里的消息。正常情况下，当消费者消费消息的时候，偏移量是线性增长的。如果消费者想要重新读取数据的时候，就需要将偏移量向前移动。可以说，非常灵活了。

11.为什么说是分布式和冗余备份的：
分区被分布到集群中的各个服务器中，每个服务器处理它所拥有的分区。根据配置，每个分区还可以复制到其他服务器作为备份容错。每个分区拥有一个leader，有一个或者多个follower（冗余备份的）。一个broker可以是一个分区的leader,同时也可以是别的分区的follwer，避免了所有的请求只让一个或者几个服务器处理，负载均衡。
某个broker如果是一个分区的leader，那么它处理这个分区上的所有读写请求，而follwer分区被动的复制数据。如果leader宕机，则follwer就可以被推举为leader。

12.为什么说是持久性的：
kafka使用文件存储消息，并且会保存所有消息直到它过期，无论是否消费。

13.consumer和topic的关系

这个kafka集群中有两个broker，broker1下有partition0和partition3，broker2下有partition1和partition2。
有两个消费者集群，消费者集群A拥有两个消费者C1和C2，消费者集群B拥有四个消费者C3,C4,C5,C6。
每个partition只能被一个消费者集群中的一个消费者消费，比如broker1中partition0，只能被Consumer GroupA中的C1消费，只能被Consumer GroupB中的C3消费，kafak会确保这个消费者是这个partition的唯一消费者。
因为偏移量的唯一值是基于一个分区内的，producer生产的消息按照一定的算法分配到不同的分区，在各个分区内部，偏移量是线性增长的，所以在一个分区内消费消息是可以保持顺序的。但是如果topic里有多个partition的话，那么不能保证全局的消息是顺序的。
一个消费组中有多个消费者可以提高消费消息的并发性，并且当partition的消费者出现故障，那么这个partition可以分配给同组的其他消费者，从而提高他的容错性。
因为一个partition只能被一个同组的消费者消费，所以当同组中的消费者数量多于partition的数量时，注定有消费者无法消费partition。
每个消费者可以消费一个到多个partition。

14.发布订阅
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。发布到topic的消息会被所有订阅者消费。消费端为拉模型，消费状态和订阅关系由客户端负责维护，消息消费完后不会立即删除，会保留历史消息。

3.应用场景

1.监控：主机通过Kafka发送与系统和应用程序健康相关的指标，然后这些信息会被收集和处理从而创建监控仪表盘并发送警告。
2.消息队列： 应用程度使用Kafka作为传统的消息系统实现标准的队列和消息的发布—订阅，例如搜索和内容提要（Content Feed）。比起大多数的消息系统来说，Kafka有更好的吞吐量，内置的分区，冗余及容错性，这让Kafka成为了一个很好的大规模消息处理应用的解决方案。消息系统 一般吞吐量相对较低，但是需要更小的端到端延时，并尝尝依赖于Kafka提供的强大的持久性保障。在这个领域，Kafka足以媲美传统消息系统，如ActiveMR或RabbitMQ
3.站点的用户活动追踪: 为了更好地理解用户行为，改善用户体验，将用户查看了哪个页面、点击了哪些内容等信息发送到每个数据中心的Kafka集群上，并通过Hadoop进行分析、生成日常报告。
4.流处理：保存收集流数据，以提供之后对接的Storm或其他流式计算框架进行处理。很多用户会将那些从原始topic来的数据进行阶段性处理，汇总，扩充或者以其他的方式转换到新的topic下再继续后面的处理。例如一个文章推荐的处理流程，可能是先从RSS数据源中抓取文章的内容，然后将其丢入一个叫做“文章”的topic中；后续操作可能是需要对这个内容进行清理，比如回复正常数据或者删除重复数据，最后再将内容匹配的结果返 还给用户。这就在一个独立的topic之外，产生了一系列的实时数据处理的流程。
5.日志聚合。使用Kafka代替日志聚合（log aggregation）。日志聚合一般来说是从服务器上收集日志文件，然后放到一个集中的位置（文件服务器或HDFS）进行处理。然而Kafka忽略掉文件的细节，将其更清晰地抽象成一个个日志或事件的消息流。这就让Kafka处理过程延迟更低，更容易支持多数据源和分布式数据处理。比起以日志为中心的系统比如Scribe或者Flume来说，Kafka提供同样高效的性能和因为复制导致的更高的耐用性保证，以及更低的端到端延迟。
6.持久性日志：Kafka可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据回复提供一种重新同步的机制。Kafka中日志压缩功能为这种用法提供了条件。在这种用法中，Kafka类似于Apache BookKeeper项目。