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可消费同一条消息，解释了为啥我们会在代码中加个主题。

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