kafka消息的管理

kafka producer将消息发送给broker后，消息日志会被存储在broker的磁盘上，采用顺序写入的方式。顺序写可以加快磁盘访问速度，并且可以将将多个小型的逻辑写合并成一次大型的物理磁盘写入，官方数据显示顺序写比随机写入快6000倍以上。另外， *** 作系统使用内存对磁盘进行缓存即pagecache，pagecache完全由 *** 作系统管理，这也使得写数据变得即简洁也快速。

配置中可以调整过期时间，超过改时间的消息日志将移除，默认值为7天；也可配置文件大小阈值，达到该阈值后，从最旧消息开始删除。配置项为：

从文件到套接字的常见数据传输路径有4步：

1) *** 作系统从磁盘读取数据到内核空间的 pagecache

2)应用程序读取内核空间的数据到用户空间的缓冲区

3)应用程序将数据(用户空间的缓冲区)写回内核空间到套接字缓冲区(内核空间)

4) *** 作系统将数据从套接字缓冲区(内核空间)复制到通过网络发送的 NIC 缓冲区

kafka使用 producer ，broker 和 consumer 都共享的标准化的二进制消息格式，这样数据块不用修改就能在他们之间传递。kafka采用Linux 中系统调用sendfile的方式，直接将数据从 pagecache 转移到 socket 网络连接中。这种零拷贝方式使得kafka数据传输更加高效。

以前面文章中安装的kafka为例： Mac 安装kafka

kafka本地文件存储目录可以在配置文件serverproperties中设置，参数及默认值为：

进入该目录，可以看到kafka保存的cosumer offset和topic消息：

其中__consumer_offsets开头的为消费的offset信息，test1开头的即为之前创建的topic “test1”，该topic有三个分区，分区编号从0开始，分别是test1-0、test1-1、test1-2。

进入test1-0，查看包含文件如下：

可以看到kafka消息按partition存储的，每个partition一个目录。partition下消息分段(segment)存储，默认每段最大1G，通过参数logsegmentbytes可配置。segment包含索引文件index、消息文件log，分别存储消息的索引和内容，以index和log结尾，文件命名为当前segment第一个消息offset。index文件在log每隔一定数据量之间建立索引，可以通过参数indexintervalbytes配置。

通过kafka命令查看00000000000000000000index内容如下：

00000000000000000000log内容如下：

其中索引文件中包含两个字段：（offset，position），分别表示消息offset和该消息在log文件的偏移量。如上图中offset=0的消息对应的position=0；对应的就是00000000000000000000log中的第一条消息：

其中payload为具体的消息内容。

另外里面还有一个以"timeindex"结尾的文件，查看其内容：

该日志文件是kafka01011加入的，其中保存的为：（消息时间戳，offset）。时间戳是该segment最后一个消息对应的时间戳（与log文件中最后一条记录时间戳一致），kafka也支持根据时间来读取消息。

由上可知消息是按partition来存储的，partition可以配置n个副本followers。多个partition和其follower在broker上是怎么分配的呢？

partition和broker都进行了排序，下标从0开始；

假设有k个broker，第i个partition被分配到到 i%k 个broker上；

第i%k个broker即为partition i 的leader，负责这个partition的读写 ；

partition的followers也进行排序，从leader的后续broker开始分配，第i个partition的第j个副本broker为 （j+ i%k）%k。

一个有3个broker的kafka集群，包含3个partition，每个partition副本数为1的topic如下图：

总结：

kafka将消息日志采用顺序写入的方式存放在broker磁盘中；数据传输通过系统调用sendfile零拷贝方式；消息日志分段存放，可配置清除时间或大小阈值；每段包含消息索引、消息内容两个文件，通过索引实现快速查找；按照/topic/partition的目录结构分开存储，且均匀分布到集群各broker上。

参考：

>

producer 是生产者，负责消息生产，上游程序中按照标准的消息格式组装（按照每个消息事件的字段定义）发送到指定的topic。producer生产消息的时候，不会因为consumer处理能力不够，而阻塞producer的生产。consumer会从指定的topic 拉取消息，然后处理消费，并提交offset（消息处理偏移量，消费掉的消息并不会主动删除，而是kafka系统根据保存周期自动消除）。

topic是消费分类存储的队列，可以按照消息类型来分topic存储。

replication是topic复制副本个数，用于解决数据丢失，防止leader topic宕机后，其他副本可以快代替。

broker是缓存代理，Kafka集群中的一台或多台服务器统称broker，用来保存producer发送的消息。Broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。

partition是topic的物理分组，在创建topic的时候，可以指定partition 数量。每个partition是逻辑有序的，保证每个消息都是顺序插入的，而且每个消息的offset在不同partition的是唯一不同的

偏移量。kafka为每条在分区的消息保存一个偏移量offset，这也是消费者在分区的位置。比如一个偏移量是5的消费者，表示已经消费了从0-4偏移量的消息，下一个要消费的消息的偏移量是5。每次消息处理完后，要么主动提交offset，要么自动提交，把offset偏移到下一位，如处理offset=6消息。在kafka配置中，如果enable_auto_commit=True和auto_commit_interval_ms=xx，那表示每xx 毫秒自动提交偏移量

分组。是指在消费同一topic的不同consumer。每个consumer都有唯一的groupId，同一groupId 属于同一个group。不同groupId的consumer相互不影响。对于一个topic，同一个group的consumer数量不能超过 partition数量。比如，Topic A 有 16个partition，某一个group下有2个consumer，那2个consumer分别消费8个partition，而这个group的consumer数量最多不能超过16个。

kafka的配置主要分四类，分别是zookeeper、server、consumer、producer。其他的配置可以忽略。

zk的配置比较简单，也可以默认不改dataDir是zk存储节点配置的目录地址，clientPort是zk启动的端口，默认2181，maxClientCnxns是限制ip的连接此处，设置0表示无连接次数，一般情况根据业务部署情况，配置合理的值。

Kafka作为一个传统的消息代理的替代品表现得非常出色。使用消息代理有各种各样的原因(将处理与数据生成器解耦，缓冲未处理的消息，等等)。与大多数消息传递系统相比，Kafka有更好的吞吐量、内置分区、复制和容错性，这使得它成为大规模消息处理应用的一个很好的解决方案。

根据我们的经验，消息传递的使用通常是相对较低的吞吐量，但可能需要较低的端到端延迟，并且常常依赖于Kafka提供的强大的持久性保证。

在这个领域，Kafka可以与ActiveMQ或RabbitMQ等传统消息传递系统相媲美。

Kafka最初的用例是能够重建一个用户活动跟踪管道，作为一组实时发布-订阅提要。这意味着站点活动(页面浏览、搜索或用户可能采取的其他 *** 作)被发布到中心主题，每个活动类型有一个主题。这些提要可用于订阅一系列用例，包括实时处理、实时监视和加载到Hadoop或脱机数据仓库系统以进行脱机处理和报告。

活动跟踪通常是非常大的量，因为许多活动消息会生成的每个用户页面视图。

Kafka通常用于运行监控数据。这涉及聚合来自分布式应用程序的统计信息，以生成集中的 *** 作数据提要。

许多人使用Kafka作为日志聚合解决方案的替代品。日志聚合通常收集服务器上的物理日志文件，并将它们放在一个中心位置(可能是文件服务器或HDFS)进行处理。Kafka抽象了文件的细节，并以消息流的形式对日志或事件数据进行了更清晰的抽象。这允许低延迟处理，并更容易支持多个数据源和分布式数据消费。与以日志为中心的系统如Scribe或Flume相比，Kafka提供了同样好的性能，由于复制而更强的持久性保证，以及更低的端到端延迟。

很多Kafka的用户在处理数据的管道中都有多个阶段，原始的输入数据会从Kafka的主题中被消费，然后被聚合、充实或者转换成新的主题进行进一步的消费或者后续的处理。例如，推荐新闻文章的处理管道可能会从RSS源抓取文章内容，并将其发布到“文章”主题;进一步的处理可能会规范化或删除该内容，并将清理后的文章内容发布到新主题;最后一个处理阶段可能会尝试向用户推荐这些内容。这种处理管道基于单个主题创建实时数据流图。从01000开始，Apache Kafka提供了一个轻量级但功能强大的流处理库，名为Kafka Streams，用于执行上述的数据处理。除了Kafka Streams，其他开源流处理工具包括Apache Storm和Apache Samza。

事件溯源是一种应用程序设计风格，其中将状态更改记录为按时间顺序排列的记录序列。Kafka支持非常大的存储日志数据，这使得它成为这种风格的应用程序的优秀后端。

Kafka可以作为分布式系统的一种外部提交日志。日志有助于在节点之间复制数据，并充当故障节点的重新同步机制，以恢复它们的数据。Kafka的日志压缩特性支持这种用法。在这种用法中，Kafka类似于Apache BookKeeper项目。

《Kafka权威指南》（Neha Narkhede）电子书网盘下载免费在线阅读

链接：>提取码：1234  

书名：Kafka权威指南

作者：Neha Narkhede

译者：薛命灯

豆瓣评分：85

出版社：人民邮电出版社

出版年份：2017-12-26

页数：214

内容简介：

每个应用程序都会产生数据，包括日志消息、度量指标、用户活动记录、响应消息等。如何移动数据，几乎变得与数据本身一样重要。如果你是架构师、开发者或者产品工程师，同时也是Apache Kafka新手，那么这本实践指南将会帮助你成为流式平台上处理实时数据的专家。

本书由出身于LinkedIn的Kafka核心作者和一线技术人员共同执笔，详细介绍了如何部署Kafka集群、开发可靠的基于事件驱动的微服务，以及基于Kafka平台构建可伸缩的流式应用程序。通过详尽示例，你将会了解到Kafka的设计原则、可靠性保证、关键API，以及复制协议、控制器和存储层等架构细节。

● 了解发布和订阅消息模型以及该模型如何被应用在大数据生态系统中

● 学习使用Kafka生产者和消费者来生成消息和读取消息

● 了解Kafka保证可靠性数据传递的模式和场景需求

● 使用Kafka构建数据管道和应用程序的最佳实践

● 在生产环境中管理Kafka，包括监控、调优和维护

● 了解Kafka的关键度量指标

● 探索Kafka如何成为流式处理利器

作者简介：

Neha Narkhede， Confluent联合创始人、CTO，曾在LinkedIn主导基于Kafka和Apache Samza构建流式基础设施，是Kafka作者之一。

Gwen Shapira， Confluent系统架构师，帮助客户构建基于Kafka的系统，在可伸缩数据架构方面拥有十余年经验；曾任Cloudera公司解决方案架构师。另著有《Hadoop应用架构》。

Todd Palino， LinkedIn主任级SRE，负责部署管理大型的Kafka、Zookeeper和Samza集群。

译者简介

薛命灯，毕业于厦门大学软件学院，十余年软件开发和架构经验，InfoQ高级社区编辑。译有《硅谷革命》《生产微服务》等书。微信公众号CodeDeep。

在基于了解或掌握其他同类MQ的基础知识上，怎么比较快速的掌握kafka的核心设计，确保在使用的过程中做到心中有数，做到知其然并知其所以然？本篇文章主要是笔者在已有的rmq的基础上学习kafka的思路以及过程的总结。

ps、rmq指RocketMQ

ps、文章写着写着发现有点长，应该挺乱了……

ps、因为是学习笔记，所以就这样吧，随便看看……

带着问题去学习新的技能，也许会更贴近自己原有的知识储备，也能更好的把新知识纳入自己原有的知识体系并加以补充或者延展，形成更完整的知识脉络。基于原有的rmq的知识体系，在提前梳理了几个相关的，并且浅显的问题，主要是两个方面的内容，一类是MQ模型中生产者客户端的设计与消费者客户端的设计，一类是服务端的总体架构设计。

服务端的总体架构设计

客户端的总体架构设计

相信很多人不管是在面试中，还是在做MQ选型时，都会遇到几个问题，比如Kafka在超过2k的topic时性能会急剧下降，但是rmq在超过2k的topic时性能不存大规模下降，比如Kafka是一个分布式消息队列中间件，而rmq更像一个单机版消息队列中间件等。这些问题的背后，正是两个消息中间件在架构设计上的差异性所导致的，各有优劣势，我们更多的关注设计思路。先看这几个问题。

在rmq服务端写入时，完全是基于commit log 做log append，避免了磁盘的随机读写，再配合零拷贝等技术特性，成为了MQ的高并发利器。而由于RMQ的全量日志都维护在commit log，这也是其余kafka的一个架构设计上的区别。相信初步了解过kafka的同学，都应该知道其设计理念中关于分区与副本的概念，一个topic在集群中存在多个分区，一个分区在集群中存在多个副本，不同的topic之间分区是互不关联的，当单机维护超过2k的topic时，意味着单机存在2k多个分区，即便topic内日志采用log append，那么在高并发写入刷盘时，磁头在这些分区的副本文件上移来移去，性能自然会随之下降，看起来像是‘随机读写’。

这个说法是在一个中间件爱好群里看到大家在讨论时聊到的，感觉相当有意思，这种看法背后又是怎么的逻辑呢？首先，网上能找到的二者大量的对比都是基于单机的对比，集群对比很少。从分区+副本的思路来看，kafka的部署架构看起来是多个broker组成集群，但是内部运转逻辑是分区维度的多副本间高可用，即topic在多个broker之间做高可用的保证，而副本间的运转逻辑是基于zookeeper的ZAB机制。反观rmq最开始的架构确实主从架构，看起来更简单，但是可用性的保证上完全不一样，由于所有的topic都在主节点上，主节点挂了整个集群就运转不下去了，因为只有主可以支持写，所以rmq推荐使用双主架构，后来才引入raft协议支持选举，但依旧是基于broker的选举。二者最大的区别在于，集群中某个节点挂机对于整个集群的影响程度不同，毫无疑问，rmq显得更重。同样的多节点集群中，每个kafka broker都在提供读写能力，因为不同的topic的副本散落在各个broker中，而每个topic的leader副本也会分散在整个集群中，而rmq则不同，所以理论上kafka集群能提供的吞吐量应该会比rmq更高。

从前两个问题，提到了几个很核心的概念，包括分区，副本，而这也是kafka最核心设计内容。kafka的分区这个设计很有意思（ 关于kafka分区 ），kafka的集群是一个整体，对于topic而言，分区个数相当于多少个可读写节点，一个分区下存在多个副本组成一个分布式可选主的‘集群’。

如上图，在一个kafka集群中，部署了三个服务端节点，在topic-a创建时，创建了2个分区，3个副本，在这个部署下，提供读写能力的只有broker1节点上1分区的副本，broker2节点上2分区的副本。对于部署节点broker而言并无主次之分，分区与分区间相互独立，分区内副本间组成集群为topic-a : partation-1提供服务。topic 与 分区 可以看做是逻辑概念，副本为物理概念。所以，前文提到弱化broker的概念就在于，它是基于分区提供服务，这个与rmq的设定完全不同，也许是先入为主的关系，又或者在rmq架构中broker的设定更像是mysql的主从设定，rmq的broker理解起来更简单。

那么什么是isr, asr 在说这个之前，先说说对于一条消息而言，kafka理论上应该如何在兼顾一定性能的情况下获取更高的可靠性？请求写入分区1的leader副本，就能保证数据一定不丢失吗？如果此时leader节点宕机发生选举，由于follower节点还没同步leader数据，那是不是一段时间内的数据就丢失了呢？那为了更高的可靠性，是不是可以选择等所有副本都同步到当前消息才算本次写入成功？follower节点的数据时从leader节点复制而来（此处会抽象一个很常见的水位高低的概念，但是还没详细了解，暂时忽略），那如果follower节点的数据跟leader节点的数据很接近的话，那么复制会很快完成，但是如果某个follower节点的数据落后leader的节点很多，等待完全同步需要更长的时间，毫无疑问将会引发灾难性的结果。那么，有没有一种相对均衡，可接受的方案，比如只等待落后leader节点数据量较低的follower节点成功复制就算成功？技术方案的选择往往都是取舍，特别是多副本间的数据一致性的问题。

isr集合，俗称副本同步集。kafka并非是根据副本间数据复制的偏移量来计算集合，而是根据数据同步的时间间隔（参数为 [replicalagtimemaxms](>

以上就是关于kafka消息的管理全部的内容，包括:kafka消息的管理、深入理解kafka(五)日志存储、kafka术语和配置介绍等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！