kafka为什么那么快（kafka为什么速度快吞吐高）

本篇文章给大家谈谈kafka为什么那么快，以及kafka为什么速度快吞吐高对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、“根本就不需要 Kafka 这样的大型分布式系统！”
• 2、kafka如何做到磁盘读写比内存读写还快？
• 3、为什么要用kafka？kafka适用什么样的场景？
• 4、kafka:replica副本同步机制
• 5、卡夫卡在生前一直籍籍无名，为什么死后却这么出名？
• 6、Flume之 各种 Channel 的介绍及参数解析

“根本就不需要 Kafka 这样的大型分布式系统！”

作者 | Normcore Tech

译者 | 弯月，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

可能有人没有听说过Kafka，这是一个非常复杂的分布式软件，可协调多台计算机之间的数据传输。更具体地说，该软件的功能是“展平”数据，然后快速地将数据从一个地方移动到另一个地方。一般来讲，如果你有很多数据需要快速处理并发送到其他地方，那么就可以考虑一下Kafka。Kafka还可以在一定期限内保留数据，比如设置数据保存2天、3天或7天，如果你的下游流程失败，那么你还可以利用存储在Kafka中的数据重新处理。

许多处理汇总数据的公司（比如Facebook和Twitter等社交网络数据，以及每晚需要处理大量星体巧尺运动的天文学家，或需要快速了解车辆周围环境数据的自动驾驶车辆公司等）都在使用Kafka，将任意地方生产的数据（即用户通过键盘输入的数据，通过望远镜读取的数据，通过车辆遥测读取的数据等）移动至下游流程进行处理和分析。

最近，WeWork更为名The We Company，他们在共享工作间领域取得了成功，其官网宣称公司的使命为：

“提升世界的意识。”其核心业务是从房地产出租公司那里租下办公室，然后转租给无法按照传统流程租赁办公室的个人和小公司。

为了“提升世界的意识”，该公司致力于为世界各地的个人和公司的团队打造独特却又不完全相同的办公空间。最近，该公司还开始涉足教育。

最近，因为上市，WeWork曝光了一些财务信息：

从好的方面来看，根据A xi os的数据，2018年WeWork的入住率为90%，且会员总数在不断增加。

有人常常将WeWork视为硅谷地区的公司过高估值的完美例子。作为一家房地产企业，WeWork烧钱的速度非常快，毫无疑问他们必须努力让公众市场投资者相信公司有长远的发展，同时和还要维护其作为 科技 公司的地位。

这家公司再三强调说它不是一家房地产公司（毕竟它在不断烧钱对吧？），那么一家消息中介技术公司究竟能提供什么？WeWork曾宣布，它使用Kafka来实现“内部部署的物联网需求”。这是什么意思？

“我们的产品是物理空间，”WeWork的首席开发负责人David Fano说，他在会议期间穿着一件印有“bldgs = data”字样的T恤。

每个办公室都有10个环境传感器——小巧的壁挂式绿色盒子，这些传感器可跟踪室内温度、湿度、空气质量、气压和环境光线水平。还有20个白色的壁挂式信标孝裤高，呈三角形分布在公共空间（开放式办公区和会议室），用于测量WeWork成员的室内位置（数据是匿名的）。顶部四分之一的传感器通过计算机视觉观察成员的活动。

换句话说，WeWork会跟踪WeWork的多个物理事件并记录所有这些数据。但是......他们真的有必要这样做吗？记录Keith Harring壁画周围开放区域的环境温度能给他们带来怎样的竞争优势？更重要的是，他们能否将这些信息用到重要的项目中？

对于公司而言，重要的是要了解办公室的“单位组合” ——私人办公室、会议空间和开放式办公桌——的比例，我们可以利用这些信息对下一个办公间作出调整。

我觉得这家新闻报道机构需要建立一种思考技术的心理模型。Ben Thompson为Stratechery提供了出色的服务，他建立了聚合理论（ .com /concepts/），我在努力为这些理论建立一个网站，如果必须从中选择一个的话，那便是：

大多数创业公司（以及大公司）现有的技术栈都没有必要。

在此，我想挑战一下那些自认为可以在一个周末期间独自建立Facebook的Hacker News上的开发人员，我认为WeWork的实际业务和架构问题在于：

WeWork需要的只不过是清点进出的人数，然后对容量规划做优化而已，追踪“气压”有什么用？只要你有WeWork的ID，那你肯定是个人或公司。那么，在大堂里安装一个登记系统，并要求会议系统发放名牌，不是更简单吗？

第一项要求根本就不需要Kafka：

目前WeWork有280个办公间。纯仔假设每个办公间平均每天有1000个（有这么多吗？）成员出入。那么每天会产生280,000个事务。我们假设每个人在早餐时间进来一次，在午餐时间出入各一次，然后离开。那么每个人会产生4个事务。那么每天大约是100万个事务，这点数据量存储在最常用的开源关系数据库Postgres中就可以了。保守地说，Postgres每秒可以提供10,000次写入（如果设置得当，其写入次数会更高）。每天100万个事件，也就是每秒11次。根本就不是问题。

至于第二项要求，受预订会议室人数的影响，产生的数据量可能更高，但你不需要实时传输数据。你完全可以等到一天结束时批量处理或收集，这同样可以利用司空见惯的关系数据库。

与大型Postgres（或者是BigQuery，或选择其他关系数据库连接到接收JSON传感器数据的Web服务）相比，Kafka的日常开销要高出很多，因为分布式系统非常非常复杂，比传统的系统复杂得多。

Kafka是一个非常优秀的强大的工具，但各个公司在采用该软件时，需要三思而后行。杀鸡焉用牛刀，WeWork用Kafka来记录开放办公间的气压，实属大材小用。

虽然很多时候我们都不需要Kafka，但开发人员很喜欢推荐这个工具，因为他们可以借机积攒经验和谈资。开发人员喜欢用最尖端的技术来完成工作，有时甚至他们自己都没意识到这一点。

过度架构真实存在。 Nemil在一篇文章中说：

在职业生涯的早期，你遇到的大量设计不良的软件系统都要归咎于那些传播错误观点的工程媒体。

在大学和培训班中，你对工程的了解主要来自工程媒体，例如 Hacker News、聚会、会议、Free Code Camp和Hacker Noon等。这些网站广泛讨论的技术（比如微服务、前端框架或区块链）自然会现在你的技术栈中，虽然不是很必要。

使用这些技术栈会导致各个公司承担不必要的债务，导致他们不得不在风险投资周期中寻求更多的资金，无法迈向精益或从别人的资金中解脱出来。

这种不幸的趋势只会持续下去，我们唯一能做的就是公之于众。

原文： .com /p/you-dont-need-kafka

【END】

kafka如何做到磁盘读写比内存读写还快？

Kafka作为一个支持大数据量写入写出的消息队列，由于是基于Scala和Java实现的，而Scala和Java均需要在JVM上运行，所以如果是基于内存的方式，即JVM的堆来进行数据存储则需要开辟很大的堆来支持数据读写，从而会导致GC频繁影响性能。考虑到这些因素，kafka是使用磁盘存储数据的。

Kafka 中消息是以 topic 进行分类的，生产者生晌告产消息，消费者消费消息，都是面向topic的。topic存储结构见下图：

由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了 分片 和 索引 机制，将每个partition分为多个segment。每个 segment对应两个文件——“.index”文件和“.log”文件。

partition文件夹命名规则：

topic 名称+分区序号，举例有一个topic名称文“kafka”，这个topic有三个分区，则每个文件夹命名如下：

index和log文件的命名规则：

1）partition文件夹中的第一个segment从0开始，以后每个segement文件以上一个segment文件的最后一条消息的offset+1命名(当前日志中的第一条消息的offset值命名)。

2）数值最大为64位long大小。19位数字字符长度，没有数字用0填充。

举例，有以下三对文件：

以第二个文件为例看下对应的数据结构：饥谨辩

稀疏索引 需要注意下。

消息查找过程 ：

找message-2589，即offset为2589：

1）先定位segment文件，在0000000000000002584中。

2）计算查找的offset在日志文件的相对偏移量

offset - 文件名的数量 = 2589 - 2584 = 5；

在index文件查找第一个参数的值，若找到，则获取到偏移量，通过偏移量到log文件去找对应偏移量的数据即可；

本例中没有找到，则找到当前索引中偏移量的上线最接近的值，即3，偏移量文246；然后到log文件中从偏移量为246数据开始向下寻找。

简单了解了kafka在数据存储方面的知识，线面我们具体分析下为什么kafka基于磁盘却快于内存。

在前面了解存储结构过程中，我们发现kafka记录log日志使用的结尾追加的方式，即 顺序写 。这样要比随机写块很多，这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

mmap，简单描述其就是将磁盘文件映射到内存, 用户通过修改内存就能修改磁盘文件。

即便是顺序写磁盘，磁盘的读写速度任然比内存慢慢的多得多，好在操作系统已经帮我们解决这个问题。在Linux操作系统中，Linux会将磁盘中的一些数据读取到内存当中，我们烂缺称之为内存页。当需要读写硬盘的时候，都优先在内存页中进行处理。当内存页的数据比硬盘数据多的时候，就形成了 脏页 ，当脏页达到一定数量，操作系统会进行 刷脏 ，即将内存也数据写到磁盘。

问题：不可靠，写到 mmap 中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用 Flush 的时候才把数据真正的写到硬盘。

零拷贝并不是不需要拷贝，而是减少不必要的拷贝次数，通常使用在IO读写过程中。

传统io过程

如上图所示，上图共经历了四次拷贝的过程：

1）数据到到内核态的read buffer;

2）内核态的read buffer到用户态应用层的buffer；

3）用户态到内核态的socket buffer；

4）socket buffer到网卡的buffer（NIC）。

DMA

引入DMA技术，是指外部设备不通过CPU而直接与系统内存交换数据的接口技术，网卡等硬件设备支持DMA技术。

如上图所示，上图共经历了两次拷贝的过程。

sendfile

在内核版本 2.1 中，引入了 Sendfile 系统调用，以简化网络上和两个本地文件之间的数据传输。同时使用了DMA技术。

如上图所示，上图共经历了一次拷贝的过程。

sendfile（ DMA 收集拷贝）

之前我们是把页缓存的数据拷贝到socket缓存中，实际上，我们仅仅需要把缓冲区描述符传到 socket 缓冲区，再把数据长度传过去，这样 DMA 控制器直接将页缓存中的数据打包发送到网络中就可以了。

如上图所示，最后一次的拷贝也被消除了，数据-read buffer-NIC。

kafka通过java和scala实现，而Java对sendfile是通过NIO 的 FileChannel （java.nio.channels.FileChannel ）的 transferTo 和 transferFrom 方法实现零拷贝

注： transferTo 和 transferFrom 并不保证一定能使用零拷贝。实际上是否能使用零拷贝与操作系统相关，如果操作系统提供 sendfile 这样的零拷贝系统调用，则这两个方法会通过这样的系统调用充分利用零拷贝的优势，否则并不能通过这两个方法本身实现零拷贝。

为什么要用kafka？kafka适用什么样的场景？

Apache Kafka 集群环脊知拦境搭建 - - ITeye技术网站

;utm_medium=referral

接下来是老生常谈的问题：为什么要用kafka？kafka适用什么样的场景？我先和大家分享一下自己再项目中的使用总结，有其他想法的同学欢迎补充：

使用kafka的理由：

1.分布式，高吞吐量，速度快（kafka是直接通樱胡过磁盘存储，线性读写，速度快：避免了数据在JVM内存和系统内存之间的复制，减少耗性能的对象创建和垃圾回收）

2.同时支持实时和离线两种解决方案（相信很多项目都有类似的需求猛脊，这也是Linkedin的官方架构，我们是一部分数据通过storm做实时计算处理，一部分到hadoop做离线分析）。

3.open source (open source 谁不喜欢呢)

4.源码由scala编写，可以运行在JVM上（笔者对scala很有好感，函数式语言一直都挺帅的，spark也是由scala写的，看来以后有空得刷刷scala）

使用场景：

笔者主要是用来做日志分析系统，其实Linkedin也是这么用的，可能是因为kafka对可靠性要求不是特别高，除了日志，网站的一些浏览数据应该也适用。（只要原始数据不需要直接存DB的都可以）

kafka:replica副本同步机制

Kafka的流行归功于它设计和操作简单、存储系统高效、充分利用磁盘顺序读写等特性、非常适合在线日志收集等高吞吐场景。

Kafka特性之一是它的复制协议。复制协议是保障kafka高可靠性的关键。对于单个集群中每个Broker不同工作负载情况下，如何自动调优Kafka副本的工作方式是比较有挑战的。它的挑战之一是要知道如何避免follower进入和退出同步副本列表(即ISR)。从用户的角度来看，如果生产者发送一大批海量消息，可能会引起Kafka Broker很多警告。这些警报表明一些topics处于“under replicated”状态，这些副本处于同步失败或失效状态，更意味着数据没有被复制到足够数量Broker从而增加数据丢失的概率。因此Kafka集群中处于“under replicated”中Partition数要密切监控。这个警告应该来自于Broker失效,减慢或暂停等状态而不是生产者写不同大小消息引起的。

Kafka中主题的每个Partition有一个预写式日志文件，每个Partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到Partition中，Partition中的每个消息都有一个连续的序列号叫做offset， 确定它在分区日志中唯一的位置。

Kafka每个topic的partition有N个副本，其中N是topic的复制因子。Kafka通过多副本机制实现故障自动转移，当Kafka集群中一个Broker失效情况下仍然保证服务可用。在Kafka中发生复制时确保partition的预写式日志有序地写到其他节点上。N个replicas中。其中一个replica为leader，其他都为follower，leader处理partition的所有读写请求，与此同时，follower会被动定期地去复制leader上的数据。

如下图所示，Kafka集群中有4个broker, 某topic有3个partition,且复制因子即副本个数也为3：

Kafka提供了数据复制算法保证，如果leader发生故障或挂掉，一个新leader被选举并被接受客户端的消息成功写入。Kafka确保从同步副本列表中选举一个副本为leader，或者说follower追赶leader数据。leader负责维护和跟踪ISR(In-Sync Replicas的缩写，表示副本同步队列，具体可参考下节)中所有follower滞后的状态。当producer发送一条消息到broker后，leader写入消息并复制到所有follower。消息提交之后才被成功复制到所有的同步副本。消息复制延迟受最慢的follower限制，重要的是快速检测慢副本，如果follower“落后”太多或者失效，leader将会把它从ISR中删除。

副本同步队列(ISR)

所谓同步，必须满足如下两个条件：

默认情况下Kafka对应的topic的replica数量为1，即每个partition都有一个唯一的肢指leader，为了确保消息的可靠性，通常应用中将其值(由broker的参数offsets.topic.replication.factor指定)大小设置为大于1，比如3。 所有的副本（replicas）统称为Assigned Replicas，即AR。ISR是AR中的一个子集，由leader维护ISR列表，follower从leader同步数据有一些延迟。任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表举饥，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

上一节中的HW俗称高水位，是HighWatermark的缩写，取一个partition对应的ISR中最小的LEO作为HW，consumer最多只能消费到HW所在的位置。另外每个replica都有HW,leader和follower各自负责更新自己的HW的状态。对于leader新写入的消息，consumer不能立刻消费，leader会等历答配待该消息被所有ISR中的replicas同步后更新HW，此时消息才能被consumer消费。这样就保证了如果leader所在的broker失效，该消息仍然可以从新选举的leader中获取。对于来自内部broKer的读取请求，没有HW的限制。

下图详细的说明了当producer生产消息至broker后，ISR以及HW和LEO的流转过程：

由此可见，Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上，同步复制要求所有能工作的follower都复制完，这条消息才会被commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，follower异步的从leader复制数据，数据只要被leader写入log就被认为已经commit，这种情况下如果follower都还没有复制完，落后于leader时，突然leader宕机，则会丢失数据。而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率。

副本不同步的异常情况

broker 分配的任何一个 partition 都是以 Replica 对象实例的形式存在，而 Replica 在 Kafka 上是有两个角色： leader 和 follower，只要这个 Replica 是 follower，它便会向 leader 进行数据同步。

反映在 ReplicaManager 上就是如果 Broker 的本地副本被选举为 follower，那么它将会启动副本同步线程，其具体实现如下所示：

简单来说，makeFollowers() 的处理过程如下：

关于第6步，并不一定会为每一个 partition 都启动一个 fetcher 线程，对于一个目的 broker，只会启动 num.replica.fetchers 个线程，具体这个 topic-partition 会分配到哪个 fetcher 线程上，是根据 topic 名和 partition id 进行计算得到，实现所示：

如上所示，在 ReplicaManager 调用 makeFollowers() 启动 replica fetcher 线程后，它实际上是通过 ReplicaFetcherManager 实例进行相关 topic-partition 同步线程的启动和关闭，其启动过程分为下面两步：

addFetcherForPartitions() 的具体实现如下所示：

这个方法其实是做了下面这几件事：

ReplicaFetcherManager 创建 replica Fetcher 线程的实现如下：

replica fetcher 线程在启动之后就开始进行正常数据同步流程了，这个过程都是在 ReplicaFetcherThread 线程中实现的。

ReplicaFetcherThread 的 doWork() 方法是一直在这个线程中的 run() 中调用的，实现方法如下：

在 doWork() 方法中主要做了两件事：

processFetchRequest() 这个方法的作用是发送 Fetch 请求，并对返回的结果进行处理，最终写入到本地副本的 Log 实例中，其具体实现：

其处理过程简单总结一下：

fetch() 方法作用是发送 Fetch 请求，并返回相应的结果，其具体的实现，如下：

processPartitionData

这个方法的作用是，处理 Fetch 请求的具体数据内容，简单来说就是：检查一下数据大小是否超过限制、将数据追加到本地副本的日志文件中、更新本地副本的 hw 值。

在副本同步的过程中，会遇到哪些异常情况呢？

大家一定会想到关于 offset 的问题，在 Kafka 中，关于 offset 的处理，无论是 producer 端、consumer 端还是其他地方，offset 似乎都是一个形影不离的问题。在副本同步时，关于 offset，会遇到什么问题呢？下面举两个异常的场景：

以上两种情况都是 offset OutOfRange 的情况，只不过：一是 Fetch Offset 超过了 leader 的 LEO，二是 Fetch Offset 小于 leader 最小的 offset

在介绍 Kafka 解决方案之前，我们先来自己思考一下这两种情况应该怎么处理？

上面是我们比较容易想出的解决方案，而在 Kafka 中，其解决方案也很类似，不过遇到情况比上面我们列出的两种情况多了一些复杂，其解决方案如下：

针对第一种情况，在 Kafka 中，实际上还会发生这样一种情况，1 在收到 OutOfRange 错误时，这时去 leader 上获取的 LEO 值与最小的 offset 值，这时候却发现 leader 的 LEO 已经从 800 变成了 1100（这个 topic-partition 的数据量增长得比较快），再按照上面的解决方案就不太合理，Kafka 这边的解决方案是：遇到这种情况，进行重试就可以了，下次同步时就会正常了，但是依然会有上面说的那个问题。

replica fetcher 线程关闭的条件，在三种情况下会关闭对这个 topic-partition 的拉取操作：

这里直接说线程关闭，其实不是很准确，因为每个 replica fetcher 线程操作的是多个 topic-partition，而在关闭的粒度是 partition 级别，只有这个线程分配的 partition 全部关闭后，这个线程才会真正被关闭。

stopReplica

StopReplica 的请求实际上是 Controller 发送过来的，这个在 controller 部分会讲述，它触发的条件有多种，比如：broker 下线、partition replica 迁移等等。

makeLeaders

makeLeaders() 方法的调用是在 broker 上这个 partition 的副本被设置为 leader 时触发的，其实现如下：

调用 ReplicaFetcherManager 的 removeFetcherForPartitions() 删除对这些 topic-partition 的副本同步设置，这里在实现时，会遍历所有的 replica fetcher 线程，都执行 removePartitions() 方法来移除对应的 topic-partition 集合。

removePartitions

这个方法的作用是：ReplicaFetcherThread 将这些 topic-partition 从自己要拉取的 partition 列表中移除。

ReplicaFetcherThread的关闭

前面介绍那么多，似乎还是没有真正去关闭，那么 ReplicaFetcherThread 真正关闭是哪里操作的呢？

实际上 ReplicaManager 每次处理完 LeaderAndIsr 请求后，都会调用 ReplicaFetcherManager 的 shutdownIdleFetcherThreads() 方法，如果 fetcher 线程要拉取的 topic-partition 集合为空，那么就会关闭掉对应的 fetcher 线程。

卡夫卡在生前一直籍籍无名，为什么死后却这么出名？

卡夫卡的写作风格很荒诞，笔法很犀利、夸张，调侃。他喜欢用来开玩笑，看起来很玩世不恭的方式写文章。他生活的年代是正处动荡，大家岁郑都在追求真实世界里的平静给自己安慰，他这种嘲讽，荒诞的写作风格，是对社会现实，对拜金主义，对人性冷漠的很大讽刺。人本来就过的不好，自然不能接受这种风格，觉得很暗黑。

卡夫卡从小生活的环境也很压抑，父亲对他的管理很粗暴压制，也导致卡夫卡的性格不是很健全，看待事情的方式方法都不太积极。长大成人的卡夫卡看待父亲还是害怕恐慌，不敢接近。他只裤含能把自己的情绪寄托在书里，宣泄自己乎纯颂的不满和情绪，得到暂时的平和。他是热爱写作的，即使不能让自己变得富裕，但可以在其中收货快乐。卡夫卡更像是一个兼职作家，

 

因为写作不挣钱反而花钱，所以他有全职的工作来维持自己的生活，每天浑浑噩噩的上班，为的就是可以继续他热爱的写作事业。

卡夫卡一直在写，没有停止，他的小说《变形记》后来被收录在课本中，让更多的孩子开始学习。可以发现的是，随着时代的发展，人们对书的风格的接受度就变多了，所以卡夫卡就出名了。像这种讽刺现实，利用一个甲虫的形象来观察一家人的生活，最后孤独惨死的故事，更好的反映了事态炎凉。一家人之间都只有索取利用，更何况冰冷的社会，这个文章很高的反映了社会关系的冷酷，人性的贪婪拜金。

[img]

Flume之 各种 Channel 的介绍及参数解析

Channel被设计为Event中转临时缓冲区，存储Source收集并且没有被Sink读取的Event，为平衡Source收集和Sink读取数据的速度，可视为Flume内部的消息队列。Channel线程安全并且具有事务性，支持source写失败重复写和sink读失败重复读等操作。

常用的Channel类型有Memory Channel、File Channel、KafkaChannel等。

对比Channel, Memory Channel读写速度快，但是存储数据量小，Flume进程挂掉空兄、服务器停机或者重启都会导致数据丢失。部署Flume Agent的线上服务器内存资源充足、不关心数据丢失的场景下可以使用。

将 event 写入磁盘文件，与 Memory Channel 相比存储容量大，无数据丢失风险。File Channle 数据存储路径可以配置多磁盘文件路径，通过磁盘并行写入提高FileChannel 性能。Flume 将 Event 顺序写入到 File Channel 文件的末尾，在配置文件中通过设置 maxFileSize 参数配置数据文件大小，当被写入的文件大小达到上限时 Flume 会重新创建新的文件存储写入的 Event。当然数据文件数量也不会无限增长，当一个已关闭的只读数据文件中的拿亏明 Event 被读取完成，并且 Sink 已经提交读取完成的事务，则 Flume 将删除存储该数据的文件。Flume 通过设置检查点和备份检查点实现在 Agent 重启之后快速将 File Channle 中的数据按顺序回放到内存中，保证在 Agent 失败重启后仍然消告能够快速安全地提供服务。

将Kafka作为Channel存储，Kafka是分布式、可扩展、高容错、高吞吐的分布式系统，Kafka通过优秀的架构设计充分利用磁盘顺序特性，在廉价的硬件条件下完成高效的消息发布和订阅。

Memory Channel在使用的过程中受内存容量的限制不能缓存大量的消息，并且如果Memory Channel中的消息没来得及写入Sink，此时Agent出现故障就会造成数据丢失。File Channel虽然能够缓存更多的消息，但如果缓存下来的消息还没有写入Sink，此时Agent出现故障则File Channel中的消息不能被继续使用，直到该Agent重新恢复才能够继续使用File Channel中的消息。Kafka Channel相对于Memory Channel和File Channel存储容量更大、容错能力更强，弥补了其他两种Channel的短板，如果合理利用Kafka的性能，能够达到事半功倍的效果。

有了Kafka Channel可以在日志收集层只配置Source组件和Kafka Channel组件，不需要再配置Sink组件，减少了日志收集层启动的进程数并且有效降低服务器内存、磁盘等资源使用率，日志汇聚层可以只配置Kafka Channel和Sink，不需要再配置Source，减少日志汇聚层的进程数，这样的配置既能降低服务器的资源使用率又能减少Event在网络之间的传输，有效提高日志采集系统的性能。

Kafka Channel相关操作在org.apache.flume.channel.kafka包的KafkaChannel类定义，

kafka相关参数的默认值在org.apache.kafka.clients.CommonClientConfigs包中的KafkaChannel-Configuration中。

Kafka的通用配置参数在配置文件中都以“kafka.”为前缀，针对Producer或者Consumer的相关配置以“kafka.producer. ”或者“kafka.consumer. ”为前缀，

源码 KafkaChannelConfiguration 中相关默认配置参数定义如下：

说明：agent_name 没有配置Source，只配置了Channel和Sink，使用的Channel类型为Kafka Channel，主题名称为“test_channel”, consumer组id为“test-consumer”, Sink类型为 hdfs 滚动生成文件，对接的Channel为KafkaChannel channel_name。

关于kafka为什么那么快和kafka为什么速度快吞吐高的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。