vlambda博客
学习文章列表

Kafka是什么

用Kafka官方的话说：Apache Kafka® is a distributedstreaming platform. 即，Kafka是一个分布式流平台。这到底是什么意思呢？

首先，我们要了解流平台具有三个关键功能：

1.发布和订阅记录流，类似于消息队列或企业消息传递系统。

2.以容错的持久方式存储记录流。

3.处理记录流。

其次，Kafka到底能干嘛？它主要的作用是什么？官方文档中这样说：

Kafka is used for building real-time data pipelinesand streaming apps. It is horizontallyscalable, fault-tolerant, wickedfast, and runs in production in thousands of companies.

大致的意思就是，这是一个实时数据处理系统，可以横向扩展、高可靠，而且还变态快，已经被很多公司使用。

那么什么是实时数据处理系统呢？顾名思义，实时数据处理系统就是数据一旦产生，就要能快速进行处理的系统，也就是流处理系统。

对于实时数据处理，我们最常见的，就是消息中间件了，也叫MQ（Message Queue，消息队列），也有叫MessageBroker的。

这篇文章，我将从消息中间件的角度，带大家看看Kafka的内部结构，看看它是如何做到横向扩展、高可靠的同时，还能变态快的。

为什么需要消息中间件

消息中间件的作用主要有两点：

1.解耦消息的生产和消费。

2.缓冲。

下面我们从数据处理、性能提升方面逐步看看Kafka的具体工作原理：

消息队列

从上面的描述，我们可以看出，消息中间件之所以可以解耦消息的生产和消费，主要是它提供了一个存放消息的地方——生产者把消息放进来，消费者在从中取出消息进行处理。

那么这个存放消息的地方，应该采用什么数据结构呢？

在绝大多数情况下，我们都希望先发送进来的消息，可以先被处理（FIFO），这符合大多数的业务逻辑，少数情况下我们会给消息设置优先级。不管怎样，对于消息中间件来说，一个先进先出的队列，是非常合适的数据结构：

那么要怎样保证消息可以被顺序消费呢？

消费者过来获取消息时，每次都把index=0的数据返回过去，然后再删除index=0的那条数据？

很明显不行，因为订阅了这条消息的消费者数量，可能是0，也可能是1，还可能大于1。如果每次消费完就删除了，那么其他订阅了这条消息的消费者就获取不到这条消息了。

事实上，Kafka会对数据进行持久化存储（至于存放多长时间，这是可以配置的），消费者端会记录一个offset，表明该消费者当前消费到哪条数据，所以下次消费者想继续消费，只需从offset+1的位置继续消费就好了。

消费者甚至可以通过调整offset的值，重新消费以前的数据。

那么这就是Kafka了吗？不，这只是一条非常普通的消息队列，我们姑且叫它为Kafka一代吧。

这个Kafka一代用一条消息队列实现了消息中间件，这样的简单实现存在不少问题：

Topic鱼龙混杂。想象一下，一个只订阅了topic为“A”的消费者，却要在一条有ABCDEFG…等各种各样topic的队列里头去寻找topic为A的消息，这样性能岂不是很慢？

吞吐量低。我们把全部消息都放在一条队列了，请求一多，它肯定应付不过来。

由此就引申出了Kafka二代。

Partition分区

要解决Kafka一代的那两个问题，很简单——分布存储。

二代Kafka引入了Partition的概念，也就是采用多条队列，每条队列里面的消息都是相同的topic：

图片来源：LinkedIn.com

Partition的设计解决了上面提到的两个问题：

纯Topic队列。一个队列只有一种topic，消费者再也不用担心会碰到不是自己想要的topic的消息了。

提高吞吐量。不同topic的消息交给不同队列去存储，再也不用以一敌十了。

一个队列只有一种topic，但是一种topic的消息却可以根据自定义的key值，分散到多条队列中。也就是说，上图的p1和p2，可以都是同一种topic的队列。不过这是属于比较高级的应用了，以后有机会再和大家讨论。

Kafka二代足够完美了吗？当然不是，我们虽然通过Partition提升了性能，但是我们忽略了一个很重要的问题——高可用。

万一机器挂掉了怎么办？单点系统总是不可靠的。我们必须考虑备用节点和数据备份的问题。

Broker集群

很明显，为了解决高可用问题，我们需要集群。

Kafka对集群的支持也是非常友好的。在Kafka中，集群里的每个实例叫做Broker，就像这样：

图片来源：sookocheff.com

每个partition不再只有一个，而是有一个leader(红色)和多个replica(蓝色)，生产者根据消息的topic和key值，确定了消息要发往哪个partition之后（假设是p1），会找到partition对应的leader(也就是broker2里的p1)，然后将消息发给leader，leader负责消息的写入，并与其余的replica进行同步。

一旦某一个partition的leader挂掉了，那么只需提拔一个replica出来，让它成为leader就ok了，系统依旧可以正常运行。

通过Broker集群的设计，我们不仅解决了系统高可用的问题，还进一步提升了系统的吞吐量，因为replica同样可以为消费者提供数据查找的功能。

这篇文章只是带大家初步认识一下Kafka，很多细节并没有深入讨论，从一个演化的视角，带大家在Kafka的后花园里走马观花，逛了一圈。很多细节并没有深入讨论，只是一个引子，希望能起到抛砖引玉的作用。

参考引用列表：

http://kafka.apache.org/

https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

https://sookocheff.com/post/kafka/kafka-in-a-nutshell/

https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying