Kafka

1.1 Kafka 概念

        Kafka是Apache旗下的一款分布式流媒体平台,Kafka是一种高吞吐量、持久性、分布式的发布订阅的消息队列系统。 它最初由LinkedIn(领英)公司发布,使用Scala语言编写,与2010年12月份开源,成为Apache的顶级子项目。 它主要用于处理消费者规模网站中的所有动作流数据。动作指(网页浏览、搜索和其它用户行动所产生的数据)。

        Kafka 是一种高吞吐量、分布式、基于发布/订阅的消息系统,最初由 LinkedIn 公司开发,使用Scala 语言编写,目前是 Apache 的开源项目。
1. broker:Kafka 服务器,负责消息存储和转发
2. topic:消息类别,Kafka 按照 topic 来分类消息
3. partition:topic 的分区,一个 topic 可以包含多个 partition,topic 消息保存在各个
partition 上
4. offset:消息在日志中的位置,可以理解是消息在 partition 上的偏移量,也是代表该消息的
唯一序号
5. Producer:消息生产者
6. Consumer:消息消费者
7. Consumer Group:消费者分组,每个 Consumer 必须属于一个 group
8. Zookeeper:保存着集群 broker、topic、partition 等 meta 数据;另外,还负责 broker 故
障发现,partition leader 选举,负载均衡等功能

1.2 Kafka 数据存储设计

1.2.1 partition 的数据文件( offset,MessageSize,data )

        partition中的每条Message包含了以下三个属性:offset,MessageSize,data,其中offset表
示 Message 在这个 partition 中的偏移量,offset 不是该 Message 在 partition 数据文件中的实际存储位置,而是逻辑上一个值,它唯一确定了partition中的一条Message,可以认为offset是
partition 中 Message 的 id;MessageSize 表示消息内容 data 的大小;data 为 Message 的具
体内容。

1.2.2 数据文件分段 segment( 顺序读写、分段命令、二分查找 )

        partition 物理上由多个 segment 文件组成,每个 segment 大小相等,顺序读写。每个 segment数据文件以该段中最小的 offset 命名,文件扩展名为.log。这样在查找指定 offset 的 Message 的时候,用二分查找就可以定位到该 Message 在哪个 segment 数据文件中。

1.2.3 数据文件索引(分段索引、 稀疏存储 )

        Kafka 为每个分段后的数据文件建立了索引文件,文件名与数据文件的名字是一样的,只是文件扩展名为.index。index 文件中并没有为数据文件中的每条 Message 建立索引,而是采用了稀疏存储的方式,每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间,从而可以
将索引文件保留在内存中。

1.3 生产者设计

1.3.1 负载均衡(partition 会均衡分布到不同 broker 上) 

        由于消息 topic 由多个 partition 组成,且 partition 会均衡分布到不同 broker 上,因此,为了有效利用 broker 集群的性能,提高消息的吞吐量,producer 可以通过随机或者 hash 等方式,将消息平均发送到多个 partition 上,以实现负载均衡。

 1.3.2 批量发送

        是提高消息吞吐量重要的方式,Producer 端可以在内存中合并多条消息后,以一次请求的方式发送了批量的消息给 broker,从而大大减少 broker 存储消息的 IO 操作次数。但也一定程度上影响了消息的实时性,相当于以时延代价,换取更好的吞吐量。

1.3.3  压缩( GZIP 或 Snappy )

        Producer 端可以通过 GZIP 或 Snappy 格式对消息集合进行压缩。Producer 端进行压缩之后,在Consumer 端需进行解压。压缩的好处就是减少传输的数据量,减轻对网络传输的压力,在对大数据处理上,瓶颈往往体现在网络上而不是 CPU(压缩和解压会耗掉部分 CPU 资源)。

1.2 消费者设计

1.2 .1 Consumer Group

        同一 Consumer Group 中的多个 Consumer 实例,不同时消费同一个 partition,等效于队列模式。partition 内消息是有序的,Consumer 通过 pull 方式消费消息。Kafka 不删除已消费的消息
对于 partition,顺序读写磁盘数据,以时间复杂度 O(1)方式提供消息持久化能力。

1.3  Kafka三大特点

1.高吞吐量:可以满足每秒百万级别消息的生产和消费。

2.持久性:有一套完善的消息存储机制,确保数据高效安全且持久化。

3.分布式:基于分布式的扩展;Kafka的数据都会复制到几台服务器上,当某台故障失效时,生产者和消费者转而使用其它的Kafka。

1.4 消息系统分类

我们知道常见的消息系统有Kafka、RabbitMQ、ActiveMQ等等,但是这些消息系统中所使用的消息模式如下两种:

Peer-to-Peer (Queue)

简称PTP队列模式,也可以理解为点到点。例如单发邮件,我发送一封邮件给小徐,我发送过之后邮件会保存在服务器的云端,当小徐打开邮件客户端并且成功连接云端服务器后,可以自动接收邮件或者手动接收邮件到本地,当服务器云端的邮件被小徐消费过之后,云端就不再存储(这根据邮件服务器的配置方式而定)。

Peer-to-Peer模式工作原理:

  1. 消息生产者Producer1生产消息到Queue,然后Consumer1从Queue中取出并且消费消息。
  2. 消息被消费后,Queue将不再存储消息,其它所有Consumer不可能消费到已经被其它Consumer消费过的消息。
  3. Queue支持存在多个Producer,但是对一条消息而言,只会有一个Consumer可以消费,其它Consumer则不能再次消费。
  4. Consumer不存在时,消息则由Queue一直保存,直到有Consumer把它消费。

Publish/Subscribe(Topic)

简称发布/订阅模式。例如我微博有30万粉丝,我今天更新了一条微博,那么这30万粉丝都可以接收到我的微博更新,大家都可以消费我的消息。

注:以下图示中的 Pushlisher是错误的名词,正确的为 Publisher

 

名词解释:

Publisher=发布者

Topic=主题

Subscriber=订阅者

Publish/Subscribe模式工作原理:

  1. 消息发布者Publisher将消息发布到主题Topic中,同时有多个消息消费者 Subscriber消费该消息。
  2. 和PTP方式不同,发布到Topic的消息会被所有订阅者消费。
  3. 当发布者发布消息,不管是否有订阅者,都不会报错信息。
  4. 一定要先有消息发布者,后有消息订阅者。

注意:Kafka所采用的就是发布/订阅模式,被称为一种高吞吐量、持久性、分布式的发布订阅的消息队列系统。

常用消息系统对比

  • RabbitMQ Erlang编写,支持多协议 AMQP,XMPP,SMTP,STOMP。支持负载均衡、数据持久化。同时 支持Peer-to-Peer和发布/订阅模式
  • Redis 基于Key-Value对的NoSQL数据库,同时支持MQ功能,可做轻量级队列服务使用。就入队操作而言, Redis对短消息(小于10KB)的性能比RabbitMQ好,长消息的性能比RabbitMQ差。
  • ZeroMQ 轻量级,不需要单独的消息服务器或中间件,应用程序本身扮演该角色,Peer-to-Peer。它实质上是 一个库,需要开发人员自己组合多种技术,使用复杂度高
  • ActiveMQ JMS实现,Peer-to-Peer,支持持久化、XA事务
  • Kafka/Jafka 高性能跨语言的分布式发布/订阅消息系统,数据持久化,全分布式,同时支持在线和离线处理
  • MetaQ/RocketMQ 纯Java实现,发布/订阅消息系统,支持本地事务和XA分布式事务
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

chuxuezhe_987

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值