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,需要考虑到"负载均衡".