Kafka学习笔记——Kafka简介与使用场景介绍

Introduction

Kafka 是 linkedin 用于日志处理的分布式消息队列，同时支持离线和在线日志处理。kafka 对消息保存时根据 Topic 进行归类，发送消息者成为 Producer,消息接受者成为 Consumer,此外 kafka 集群有多个 kafka 实例组成，每个实例(server)称为 broker。无论是 kafka集群，还是 producer 和 consumer 都依赖于 zookeeper 来保证系统可用性，为集群保存一些 meta 信息。

Topics/logs

一个 Topic 可以认为是一类消息，每个 topic 将被分成多个partition(区),每个 partition 在存储层面是 append log 文件。任何发布到此 partition 的消息都会被直接追加到 log 文件的尾部，每条消息在文件中的位置称为 offset（偏移量），offset 为一个 long型数字，它是唯一标记一条消息。kafka 并没有提供其他额外的索引机制来存储 offset，因为在 kafka 中几乎不允许对消息进行“随机读写”。
对于每一个topic，kafka集群都包含一个分区日志，如下图所示

在 kafka 中，即使消息被消费,消息仍然不会被立即删除。日志文件将会根据 broker 中的配置要求,保留一定的时间之后删除;比如log 文件保留 2 天,那么两天后,文件会被清除,无论其中的消息是否被消费。kafka 通过这种简单的手段,来释放磁盘空间,以及减少消息消费之后对文件内容改动的磁盘 IO 开支。
对于consumer而言,它需要保存消费消息的offset,对于offset的保存和使用,由 consumer 来控制;当 consumer 正常消费消息时,offset 将会”线性”的向前驱动,即消息将依次顺序被消费。事实上 consumer 可以使用任意顺序消费消息,它只需要将 offset 重置为任意值。

kafka集群几乎不需要维护任何consumer和producer状态信息,这些信息由 zookeeper 保存;因此 producer 和 consumer 的客户端实现非常轻量级,它们可以随意离开,而不会对集群造成额外的影响。partitions 的设计目的有多个。最根本原因是 kafka 基于文件存储。通过分区,可以将日志内容分散到多个 server 上,来避免文件尺寸达到单机磁盘的上限,每个 partiton 都会被当前 server(kafka实例)保存;可以将一个 topic 切分多任意多个 partitions 来保存消息。此外越多的 partitions 意味着可以容纳更多的 consumer,有效提升并发消费的能力。

Distribution

一个Topic的多个partitions,被分布在kafka集群中的多个server上;每个server(kafka实例)负责partitions中消息的读写操作;此外kafka还可以配置partitions需要备份的个数(replicas),每个partition将会被备份到多台机器上,以提高可用性。基于replicated方案,那么就意味着需要对多个备份进行调度;每个partition都有一个server为”leader”;leader负责所有的读写操作,如果leader失效,那么将会有其他follower来接管(成为新的leader);follower只是单调的和leader跟进,同步消息即可。 由此可见作为leader的server承载了全部的请求压力,因此从集群的整体考虑,有多少个partitions就意味着有多少个”leader”,kafka会将”leader”均衡的分散在每个实例上,来确保整体的性能稳定 。
1、发送到partitions中的消息将会按照它接收的顺序追加到日志中。
2、对于消费者而言,它们消费消息的顺序和日志中消息顺序一致。
3、如果Topic的”replication factor”为N,那么允许N-1个kafka实例失效

producers

producer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition;比如基于”round-robin”方式或者通过其他的一些算法等

consumers

本质上kafka只支持Topic。 每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer。 发送到Topic的消息,只会被订阅此Topic的每个group中的一个consumer消费。
如果所有的consumer都具有相同的group,这种情况和queue模式很像;消息将会在consumers之间负载均衡。如果所有的consumer都具有不同的group,那这就是”发布-订阅”， 消息将会广播给所有的消费者。

在kafka中,一个partition中的消息只会被group中的一个consumer消费;每个group中consumer消息消费互相独立;我们可以认为一个 group 是一个”订阅”者,一个 Topic 中的每个 partions,只会被一个”订阅者”中的一个 consumer 消费,不过一个 consumer 可以消费多个 partitions 中的消息。 kafka 只能保证一个 partition 中
的消息被某个 consumer消费时,消息是顺序的。 事实上,从Topic 角度来说,消息仍不是有序的。kafka 的设计原理决定,对于一个 topic,同一个 group 中不能有
多于 partitions 个数的 consumer 同时消费,否则将意味着某些consumer将无法得到消息

use cases

Message

对于一些常规的消息系统 ,kafka 是个不错的选择;partitons/replication和容错,可以使kafka具有良好的扩展性和性能优势。 不过 kafka 并没有提供 JMS中的”事务性”、 “消息确认机制”、 “消息分组”等企业级特性， kafka 只能作为”常规”的消息系统,在一定程度上,尚未确保消息的发送与接收绝对可靠(比如,消息
重发,消息发送丢失等)。

Websit activity tracking

kafka 可以作为”网站活性跟踪”的最佳工具;可以将网页/用户操作等信息发送到kafka 中。 并实时监控,或者离线统计分析等。

LogAggregation

kafka 的特性决定它非常适合作为”日志收集中心”;application可以将操作日志”批量”、 “异步”的发送到 kafka 集群中,而不是保存在本地或者 DB 中;kafka 可以批量提交消息/压缩消息等,这对producer 端而言,几乎感觉不到性能的开支。 此时 consumer 端可以使 hadoop 等其他系统化的存储和分析系统。
这里主要参考官网介绍了下kafka的理论知识，下一节我们开始进入到kakfa的实际使用。
参考资料：http://kafka.apache.org