“这是我参与更文挑战的第22天,活动详情查看: 更文挑战”
本篇是Kafka的第一篇,主要先认识下什么是kafka,它能干什么?主要用于哪些场景?
kafka是什么
官方地址:kafka.apache.org/
- Kafka 是 linkedin 使用 Scala 编写具有高水平扩展和高吞吐量的分布式消息系统。
- Kafka 对消息保存时根据 Topic 进行归类,发送消息者成为 Producer ,消息接受者成为 Consumer ,此外 kafka 集群有多个 kafka 实例组成,每个实例(server)称为 broker。
- 无论是 Kafka集群,还是 producer 和 consumer 都依赖于 zookeeper 来保证系统可用性,为集群保存一些 meta 信息。
Kafka是最初由Linkedin公司开发,是一个分布式、支持分区的(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、Storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
新版的Kafka已不依赖于zookeeper,有自己一套实现机制。一般公司都不用最新版本,都处于观望阶段,谁敢第一个吃?,不好说!
kafka能做什么
kafka主要功能是什么?
Apache Kafka® 是 一个分布式流处理平台。
流处理平台特性:
- 可以让你发布和订阅流式的记录。这一方面与消息队列或者企业消息系统类似。
- 可以储存流式的记录,并且有较好的容错性。
- 可以在流式记录产生时就进行处理。
Kafka适合什么样的场景
- 构造实时流数据管道,它可以在系统或应用之间可靠地获取数据。 (相当于消息队列)
- 构建实时流式应用程序,对这些流数据进行转换或者影响。
Kafka的使用场景
- 日志收集:一个公司可以用Kafka收集各种服务的log,通过kafka以统一接口服务的方式开放给各种consumer,例如hadoop、Hbase、Solr等。
- 消息系统:解耦和生产者和消费者、缓存消息等。
- 用户活动跟踪:Kafka经常被用来记录web用户或者app用户的各种活动,如浏览网页、搜索、点击等活动,这些活动信息被各个服务器发布到kafka的topic中,然后订阅者通过订阅这些topic来做实时的监控分析,或者装载到hadoop、数据仓库中做离线分析和挖掘。
- 运营指标:Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据,生产各种操作的集中反馈,比如报警和报告。
kafka重要概念
- Broker
- 消息中间件处理节点,一个Kafka节点就是一个broker,一个或者多个Broker可以组成一个Kafka集群
- Topic
- Kafka根据topic对消息进行归类,发布到Kafka集群的每条消息都需要指定一个topic
- Producer
- 消息生产者,向Broker发送消息的客户端
- Consumer
- 消息消费者,从Broker读取消息的客户端
- ConsumerGroup
- 每个Consumer属于一个特定的Consumer Group,一条消息可以被多个不同的Consumer Group消费,但是一个Consumer Group中只能有一个Consumer能够消费该消息
- Partition
- 物理上的概念,一个topic可以分为多个partition,每个partition内部消息是有序的
kafka作为一个集群运行在一个或多个服务器上,Kafka 通过 topic 对存储的流数据进行分类
,每条记录中包含一个 key ,一个 value 和一个 timestamp(时间戳)
producer通过网络发送消息到Kafka集群,然后consumer来进行消费,如下图:
服务端(brokers)和客户端(producer、consumer)之间通信通过TCP协议来完成。
主题Topic和消息日志Log
可以理解Topic是一个类别的名称,同类消息发送到同一个Topic下面。对于每一个Topic,下面可以有多个分区(Partition)日志文件。Kafka 中的 Topics 总是多订阅者模式,一个 topic 可以拥有一个或者多个消费者来订阅它的数据。
Partition是一个有序的message序列
,这些message按顺序添加到一个叫做commit log
的文件中。每个partition中的消息都有一个唯一的编号,称之为offset
,用来唯一标示某个分区中的message。 每个partition,都对应一个commit log文件
。一个partition中的message的offset都是唯一的
,但是不同的partition中的message的offset可能是相同的。
为什么要对Topic下数据进行分区存储?
- commit log文件会受到所在机器的文件系统大小的限制,分区之后,理论上一个topic可以处理任意数量的数据。
- 为了提高并行度。
每个consumer是基于自己在commit log中的消费进度(offset)来进行工作的。在kafka中,消费offset由consumer自己来维护
;一般情况下我们按照顺序逐条消费commit log中的消息,当然我可以通过指定offset来重复消费某些消息,或者跳过某些消息。这意味kafka中的consumer对集群的影响是非常小的,添加一个或者减少一个consumer,对于集群或者其他consumer来说,都是没有影响的,因为每个consumer维护各自的offset。所以说kafka集群是无状态的
,性能不会因为consumer数量受太多影响。kafka还将很多关键信息记录在zookeeper里,保证自己的无状态,从而在水平扩容时非常方便
。
分布式Distribution
Log 的分区被分布到集群中的多个服务器上,每个服务器处理它分到的分区, 根据配置每个分区还可以复制到其它服务器作为备份容错。
每个分区有一个 leader
,零或多个 follower
。Leader 处理此分区的所有的读写请求
,而 follower 被动的复制数据
。如果 leader 宕机,其它的一个 follower 会被推举为新的 leader。 一台服务器可能同时是一个分区的 leader,另一个分区的 follower。 这样可以平衡负载,避免所有的请求都只让一台或者某几台服务器处理。
生产者Producers
生产者将消息发送到topic中去,同时负责选择将message发送到topic的哪一个partition中。通过round-robin做简单的负载均衡。也可以根据消息中的某一个关键字来进行区分。通常第二种方式使用的更多。
消费者Consumers
传统的消息传递模式有2种:队列( queue) 和(publish-subscribe)
- queue模式:多个consumer从服务器中读取数据,消息只会到达一个consumer。
- publish-subscribe模式:消息会被广播给所有的consumer。
Kafka基于这2种模式提供了一种consumer的抽象概念:consumer group
。
- queue模式:所有的consumer都位于同一个consumer group 下。
- publish-subscribe模式:所有的consumer都有着自己唯一的consumer group。
上图说明:由2个broker组成的kafka集群,总共有4个partition(P0-P3)。这个集群由2个Consumer Group, A有2个consumer instances ,B有四个。通常一个topic会有几个consumer group,每个consumer group都是一个逻辑上的订阅者( logical subscriber )。每个consumer group由多个consumer instance组成,从而达到可扩展和容灾的功能。
消费顺序
Kafka比传统的消息系统有着更强的顺序保证。
一个partition
同一个时刻在一个consumer group中只有一个consumer instance
在消费,从而保证顺序。consumer group
中的consumer instance
的数量不能比一个Topic
中的partition
的数量多,否则,多出来的consumer
消费不到消息。
Kafka只在partition的范围内保证消息消费的局部顺序性,不能在同一个topic中的多个partition中保证总的消费顺序性。
如果有在总体上保证消费顺序的需求,那么我们可以通过将topic的partition数量设置为1,将consumer group中的consumer instance数量也设置为1。
总结
本篇介绍了kafka的一些基本核心概念,只有初步了解了这些概念,才能进一步的往下走。
欢迎大家关注公众号(MarkZoe)互相学习、互相交流。