Kafka 几个实现细节

Kafka 几个实现细节

关于Kafka大方向上的介绍已经很多了,infoq上面不少不错的资源

http://www.oschina.net/translate/kafka-design?cmp&p=1#

http://www.infoq.com/cn/articles/kafka-analysis-part-1

http://www.infoq.com/cn/articles/kafka-analysis-part-2

http://www.infoq.com/cn/articles/kafka-analysis-part-3

http://www.infoq.com/cn/articles/kafka-analysis-part-4

主要想从几个细节出发简单写一下Kafka,也为自己做一些积累。

基本概念

下面的概念中有部分逻辑概念,部分实体概念。

Broker

物理概念,指服务于Kafka的一个node。

topic

MQ中的抽象概念,是一个消费标示。用于保证Producer以及Consumer能够通过该标示进行对接。可以理解为一种Naming方式。

partition

Topic的一个子概念,一个topic可具有多个partition,但Partition一定属于一个topic。

值得注意的是:

  • 在实现上都是以每个Partition为基本实现单元的。
  • 消费时,每个消费线程最多只能使用一个partition。
  • 一个topic中partition的数量,就是每个user group中消费该topic的最大并行度数量。

User group

为了便于实现MQ中的多播,重复消费等引入的概念。如果ConsumerA以及ConsumerB同在一个UserGroup,那么ConsumerA消费的数据ConsumerB就无法消费了。

即:所有usergroup中的consumer使用一套offset。

Offset

Offset专指Partition以及User Group而言,记录某个user group在某个partiton中当前已经消费到达的位置。

总结

Kafka使用了Topic以及Partition的概念。其中Partition隶属于Topic,即topic1可以具有多个partition。而Partition则是Consumer消费的基本单元,即topic1有几个partition,那么最多就可以有多少个consumer同时在一个User Group里消费这个topic。而Offset则是记录了UserGroup在每个partiton中的偏移值。

概念介绍:生产者,消费者,消费语义

  • 生产者

生产者直接向某topic的某partition发送数据。leader负责主备策略,写入数据,发送ack。

  • 消费者

消费者使用fetch的方式拉取数据。kafkaServer不直接负责每个consumer的当前消费到了哪里,所以需要client端和zk联合维护每个partition读到了哪里,即Offset。

所以这样看上去,kafkaServer在一定程度上更像是一个大部分为顺序读取的,基于文件的日志系统。

因为简单,所以稳定。
  • 消费语义

对比其他MQ的多播,等语义,Kafka看上去略显单薄,其主要通过User Group的概念实现消费语义。而UserGroup实际对应的就是Offset的更改策略。

User1,User2同属一个userGroup时,即表示二者共用一套Offset。因每个partition 的offset只能由一个线程维护,因此注定了每个UserGroup里只能有一个消费线程对一个partition进行消费。

同样,如果希望实现多播,那就User1和User2用两个userGroup。

Kafka实现细节1 :Server端的日志存储

Kafka因为采用顺序写+无状态的方式,将可靠性发挥到了极致,使得Kafka成为了一集消息缓存以及MQ于一身的利器。首先第一个问题是搞清楚:Kafka内部存储日志的方式。

我们知道Partition是Topic的实体,所以当Producer向某topic发送数据时,需要判定几个问题。

问题1:发到哪个partition,谁来定?

这种问题没有正确的答案,只有到底在牺牲谁的答案。

在目前0.8.2.1的Kafka中,是交由Producer来解决这个问题的,Producer中有个PartitionManager专门用于负责对每个Message分配partition,或者由使用者更改。

  • 优势

这样的优势在于Kafka Server不需要单独一个LoadBalancer来决定消息去哪里。而且Producer完全可以根据partition的id在ZK里寻找当前Leader,直接与Leader建立连接。

  • 劣势

是不是看到这里发现问题了?是的,如果某个Partition完全不可用,这些消息就无法发送了。使用更加简化的模型带来的代价是牺牲了一部分可用性。

当然再有了副本策略之后,使一个partition变得不可用是一件很困难的事情。

问题2:日志如何存储?

在这里,我们先讨论单点存储结构

Kafka Producer在确定partition leader之后开始与其所在的broker通信。为了使用磁盘的顺序写,即使用Log Structure storage。

为查找方便,Kafka同样建立了基本的索引结构。想想查询需求,有什么查询需求?大部分消息都会被顺序读取,当然也会存在少量的随机读取消息(比如处理的时候这条消息处理失败,需要重新处理)。所以索引在这里的意义仅为简单支持少量随机查询。

所以在索引的实现上,基本上就是为了支持针对某个Offset进行二分查找而存在的索引。

所以在文件存储上,每个消息被写成了两部分,一部分是『消息实体』,一部分是『消息索引』。消息实体格式如下:

On-disk format of a message

message length : 4 bytes (value: 1+4+n) 
"magic" value  : 1 byte
crc            : 4 bytes
payload        : n bytes

消息索引格式如下,官网那张图是错的,你们就别看那个了。

Segement file主要用来搜索offset的时候使用,如果是顺序消费,只需要持续读文件内部内容即可。

kafka_message

问题3:如何实现日志副本&&副本策略&&同步方式

副本问题的提出

日志副本策略是可靠性的核心问题之一,其实现方式也是多种多样的。包括无主模型,通过paxos之类的协议保证消息顺序,但更简单直接的方式是使用主从结构,主决定顺序,从拷贝主的信息。

如果主不挂,从节点没有存在的意义。但主挂了时,我们需要从备份节点中选出一个主。与此同时,更重要的是:保证一致性。在这里一致性是指:

主ack了的消息,kafka切换主之后,依然可被消费。
主没有ack的消息,kafka切换主之后,依然没有被存储。

因此这里产生了一个trade off:Leader应该什么时候ack呢?

这个问题简直是分布式环境里永恒(最坑爹)的主题之一了。其引申出的本质问题是,你到底要什么?

  • 要可靠性

当然可以,leader收到消息之后,等follower 返回ok了ack,慢死。但好处是,主挂了,哪个follower都可以做主,大家数据都一样嘛

  • 要速度

当然可以,leader收到消息写入本地就ack,然后再发给follower。问题也很显而易见,最坏得情况下,有个消息leader返回ack了,但follower因为各种原因没有写入,主挂了,丢数据了。

副本问题的集中解决方式

我们来集中讨论一下几种实现方式从而明白我们需要哪种策略吧。

  • 方式1: Quorum及类似协议

Quorum直译为决议团,即通过写多份,读多次的方式保证单个值是最新值,通俗理解为抽屉原理。

抽屉原理的适用范围很广,Dynamo在某种程度上也是使用了抽屉原理

在Dynamo的使用中,设共有N副本,每次写保证W个副本ack,每次读的时候读R个副本并从中取最新值,则只要保证W+R>N,那么就一定能保证读到最新数据。但那是在Key-Value的存储中使用的,没有数据顺序问题。在Kafka里,我们还需要有一个数据顺序问题。

Kafka中会持续写入数据,主接收数据后,向所有follower发送数据。当然,因为网络问题,每次成功ack的follower可能不完全相同,但可以当有W个节点ack的时候就进行主的ack。

这样,在主挂的时候,需要R个点共同选主,因为W+R>N,所以对于每条消息,R个点里一定是有一个点是写成功的。因此通过这R个点,一定可以拼凑出来一份齐全的,和Leader一样的数据。把这些数据写入单点,即可实现选新主。

当然,这里隐含了一个协议,就是leader每次向follower发送消息的时候是附带了消息编号的,且消息编号自增。里面还有很多实现细节(such as precisely defined what makes a log more complete, ensuring log consistency during leader failure or changing the set of servers in the replica set),因为Kafka没用这种方式实现,所以也就不再复述。

最经典的情况就是R=f+1,W=f+1,N=2f+1

ISR1

这就是一个典型情况,有leader 以及F1F4四个follower,每次写入写入leader的同时,保证至少写入f=2额外的点。所以当leader写完所有信息后如果挂掉,从F1F4里任选三个都可以组合出所有的完整的消息。

  1. 优势:
    这个方式的优势是,在写入过程中,跳过了部分反应慢的节点。因为要求W+R>N,所以选主速度应该也还可以。

  2. 劣势:性能较差,拥有2f+1的机器只能支持最多f台机器挂掉。假设我希望支持2台机器挂掉,我就需要5台机器。使用5台机器的存储,但只能存储一台机器的容量,以及一台机器的吞吐,这显然不是一个划算的买卖。

这也就是为什么只有在保证主节点的关键信息时才会使用类似Quorom的实现方式,而对于大量的数据存储并不是使用这种方式。(Dynamo应该算个特例吧)

当然还有一些其他相对类似的实现,比如 ZooKeeper的 Zab, Raft, 以及 Viewstamped Replication。Kafka等人认为最接近他们是实现的是微软亚研院的一篇论文: PacificA(周立东老师的论文....当年就是他电面的我然后直接把我送走了....)

  • Kafka自己的ISR机制

Kafka自己使用了一种称之为In-Sync Replicas(ISR)的机制。

我们回想一下刚才Quorum实现里的问题,支持挂2台的环境需要5台机器,主要是比例太高。之前使用Quorum主要是对每个消息都做f+1的备份,即

以单个消息为进行备份的基本单位,进行可靠性保障

在这种情况下,为了保证每个消息的可靠,所以我们只有一个选择,那就是写够f+1份数据。因为只有这样,才能保障一个f+1份的读可以获取全部数据。其主要问题在于每次ack的机器不一样。所以,找f+1份才会保险。

但是想想,使用kafka是为了高吞吐,每个机器上数据不全显然需要多点读,但我们可不可以让节点在ack之后,自己慢慢补上自己缺失的数据呢?这样读数据的时候就可以读单点了啊!

事实上,在Quorum默认的实现方式里,节点是不再进行数据交互的。也对,输入数据量那么大,每个消息持有者都不相同,进行数据交互补充自己不含有的数据可能会带来很大的网络开销,而且存储同样是问题。难道也要学dynamo用gossip协议?想想就头疼,能不能把问题简化一下呢?

不适合直接用gossip协议的原因是消息数量太大,但不用Gossip协议必然导致多份读,这对于高吞吐的kafka是不能容忍的。是不是可以换一种思路呢?比如:

以一段时间而非以一个消息为基本单位,进行可靠性保障

个人认为这是ISR机制最核心的思想。

这同样是基于一个节点故障模型的假设:

对大多数系统而言,其正常工作状态与异常工作状态成时间段分布。

所以,如果存在一种方式,能够按照时间段进行ack,再进行gossip就会变得简单很多。因为不会有多少个gossip消息传来传去。

下面介绍ISR机制

  • 不是

问题6: Kafka的主挂掉的情况讨论

Kafka实现细节2:新玩法.Log Compaction

Kafka实现细节3:消费怎么保证不丢数据?

问题1: Offset怎么存?

问题2: Consumer如何做loadbalance?

问题3: Consumer的关闭异常,会不会存在Offset异常导致多消费或者少消费?

posted @ 2015-09-24 20:52  RobinMeng  阅读(32449)  评论(3编辑  收藏  举报