一文搞懂Kafka：女朋友看了也懂的Kafka

Kafka

1.为什么需要Kafka

举个例子：麦当劳点餐时，当我们选择外带的时候，餐厅制作好餐之后会放在一个取餐台，而且取餐台是按照不同的取餐码尾号分开放置的，按照餐品的产出顺序进行放置的。这时候我们可以在我们空闲的时候去取餐，而餐厅也不用等待我们拿完餐再生产。而这个取餐台就像一个消息队列。我们现在想想如果没有这个取餐台会发生什么？餐厅不断需要顾客及时取走，不然会严重影响到餐厅的出餐和订单处理。那消费者也要关注取餐的信息，自己的时间安排自由度就下降了。so，取餐台这个中间缓冲的对象就可以接触消费者和餐厅的强绑定关系，让餐厅和消费者都可以自由化做各自的事情。

Kafka所扮演的角色就是类似当前取餐台的功能，当然起作用不仅仅是缓冲，在接下来的内容中一起揭开kafka的面纱，一窥其工作机理和设计思想。

2.初识kafka

我们先来看看Kafka是怎么定义的？

kafka是一个分布式的基于发布/订阅模式的消息队列。

那啥是消息队列啊。如我们开篇讲到的那个取餐台就是一个消息队列。就是在消息传输过程中保存消息的容器。其本质就是：

消息发送者（我们称之为生产者，多形象）——>MQ（message queue消息队列，消息保存的容器）——>消息接受者（消息的消费者）

消息队列就是可以接受生产者发送的消息并保存起来，队列Queue，按照消息接受的顺序存储，然后等待消费者进行消费消息。消息队列的作用就是保存消息并转发消息。

消息队列的好处：

1）解耦

允许我们独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2）可恢复性

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

3）缓冲

有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。

4）灵活性 & 峰值处理能力 （削峰）

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。比如：618，双十一等活动，00:00 大量的手速点击访问，如果没有消息队列作为缓冲，所有请求都打到Redis，mysql等服务器，他们也扛不住啊。

5）异步通信

很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

消息队列的两种模式

（1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。

消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

2）发布/订阅模式 （一对多，消费者消费数据之后不会清除消息）

消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

发布-订阅（Publish/Subscribe）模式（又被称为观察者模式，属于行为型模式的一种，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使他们能够自动更新自己。

我们看看传统的MQ有什么问题？

没有消息队列我们怎么做？

假设现在我们的应用程序需要往别处发送监控信息，可以直接在应用程序和另一个可以在仪表盘上显示度量指标的应用程序之间建立连接 然后通过这个连接推送度量指标，

我们可以这样做：

这是刚接触监控系统时简单问题的应对方案。过了不久，你需要分析更长时间片段的度量指标，而此时的仪表盘程序满足不了需求，于是，你启动了一个新的服务来接收度盘指标。该服务把度量指标保存起来，然后进行分析。与此同时，你修改了原来的应用程序， 把度量指标同时发送到两个仪表盘系统上。

现在，你又多了3个可以生成度量指标 应用 程序，它们都与这两个服务直接相连。而你的同事认为最好可以对这些服务进行轮询以便 获得告警功能，于是你为每一个应用程序增加了一个服务器，用于提供度量指标。再过一阵子，有更多的应用程序出于各自的目的，都从这些服务器获取度主指标。这时的架构看起来就像下图所示一样，节点间的连接一团糟。

传统MQ怎么做？

我们创建一个基于发布订阅的消息队列， 用于接收来自其他应用程序的度量指标，井为其他系统提供了一个查询服务器。

这时候一切都看起来这么清爽和简单，但是当我们和度量指标进行了一轮“艰苦奋战”之后，其他同事也要和各自的任务进行battle。另一个同事也正在跟日志消息奋战。还有另一个同事正在跟踪网站用户的行为，为负责机器学习开发的同事提供信息 ，同时为管理团队生成报告。你和同事们使用相同的方式创建这些系统，解辑信息的发布者和订阅者。然后发现世界好像又不美好了？看图：

由于不同的业务任务，我们产生了多个消息队列进行各自业务的处理，但是这里有很多重复的地方。而且由于不同的业务模块，开发人员需要为各自的业务指标任务维护一套内容，而且之后或许还有其他的业务需要构建新的消息队列进行处理，资源浪费且每天维护这些内容，出现BUG的排查等等都会带来极大的不便性。但是又因为传统消息队列中的一个消息只能被消费一次，这时候我们就想，如果消息队列可以对于不同的业务的消费者看做不同的消费者，他们都可以消费消息队列中的消息就可以共用这些消息系统了。岂不是美滋滋，即便是后边需要增加业务，也不用独立的使用新的消息队列，世界又变得美好万分。

这时候，Kafka就”闪亮登场“了

Kafka的数据按照一定的顺序持久化保存，可以按需读取，通过对于不同的群组的消费者重新数据的消费状态实现多消费者共同消费消息等。具体的数据一致性保证以及生产者消费者写入和读取数据是怎么进行的，在后边的内容会与展开讲述。

3.Kafka基本架构

前备知识：

1.消息和批次

Kafka 的数据单元被称为消息。消息由字节数组组成，所以对于Kafka来说，消息里的数据没有特别的格式或含义。消息可以有一个可选的元数据，也就是键。键也是一个字节数组，与消息一样，对于Kafka来说也没有特殊的含义。消息以一种可控的方式写入不同的分区时，会用到键。最简单的例子就是为键生成一个一致性散列值，然后使用散列值对主题分区数进行取模，为消息选取分区。
$$patitionnum=mod(hash(key),partitions)$$
这样可以保证具有相同键的消息总是被写到相同的分区上。为了提高效率，消息被分批次写入 Kafka 。批次就是一组消息，这些消息属于同一个主题和分区。如果每 个消息都单独在网络传输，会导致大量的网络开销，把消息分成批次传输可以减少网络开销。不过，这要在时间延迟和吞吐量之间作出权衡：批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储能力，但要做更多的计算处理。

2.消息模式

对于Kafka而言，消息的底层是一组字节数组，是我们难以辨识的内容。为了更好的理解这些消息，就有开发者提出用额外的一种结构来定义消息内容。比如常见的JSON和XML。这些结构不仅易用，且可读性好。Kafka一般采用Avro。Avro提供了一种紧凑的序列化格式，其模式和消息体是分开的。另外Avro也是由Doug Cutting创建的哦。因为Avro的一些特性，很适合Kafka这样的消息队列。消除了消息读写操作之间的耦合性。

如果读写