Kafka的设计原理

kafka是领英(Linked-in)开源的,承载着领英万亿级/天的消息数量。

具有如下特点

  • 高吞吐量、低延迟:每秒可以处理几十万条消息,它的延迟最低只有几毫秒
  • 可扩展性:支持热扩展
  • 持久性、可靠性:消息被持久化到本地磁盘,支持数据备份防止数据丢失
  • 容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败)
  • 高并发:支持数千个客户端同时读写

和大多数消息队列类似,kafka中有这么几个角色:

  • Topic:消息存放的目录即主题
  • Producer:生产消息到topic的一方
  • Consumer:订阅topic消费消息的一方
  • Broker:Kafka的服务实例就是一个broker

消息主题(Topic)

每个topic,kafka维护着几个分区日志(Patitioned Log)在存储它的内容,如下图:

这张图中有几个概念:

  • Partition:消息的分区,一个topic中,通常会分为几个区(默认3)。消息发送到哪个区,由消息生产者决定,一般通过topic和key取hash来决定分区。
  • 顺序消费:在每个区中的消息是顺序的,即同一个topic的消息不是顺序消费的(如果partition个数大于1的话)。
  • 消息过期:kafka会将消息保存一段时间,保存的时间可配置。不管消息有没有被消费,到了过期时间消息就会被删除。

消息生产者(Producer)

  • Producers直接发送消息到broker上的leader partition,不需要经过任何中介一系列的路由转发。为了实现这个特性,kafka集群中的每个broker都可以响应producer的请求,并返回topic的一些元信息,这些元信息包括哪些机器是存活的,topic的leader partition都在哪,现阶段哪些leader partition是可以直接被访问的。
  • Producer客户端自己控制着消息被推送到哪些partition。实现的方式可以是随机分配、实现一类随机负载均衡算法,或者指定一些分区算法。Kafka提供了接口供用户实现自定义的分区,用户可以为每个消息指定一个消息key,通过这个key来实现一些hash分区算法。
  • 发送效率。以Batch的方式推送数据可以极大的提高处理效率,kafka Producer 可以将消息在内存中累计到一定数量后作为一个batch发送请求。Batch的数量大小可以通过Producer的参数控制,参数值可以设置为累计的消息的数量(如500条)、累计的时间间隔(如100ms)或者累计的数据大小(64KB)。通过增加batch的大小,可以减少网络请求和磁盘IO的次数,当然具体参数设置需要在效率和时效性方面做一个权衡。
  • 发送的可靠性。配置ack参数,producer需要server接收到数据之后发出的确认接收的信号,ack=0:不需要,ack=1:leader成功将数据写入本地log,all:leader需要等待所有备份都成功写入日志。

消息消费者(Consumer)

  • 消息的消费由consumer主动pull,这一点不同于其他消息队列。
  • 每个consumer都归属于一个组(consumer group),一条消息只能被同一个组中的一个consumer消费。
  • 如果所有consumer都有同一个组名,那么kafka就相当于一个队列消息服务,而各个consumer均衡的消费相应partition中的数据。若consumer的组名都不同,那么此时kafka就相当于一个广播服务,会把topic中的所有消息广播到每个consumer。
  • 在kafka中,当前读到消息的offset值是由consumer来维护的,因此,consumer可以自己决定如何读取kafka中的数据。比如,consumer可以通过重设offset值来重新消费已消费过的数据。不管有没有被消费,kafka会保存数据一段时间,这个时间周期是可配置的,只有到了过期时间,kafka才会删除这些数据。
  • Kafka提供了两套consumer api,分为high-level api和sample-api。Sample-api 是一个底层的API,它维持了一个和单一broker的连接,并且这个API是完全无状态的,每次请求都需要指定offset值,因此,这套API也是最灵活的。High-level API,封装了对集群中一系列broker的访问,可以透明的消费一个topic。它自己维持了已消费消息的状态(zookeeper中保存offset),即每次消费的都是下一个消息。

kafka其他特性

    • 消息压缩。压缩可以提高网络传输效率,但会增加CPU负担。主要应用在大数据的处理中,此时网络的传输往往成为性能瓶颈。
    • 数据冗余。kafka在0.8版本以后支持了数据冗余,可将一份数据备份在多个其他节点中。一个备份数量为n的集群允许n-1个节点宕机的情况下保证数据不丢失。
    • 消息持久化。Kafka高度依赖文件系统来存储和缓存消息,一般的人认为磁盘是缓慢的,其实磁盘的的随机读写非常慢,但顺序写非常快。比如:在一个6x7200rpm SATA RAID-5 的磁盘阵列上线性写的速度大概是600M/秒,但是随机写的速度只有100K/秒,两者相差将近6000倍。
时间: 2024-10-12 12:34:45

Kafka的设计原理的相关文章

kafka入门:简介、使用场景、设计原理、主要配置及集群搭建(转)

问题导读: 1.zookeeper在kafka的作用是什么? 2.kafka中几乎不允许对消息进行"随机读写"的原因是什么? 3.kafka集群consumer和producer状态信息是如何保存的? 4.partitions设计的目的的根本原因是什么? 一.入门 1.简介 Kafka is a distributed,partitioned,replicated commit logservice.它提供了类似于JMS的特性,但是在设计实现上完全不同,此外它并不是JMS规范的实现.k

深入理解kafka设计原理

最近开研究kafka,下面分享一下kafka的设计原理.kafka的设计初衷是希望作为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力. 1.持久性 kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎没有可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为了减少磁盘写入的次数,broker会将消息暂

中间件 | kafka简介、使用场景、设计原理、主要配置及集群搭建

开源Java学习 公众号 一.入门 1.简介 Kafka is a distributed,partitioned,replicated commit logservice.它提供了类似于JMS的特性,但是在设计实现上完全不同,此外它并不是JMS规范的实现.kafka对消息保存时根据Topic进行归类,发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成,每个实例(server)成为broker.无论是kafka集群,还是producer和c

二 kafka设计原理

kafka的设计初衷是希望作为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力. 1.持久性 kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎没有可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时

【转载】kafka的工作原理

http://www.ibm.com/developerworks/cn/opensource/os-cn-kafka/index.html 消息队列 消息队列技术是分布式应用间交换信息的一种技术.消息队列可驻留在内存或磁盘上, 队列存储消息直到它们被应用程序读走.通过消息队列,应用程序可独立地执行--它们不需要知道彼此的位置.或在继续执行前不需要等待接收程序接收此消息.在分布式计算环境中,为了集成分布式应用,开发者需要对异构网络环境下的分布式应用提供有效的通信手段.为了管理需要共享的信息,对应

分布式公布订阅消息系统 Kafka 架构设计

我们为什么要搭建该系统 Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础. 如今它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用. 活动流数据是全部站点在对其站点使用情况做报表时要用到的数据中最常规的部分.活动数据包含页面訪问量(page view).被查看内容方面的信息以及搜索情况等内容.这样的数据通常的处理方式是先把各种活动以日志的形式写

分布式发布订阅消息系统 Kafka 架构设计[转]

分布式发布订阅消息系统 Kafka 架构设计 转自:http://www.oschina.net/translate/kafka-design 我们为什么要搭建该系统 Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础.现在它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用. 活动流数据是所有站点在对其网站使用情况做报表时要用到的数据中最常规的部

分布式发布订阅消息系统 Kafka 架构设计

我们为什么要搭建该系统 Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础.现在它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用. 活动流数据是所有站点在对其网站使用情况做报表时要用到的数据中最常规的部分.活动数据包括页面访问量(page view).被查看内容方面的信息以及搜索情况等内容.这种数据通常的处理方式是先把各种活动以日志的形式写入某

Kafka 的这些原理你知道吗

如果只是为了开发 Kafka 应用程序,或者只是在生产环境使用 Kafka,那么了解 Kafka 的内部工作原理不是必须的.不过,了解 Kafka 的内部工作原理有助于理解 Kafka 的行为,也利用快速诊断问题.下面我们来探讨一下这三个问题 Kafka 是如何进行复制的 Kafka 是如何处理来自生产者和消费者的请求的 Kafka 的存储细节是怎样的 如果感兴趣的话,就请花费你一些时间,耐心看完这篇文章. 集群成员间的关系 我们知道,Kafka 是运行在 ZooKeeper 之上的,因为 Zo