Kafka入门、底层原理、面试题讲解【小二讲堂】

Spark全面精讲：https://blog.csdn.net/Mirror_w/article/details/89408567

一、Kafka概述

kafka是一个分布式的消息队列系统（Message Queue）.kafka保证数据不丢失，采用顺序写磁盘技术。
1.有顺序的储存保证了高效的读取。–高吞吐量
2.分布式系统，易于向外扩展，所有的producer、broker和consumer都会有多个，均为分布式的。无序停机即可扩展机器。
3.消息处理的状态是在customer端进行维护的，而不是server端维护的。当失效时能自动平衡。
4.支持在线和离线的场景。

Kafka：
Kafa分布式消息队列，默认将数据储存在磁盘，默认保存七天
producer:
消息的生产者，两种生产模式：1.轮询，2.基于key的hashCode取模。将同一个组消息的放到相同的分区partition中。
broker:
组成kafka集群的节点，由zookeeper来协调管理。broker负责消息的储存和读写，一个broker分组可以管理多个partition缓冲代理，kafka集群中的一台或者多态服务器统称为broker.
topic:
一类消息，消息的队列，topic是由partition组成的，多个partition是为了做并行处理，一个topic是由是由几个partition组成的。可以在创建topic的时候进行组成。
partiiton:
partition是组成topic单元，partition对应磁盘目录。一个partitiion中的消息是强有序的。每个partition是由对应的副本的。可以在创建的时候进行指定。每个partition最多是由一个组内的一个消费者进行消费的。partition是由broker管理的。每个partition是由一个broker来管理的。
Customer:
每个消费者都有自己的消费组，不同的消费组可以消费用一个partition中的数据，在消费数据的时候互不影响。同一个消费者组内的不同消费者消费同一个topic时，这个topic中的数据，只能被消费一次。
zookeeper:
协调broker,储存元数据：broker、topic、partition
在zookeeper0.8.2之前，zookeeper开可以储存消费者Offset

1.Kafka简述

Kafka架构是由producer（消息生产者）、consumer（消息消费者）、broker(kafka集群的server，负责处理消息读、写请求，存储消息，在kafka cluster这一层这里，其实里面是有很多个broker)、topic（消息队列/分类相当于队列，里面有生产者和消费者模型）、zookeeper(元数据信息存在zookeeper中，包括：存储消费偏移量，topic话题信息，partition信息) 这些部分组成。
kafka里面的消息是由topic来组织的，简单的我们可以想象为一个队列，一个队列就是一个topic，然后它把每个topic又分为很多个partition，这个是为了做并行的，在每个partition内部消息是强有序，相当于有序的队列，其中每个消息都有个序号offset，比如0到12，从前面读往后面写。一个partition对应一个broker，一个broker可以管多个partition，比如说，topic有6个partition，有两个broker，那每个broker就管3个partition。这个partition可以很简单想象为一个文件，当数据发过来的时候它就往这个partition上面append，追加就行，消息不经过内存缓冲，直接写入文件，kafka和很多消息系统不一样，很多消息系统是消费完了我就把它删掉，而kafka是根据时间策略删除，而不是消费完就删除，在kafka里面没有一个消费完这么个概念，只有过期这样一个概念。
producer自己决定往哪个partition里面去写，这里有一些的策略，譬如hash。consumer自己维护消费到哪个offset，每个consumer都有对应的group，group内是queue消费模型（各个consumer消费不同的partition，因此一个消息在group内只消费一次），group间是publish-subscribe消费模型，各个group各自独立消费，互不影响，因此一个消息在被每个group消费一次。
producer自己决定往哪个partition里面去写，这里有一些的策略，譬如hash。consumer自己维护消费到哪个offset，每个consumer都有对应的group，group内是queue消费模型（各个consumer消费不同的partition，因此一个消息在group内只消费一次），group间是publish-subscribe消费模型，各个group各自独立消费，互不影响，因此一个消息在被每个group消费一次。

2. kafka的特点

Ø 系统的特点：生产者消费者模型，FIFO
Partition内部是FIFO的，partition之间呢不是FIFO的，当然我们可以把topic设为一个partition，这样就是严格的FIFO。
Ø 高性能：单节点支持上千个客户端，百MB/s吞吐，接近网卡的极限
Ø 持久性：消息直接持久化在普通磁盘上且性能好
直接写到磁盘中去，就是直接append到磁盘里去，这样的好处是直接持久化，数据不会丢失，第二个好处是顺序写，然后消费数据也是顺序的读，所以持久化的同时还能保证顺序，比较好，因为磁盘顺序读比较好。
Ø 分布式：数据副本冗余、流量负载均衡、可扩展
分布式，数据副本，也就是同一份数据可以到不同的broker上面去，也就是当一份数据，磁盘坏掉的时候，数据不会丢失，比如3个副本，就是在3个机器磁盘都坏掉的情况下数据才会丢，在大量使用情况下看这样是非常好的，负载均衡，可扩展，在线扩展，不需要停服务。
Ø 很灵活：消息长时间持久化+Client维护消费状态
消费方式非常灵活，第一原因是消息持久化时间跨度比较长，一天或者一星期等，第二消费状态自己维护消费到哪个地方了可以自定义消费偏移量。

3. kafka的leader的均衡机制

当一个broker停止或者crash时，所有本来将它作为leader的分区将会把leader转移到其他broker上去，极端情况下，会导致同一个leader管理多个分区，导致负载不均衡，同时当这个broker重启时，如果这个broker不再是任何分区的leader,kafka的client也不会从这个broker来读取消息，从而导致资源的浪费。
kafka中有一个被称为优先副本（preferred replicas）的概念。如果一个分区有3个副本，且这3个副本的优先级别分别为0,1,2，根据优先副本的概念，0会作为leader 。当0节点的broker挂掉时，会启动1这个节点broker当做leader。当0节点的broker再次启动后，会自动恢复为此partition的leader。不会导致负载不均衡和资源浪费，这就是leader的均衡机制。

4.角色介绍

a.topic:特指kafka处理的消息源（feed of messages）的不同分类
b.partition:topic物理上的分组,一个topic可以分为多个partition,每个partition是一个有序队列，partition中的每条消息都会被分配一个有序的id(offset偏移量)。当失效时能自动平衡。
c.Message:消息，是通信的基本单位，没个producer可以向一个topic发布一些消息。
d.producers:消息和数据生产者，向kafka的一个topic发送消息的过程就叫做producers（生产）
e.Consumers:消息和数据的消费者，订阅topic并处理其发布的消息的过程就叫做Consumers.
f.Broker:缓存代理，kafka集群中的一台或多态服务器统称为broker.

3.kafka架构描述

a.kafka主要是以个显示的分布式架构，是由producer,broker(kafka),consumer组成，数据是从producer进行发送，发送给broker,broker承担着一个数据的缓存和分发的作用，broker将数据分发到注册到系统中的consumer。
b.broker将数据发送给consumer后，磁盘上的数据不会立即删除，根据用户在broker中的配置信息，保留一段时间后进行删除。比如log文件保留两天，两天后无论数据被消费都会自动删除。
c.负载均衡：producer将会和topic下的所有partition leader 保持socket连接，消息是由producer直接通过socket发送到broker,中间不会经过任何"路由层",事实上，消息被路由到哪个partition上，由producer客户端决定。比如可以采用random 、key-hash、轮询等，如果一个topic中有多个partitions那么在producer端实现"消息均衡分发"是必要的。其中partition leader的位置(post:port)注册在zookeeper中，producer client,已经注册了watch用来监听partition leader的变更事件。

注意：生产者producer会将生产的数据主动push推送到broker中
消费者检测到broker中有数据时，就会到broker中主动pull拉取数据。而不是broker主动将数据进行推送的。
集群启动：
启动zookeeper:zkServer.sh start
启动kafka:kafka-server-satrt.sh server.properties

二、使用场景

1、Messaging

对于一些常规的消息系统,kafka是个不错的选择;partitons/replication和容错,可以使kafka具有良好的扩展性和性能优势.不过到目前为止,我们应该很清楚认识到,kafka并没有提供JMS中的"事务性"“消息传输担保(消息确认机制)”"消息分组"等企业级特性;kafka只能使用作为"常规"的消息系统,在一定程度上,尚未确保消息的发送与接收绝对可靠(比如,消息重发,消息发送丢失等)

2、Websit activity tracking

kafka可以作为"网站活性跟踪"的最佳工具;可以将网页/用户操作等信息发送到kafka中.并实时监控,或者离线统计分析等

3、Log Aggregation

kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统.

三、Kafka面试题

1.kafka的设计？

kafka主要将消息一topic主题为单位进行数据的传输
将kafka消息发布的程序就是producer生产者
从kafka中消费topic并且主动拉取的是consumer消费者，集群会向kafka提供消息。

2.数据传输的事务定义的三种级别？

（1）最多一次：消息不会被重复发送，最多会发送一次，但是有可能一次都不传输。
（2）至少一次：消息不会被漏发，但是有可能被重复发送，至少发送一次。
（3）精准一次(Exactly once):不会造成漏传输，也不会造成重复发送，仅仅发送一次，这种级别是所期望的。

3.判断kafka活着的两个条件？

（1）节点必须可以维护和zookeeper之间的连接，zookeeper通过心跳机制，检查每个节点的连接。
（2）如果节点的的状态是follower,则他必须及时同步leader的写操作，延时不能太久。

4.producer是否直接将数据发送到broker的leader节点上？

producer直接将数据发送到broker的leader节点上，不需要每个节点之间进行分发。为了帮助producer做到这点，所有的kafka节点都可以及时的告知那些节点是活动的。topic目标的分区在哪，这样producer可以直接将消息发送到指定的partition分区了。

5、kafka中的 zookeeper 起到什么作用，可以不用zookeeper么？

zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖，
但是broker依然依赖于ZK，zookeeper 在kafka中还用来选举controller 和 检测broker是否存活等等。

6.kafka follower如何与leader同步数据

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

7.复制备份

kafka将每个partition数据复制到多个server上,任何一个partition有一个leader和多个follower(可以没有);备份的个数可以通过broker配置文件来设定.leader处理所有的read-write请求,follower需要和leader保持同步.Follower和consumer一样,消费消息并保存在本地日志中;leader负责跟踪所有的follower状态,如果follower"落后"太多或者失效,leader将会把它从replicas同步列表中删除.当所有的follower都将一条消息保存成功,此消息才被认为是"committed",那么此时consumer才能消费它.即使只有一个replicas实例存活,仍然可以保证消息的正常发送和接收,只要zookeeper集群存活即可.(不同于其他分布式存储,比如hbase需要"多数派"存活才行)
当leader失效时,需在followers中选取出新的leader,可能此时follower落后于leader,因此需要选择一个"up-to-date"的follower.选择follower时需要兼顾一个问题,就是新leaderserver上所已经承载的partition leader的个数,如果一个server上有过多的partition leader,意味着此server将承受着更多的IO压力.在选举新leader,需要考虑到"负载均衡".

Flume+kafka+Storm

小二讲堂：https://blog.csdn.net/Mirror_w