Kafka消息队列学习进阶(三)-原理概念介绍篇

Kafka原理

这篇主要是为了Kafka调优而进行讲解的,我所认为的只有了解了部分原理,才知道怎么去调优。我将从下面几个点进行讲解:

CAP理论。

Replica概念及Data Replication要解决的问题。

Kafka如何使用Zookeeper及Kafka Leader Election。

Kafka Consumer及 Producer。

CAP理论将不再详细介绍,之前的Zookeeper已经介绍了;后面的三点将详细的介绍。

CAP理论

CAP理论,包含三个点,一致性;可用性;分区容忍性,下面分别这三个点的介绍:

Consistency(一致性)

通过某个节点的写操作结果对后面通过其它节点的读操作可见。

如果更新数据后,并发访问情况下可立即感知该更新,称为强一致性。

如果允许之后部分或者全部感知不到该更新,称为弱一致性。

若在之后的一段时间(通常该时间不固定)后,一定可以感知该更新,称为最终一致性。

Availability(可用性)

任何一个没有发生故障的节点必须在有限的时间内返回合理的结果。

Partition tolerance(分区容忍性)

部分节点宕机或者无法与其它节点通信时,各分区间还可保持分布式系统的功能。

对于上面的三个又可以分别进行组合,CA/CP/AP。其中考虑到分布式系统的相关知识点,我们将会放弃CA,只考虑CP和AP两种情况。

Replica

Kafka的replica指的是消息的备份,为了保证Kafka的高可用(当leader节点挂了之后,Kafka依然能提供服务)kafka提供了备份的功能。这个备份是针对partition的。可以通过default.replication.factor对replica的数目进行配置,默认值为1,表示不对topic进行备份。如果配置为2,表示除了leader节点,对于topic里的每一个partition,都会有一个额外的备份。特点如下:

1.当某个Topic的replication-factor为N且N大于1时,每个Partition都会有N个副本(Replica).

2.Replica的个数小于等于Broker数,即对每个Partition而言每个Broker上只会有一个Replica,因此可用Broker ID表示Replica.

3.所有Partition的所有Replica默认情况会均匀分布到所有Broker上.

replica分配算法所解决的问题:kafka通过replica分配的算法保证了当某台机器挂掉,甚至某个机房挂掉,依然有备份可用。

Data Replication要解决的问题

所需要解决问题,如下四点:

如何Propagate消息。

何时Commit。

如何处理Replica恢复。

如何处理Replica全部宕机。

我将详细的介绍第三点,另外三点将提供一个地址提供读者进行详细研究和了解,地址如下:http://www.infoq.com/cn/articles/kafka-analysis-part-2/。

第三点,何时提交,分为ISR和Commit策略:

1.ISR

a.Leader会维护一个与其基本保持同步的Replica列表,该列表称为ISR(in-sync Replica)。

b.如果一个Follower比Leader落后太多,或者超过一定时间未发起数据复制请求,则Leader将其从ISR中移除。

c.当ISR中所有Replica都向Leader发送ACK时,Leader即Commit。

2.Commit策略

a.Server配置

replica.lag.time.max.ms=10000

replica.lag.max.messages=4000

b.Topic配置

min.insync.replicas=1

c.Producer配置

request.required.acks=0

Kafka如何使用Zookeeper

Kafka如何使用Zookeeper,主要有下面三点:

配置管理。

Leader Election。

服务发现。

代码实现我们将不再进行讲解,因为我也没有研究这块的源码,讲这个主要是为了优化。从优化的角度来说,我们可以自己手动搭建ZK集群,同时提高Kafka连接ZK的时长等方面入手。

Kafka Consumer及 Producer

首先我们将分别介绍生成者和消费者的概念,然后再介绍一个重点概念消费分组(Consumer Group)。

Producer:Producer通过主动Push的方式将消息发布到Broker。

Consumer:Consumer通过Pull从Broker消费数据:

1.Push

优势:延时低。

劣势:可能造成Consumer来不及处理消息;网络拥塞。

2.Pull

优势:Consumer按实际处理能力获取相应量的数据;Broker实现简单。

劣势:如果处理不好,实时性相对不足(Kafka使用long polling)。

消费分组(Consumer Group),特点如下:

High Level Consumer将从某个Partition读取的最后一条消息的offset存于Zookeeper中(从0.8.2开始同时支持将offset存于Zookeeper中和专用的Kafka Topic中)。

这个offset基于客户程序提供给Kafka的名字来保存,这个名字被称为Consumer Group

Consumer Group是整个Kafka集群全局唯一的,而非针对某个Topic的。

每个High Level Consumer实例都属于一个ConsumerGroup,若不指定则属于默认的Group。

需要注意的地方:

消息被消费后,并不会被删除,只是相应的offset加一。

对于每条消息,在同一个Consumer Group里只会被一个Consumer消费。

不同Consumer Group可消费同一条消息,解释了为啥我们会在代码中加个主题。

欢迎关注和转发,下一篇我们将正式介绍项目中优化配置实战。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181008G0C0YU00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券