Kafka理论及经典面试题

1.什么是kafka？
Kafka是一种高吞吐量的分布式发布–订阅消息系统。它可以处理消费者规模的网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。

Kafka是一个分布式的流处理平台。kafka主要是作为一个分布式的、可分区的、具有副本数的日志服务系性、高容错性、访问速度快、分布式等特性；统, 具有高水平扩展主要应用场景是：日志收集系统和分布式发布–订阅消息系统.

2.kafka的组件？

• Topic ：消息根据Topic进行归类
• Producer：发送消息者
• Consumer：消息接受者
• broker：每个kafka实例(server)
• Zookeeper：依赖集群保存meta信息。

3.什么是zk？ 应用场景？
其实说实话，问这个问题，一般就是看看你是否了解 zookeeper，因为 zk 是分布式系统中很常见的一个基础系统。而且问的话常问的就是说 zk 的使用场景是什么？看你知道不知道一些基本的使用场景。但是其实 zk 挖深了自然是可以问的很深很深的。

大致来说，zk 的使用场景如下，我就举几个简单的，大家能说几个就好了：

• 分布式协调
• 分布式锁
• 元数据/配置信息管理
• HA高可用性

分布式协调
这个其实是 zk 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。那 A 系统如何知道 B 系统的处理结果？用 zk 就可以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zk 上对某个节点的值注册个监听器，一旦 B 系统处理完了就修改 zk 那个节点的值，A 立马就可以收到通知，完美解决。

分布式锁
举个栗子。对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行完另外一个机器再执行。那么此时就可以使用 zk 分布式锁，一个机器接收到了请求之后先获取 zk 上的一把分布式锁，就是可以去创建一个 znode，接着执行操作；然后另外一个机器也尝试去创建那个 znode，结果发现自己创建不了，因为被别人创建了，那只能等着，等第一个机器执行完了自己再执行。

元数据/配置信息管理
zk 可以用作很多系统的配置信息的管理，比如 kafka、storm 等等很多分布式系统都会选用 zk 来做一些元数据、配置信息的管理，包括 dubbo 注册中心不也支持 zk 么？

HA高可用性
这个应该是很常见的，比如 hadoop、hdfs、yarn 等很多大数据系统，都选择基于 zk 来开发 HA 高可用机制，就是一个重要进程一般会做主备两个，主进程挂了立马通过 zk 感知到切换到备用进程。

5.Kafka 与传统消息系统之间有三个关键区别？
实际上，Kafka 并非传统意义上的消息队列，它与 RabbitMQ 等消息系统并不一样。它更像是一个分布式的文件系统或数据库。Kafka 与传统消息系统之间有三个关键区别。

• Kafka 持久化日志，这些日志可以被重复读取和无限期保留
• Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性
• Kafka 支持实时的流式处理

以上三点足以将 Kafka 与传统的消息队列区别开，我们甚至可以把它看成是流式处理平台。因此，在 Kafka 里存储数据并不是什么疯狂事，甚至可以说 Kafka 本来就是设计用来存储数据的。数据经过校验后被持久化在磁盘上，并通过复制副本提升容错能力。再多的数据都不会拖慢 Kafka，在生产环境中，有些 Kafka 集群甚至已经保存超过 1 TB 的数据。

6.JMS消息传输模型

• 点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。

• 发布/订阅模式（一对多，数据生产后，推送给所有订阅者）

发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即时当前订阅者不可用，处于离线状态。

7.总结一下常见 的JMS？

JMS消息服务器 ActiveMQ
ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的。
主要特点：

• 多种语言和协议编写客户端。语言: Java, C, C++, C#, Ruby, Perl, Python, PHP。应用协议:
  OpenWire,Stomp REST,WS Notification,XMPP,AMQP
• 完全支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务)
• 对Spring的支持,ActiveMQ可以很容易内嵌到使用Spring的系统里面去,而且也支持Spring2.0的特性
• 通过了常见J2EE服务器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的测试,其中通过JCA 1.5 resource adaptors的配置,可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上
• 支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
• 支持通过JDBC和journal提供高速的消息持久化
• 从设计上保证了高性能的集群,客户端-服务器,点对点
• 支持Ajax
• 支持与Axis的整合
• 可以很容易得调用内嵌JMS provider,进行测试

分布式消息中间件 Metamorphosis
Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件，类似于LinkedIn的Kafka，具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，在淘宝和支付宝有着广泛的应用，现已开源。
主要特点：

• 生产者、服务器和消费者都可分布

• 消息存储顺序写

• 性能极高,吞吐量大

• 支持消息顺序

• 支持本地和XA事务

• 客户端pull，随机读,利用sendfile系统调用，zero-copy ,批量拉数据

• 支持消费端事务

• 支持消息广播模式

• 支持异步发送消息

• 支持http协议

• 支持消息重试和recover

• 数据迁移、扩容对用户透明

• 消费状态保存在客户端

• 支持同步和异步复制两种HA

• 支持group commit

分布式消息中间件 RocketMQ
RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点：

• 能够保证严格的消息顺序

• 提供丰富的消息拉取模式

• 高效的订阅者水平扩展能力

• 实时的消息订阅机制

• 亿级消息堆积能力

• Metaq3.0 版本改名，产品名称改为RocketMQ

其他MQ

• .NET消息中间件 DotNetMQ
• 基于HBase的消息队列 HQueue
• Go 的 MQ 框架 KiteQ
• AMQP消息服务器 RabbitMQ
• MemcacheQ 是一个基于 MemcacheDB 的消息队列服务器。

8.kafka 消息 默认保存多久？

默认保存168hours(7天)

日志保存清理策略

属性名	含义	默认值
log.cleanup.polict	日志清理保存的策略只有delete和compact两种	delete
log.retention.hours	日志保存的时间，可以选择hours,minutes和ms	168(7day)
log.retention.bytes	删除前日志文件允许保存的最大值	-1
log.segment.delete.delay.ms	日志文件被真正删除前的保留时间	60000
log.cleanup.interval.mins	每隔一段时间多久调用一次清理的步骤	10
log.retention.check.interval.ms	周期性检查是否有日志符合删除的条件（新版本使用）	300000

9.topic 删除, 物理删除和逻辑删除？
在计算机中资料数据等都以文件形式存储，删除文件分为两种情况。分为逻辑删除和物理删除。

• 逻辑删除：
  文件没有被真正的删除，只不过是文件名的第一个字节被改成操作系统无法识别的字符，通常这种删除操作是可逆的，就是说用适当的工具或软件可以把删除的文件恢复出来。

• 物理删除：
  指文件存储所用到的磁存储区域被真正的擦除或清零，这样删除的文件是不可以恢复的。

kafka中关于删除参数的配置
delete.topic.enable=true （kafka 的topic是否物理删除，true-物理删除，false-逻辑删除）

10.kafka 消息的有序论？

两种方案：
方案一，kafka topic 只设置一个partition分区
方案二，producer将消息发送到指定partition分区

解析：

• 方案一：kafka默认保证同一个partition分区内的消息是有序的，则可以设置topic只使用一个分区，这样消息就是全局有序，缺点是只能被consumer
  group里的一个消费者消费，降低了性能，不适用高并发的情况
• 方案二：既然kafka默认保证同一个partition分区内的消息是有序的，则producer可以在发送消息时可以指定需要保证顺序的几条消息发送到同一个分区，这样消费者消费时，消息就是有序。

producer发送消息时具体到topic的哪一个partition分区，提供了三种方式

1）指定分区
2）不指定分区，有指定key 则根据key的hash值与分区数进行运算后确定发送到哪个partition分区
3）不指定分区，不指定key，则轮询各分区发送

11.CG的Consumer与topic关系？

本质上kafka只支持Topic；

• 每个group中可以有多个consumer，每个consumer属于一个consumer group；
  通常情况下，一个group中会包含多个consumer，这样不仅可以提高topic中消息的并发消费能力，而且还能提高"故障容错"性，如果group中的某个consumer失效那么其消费的partitions将会有其他consumer自动接管。
• 对于Topic中的一条特定的消息，只会被订阅此Topic的每个group中的其中一个consumer消费，此消息不会发送给一个group的多个consumer；
  那么一个group中所有的consumer将会交错的消费整个Topic，每个group中consumer消息消费互相独立，我们可以认为一个group是一个"订阅"者。
• 在kafka中,一个partition中的消息只会被group中的一个consumer消费(同一时刻)；
  一个Topic中的每个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以同时消费多个partitions中的消息。
• kafka的设计原理决定,对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。
  kafka只能保证一个partition中的消息被某个consumer消费时是顺序的；事实上，从Topic角度来说,当有多个partitions时,消息仍不是全局有序的。

12.Kafka消息的分发策略

Producer客户端负责消息的分发

• kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"/"partitions
  leader列表"等信息；
• 当producer获取到metadata信息之后, producer将会和Topic下所有partition
  leader保持socket连接；
• 消息由producer直接通过socket发送到broker，中间不会经过任何"路由层"，事实上，消息被路由到哪个partition上由producer客户端决定；
  比如可以采用"random"“key-hash”"轮询"等,如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。
• 在producer端的配置文件中,开发者可以指定partition路由的方式。

13.producer发送消息的应答机制？ ACK机制？ 0 1 -1 all

Producer消息发送的应答机制 ：ACK
设置发送数据是否需要服务端的反馈,有四个值： 0,1,-1,All

		0: producer不会等待broker发送ack 
		1: 当leader接收到消息之后发送ack 
		-1: 当所有的follower都同步消息成功后发送ack
		All:

request.required.acks=0

14.segment 文件组成？

• Segment file组成：由2大部分组成，分别为index file和data
  file，此2个文件一一对应，成对出现，后缀".index"和“.log”分别表示为segment索引文件、数据文件。
  

• Segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。

• 索引文件存储大量元数据，数据文件存储大量消息，索引文件中元数据指向对应数据文件中message的物理偏移地址。
  

• segment data file由许多message组成， message物理结构如下：

关键字	解释说明
8 byte offset	在parition(分区)内的每条消息都有一个有序的id号，这个id号被称为偏移(offset),它可以唯一确定每条消息在parition(分区)内的位置。即offset表示partiion的第多少message
4 byte message size	message大小
4 byte CRC32	用crc32校验message
1 byte “magic"	表示本次发布Kafka服务程序协议版本号
1 byte “attributes"	表示为独立版本、或标识压缩类型、或编码类型。
4 byte key length	表示key的长度,当key为-1时，K byte key字段不填
K byte key	可选
value bytes payload	表示实际消息数据。

15.kafka message消息包含那些？

读取offset=368776的message，需要通过下面2个步骤查找。

• 查找segment file
  00000000000000000000.index表示最开始的文件，起始偏移量(offset)为0
  00000000000000368769.index的消息量起始偏移量为368770 = 368769 + 1
  00000000000000737337.index的起始偏移量为737338=737337 + 1 其他后续文件依次类推。
  以起始偏移量命名并排序这些文件，只要根据offset 二分查找文件列表，就可以快速定位到具体文件。当offset=368776时定位到00000000000000368769.index和对应log文件。
• 通过segment file查找message 当offset=368776时，依次定位到00000000000000368769.index的元数据物理位置和00000000000000368769.log的物理偏移地址
  然后再通过00000000000000368769.log顺序查找直到offset=368776为止。