MQTT 与 Kafka 是完全不同的两个东西， MQTT 是协议，是一个技术标准，由 OASIS 技术委员会的成员（其成员多数为 IBM 和微软的顶级工程师）制订。而 Kafka 是已经实现的开源流处理平台，最早由 LinkedIn 开发，于 2011 年开源后交给 Apache Incubator孵化后成为了 Apache 软件基金会的顶级项目。

两者之前唯一存在的联系恐怕就是它们都和发布/订阅范式有关了吧。MQTT 是基于发布/订阅范式的消息协议，而Apache Kafka 的生产、消费的流程也是属于发布/订阅范式的。那么如果我们基于 MQTT 协议去实现一个消息 broker，是否这个MQTT broker是否能和Kafka作用等价呢？ 答案当然是否定的！

Kafka 虽然也是基于发布订阅范式的消息系统，但它同时也被称为“分布式提交日志”或者“分布式流平台”，它的最主要的作用还是实现分布式持久化保存数据的目的。Kafka 的数据单元就是消息，可以把它当作数据库里的一行“数据”或者一条“记录”来理解，Kafka 通过主题来进行分类，kafka 的生产者发布消息到某一特定主题上，由消费者去消费特定主题的消息，其实生产者和消费者就可以理解成发布者和订阅者，主题就好比数据库中的表，每个主题包含多个分区，分区可以分布在不同的服务器上，也就是说通过这种方式来实现分布式数据的存储和读取， kafka 分布式的架构利于读写系统的扩展和维护（比如说通过备份服务器来实现冗灾备份，通过架构多个服务器节点来实现性能的提升），在很多有大数据分析需求的大型企业，都会用到Kafka 去做数据流处理的平台。

而MQTT 最开始就是为物联网设备的网络接入而设计的，物联网设备大多都是性能低下，功耗较低的计算机设备，而且网络连接的质量也是不可靠的，所以在设计协议的时候最需要考虑的几个重点是：

1. 协议要足够轻量，方便嵌入式设备去快速地解析和响应。
2. 具备足够的灵活性，使其足以为 IoT 设备和服务的多样化提供支持。
3. 应该设计为异步消息协议而非同步协议，这么做是因为大多数 IoT 设备的网络延迟很可能非常不稳定，若使用同步消息协议，IoT 设备需要等待服务器的响应，对于为大量的 IoT 设备提供服务这一情景，显然是非常不现实的。
4. 必须是双向通信，服务器和客户端应该可以互相发送消息。

MQTT 协议完美地解决了上述几点要求，并且最新版的 MQTT v5.0 协议做了很多优化，使其协议相比过去的 v3.1.1 版本具备更强大的灵活性以及对带宽的更少占用。

要说基于 MQTT 协议的消息 broker 和 Kafka 的区别的话，EMQ君认为还是在于它们的侧重点不同，Kafka 的侧重点在于数据的存储和读取，针对实时性比较高的流式数据处理场景；而 MQTT broker 的侧重点在于客户端和服务器的通信。

MQTT broker 与 Kafka 所采用的消息交换范式是如此相近，将其两者结合起来使用显然是一个非常不错的主意，事实上，很多 MQTT broker，诸如EMQ X已经实现了 MQTT broker 与 Kafka的桥接。MQTT broker 用来快速的对大量物联网设备发来的消息做接收处理响应，而Kafka 对这些大量的数据做采集存储，交给数据分析人员来分析处理消息，这一流程或许会成为未来物联网云平台的一大通用范式。

一下图标对比：

1.名称

MQTT

kafka

2.历史

IBM推出的一种针对移动终端设备的发布/预订协议。

LinkedIn公司开发的分布式发布-订阅消息系统。后来，成为Apache项目的一部分。

3.原理

基于二进制消息    发布/订阅编程模式的消息协议。

发布/订阅（Publish/Subscribe）模式

4.应用场景

物联网：大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议。                                   

•遥感数据

•汽车

•智能家居

•智慧城市

•医疗医护

在线应用（消息）和离线应用（数据文件，日志）               1.消息系统（吞吐量，内置的分区，冗余及容错性）                                                       2.行为跟踪（户浏览页面、搜索及其他行为）

3.日志收集（抽象成一个个日志或事件的消息流）

消息系统

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务。kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性。                                                        

5.消息消费(push/pull)

6.角色对比

创建主题(一类消息)

5.主题（Topic）

主题筛选器：通过主题对消息进行分类的                             层级主题：通过反斜杠表示多个层级关系；                                 通过通配符进行过滤：+可以过滤一个层级，而*只能出现在主题最后表示过滤任意级别的层级。举个例子：

• building-b/floor-5：代表B楼5层的设备。

• +/floor-5：代表任何一个楼的5层的设备。

• building-b/*：代表B楼所有的设备。

注意，MQTT允许使用通配符订阅主题，但是并不允许使用通配符广播。

每个topic划分为多个partition。                                            每个partition在存储层面是append log文件。

6.服务质量（Quality of Service，QoS）

为了满足不同的场景，MQTT支持三种不同级别的服务质量为不同场景提供消息可靠性：

•级别0：尽力而为。消息可能会丢，但绝不会重复传输

•级别1：消息绝不会丢，但可能会重复传输

•级别2：恰好一次。每条消息肯定会被传输一次且仅传输一次

级别1，Kafka利用这一特点减少确认从而大大提高了并发。

7.存储方式

内存、redis、mongdb等

磁盘 

 将消息持久化到磁盘，因此可用于批量消费。因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的次数.

8.设计原则（为什么MQTT用来做物联网消息传输、Kafka用来做日志收集）

1.协议精简，不添加可有可无的功能。

2.发布/订阅（Pub/Sub）模式，方便消息在传感器之间传递。

3.允许用户动态创建主题，零运维成本。

4.把传输量降到最低以提高传输效率。（固定长度的头部是2字节），协议交换最小化，以降低网络流量。

5.把低带宽、高延迟、不稳定的网络等因素考虑在内。

6.支持连续的会话控制。

7.理解客户端计算能力可能很低。

8.提供服务质量管理。

9.假设数据不可知，不强求传输数据的类型与格式，保持灵活性。

吞吐量

1.数据磁盘持久化：消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能

2.zero-copy：减少IO操作步骤

3.数据批量发送

4.数据压缩

5.Topic划分为多个partition，提高parallelism

负载均衡

1.生产者发送消息到pattition

2.存在多个partiiton，每个partition有自己的replica，每个replica分布在不同的Broker节点上

3.多个partition需要选取出lead partition，lead partition负责读写，并由zookeeper负责fail over

4.通过zookeeper管理broker与consumer的动态加入与离开                                                                                        

拉取系统

kafka broker会持久化数据，consumer采取pull的方式消费数据：

1.consumer根据消费能力自主控制消息拉取速度

2.consumer根据自身情况自主选择消费模式，例如批量，重复消费，从尾端开始消费等

可扩展性

当需要增加broker结点时，新增的broker会向zookeeper注册，而producer及consumer会根据注册在zookeeper上的watcher感知这些变化，并及时作出调整。

9.消息类型

1. CONNECT：客户端连接到MQTT代理

2. CONNACK：连接确认

3. PUBLISH：新发布消息

4. PUBACK：新发布消息确认，是QoS 1给PUBLISH消息的回复

5. PUBREC：QoS 2消息流的第一部分，表示消息发布已记录

6. PUBREL：QoS 2消息流的第二部分，表示消息发布已释放

7. PUBCOMP：QoS 2消息流的第三部分，表示消息发布完成

8. SUBSCRIBE：客户端订阅某个主题

9. SUBACK：对于SUBSCRIBE消息的确认

10. UNSUBSCRIBE：客户端终止订阅的消息

11. UNSUBACK：对于UNSUBSCRIBE消息的确认

12. PINGREQ：心跳

13. PINGRESP：确认心跳

14. DISCONNECT：客户端终止连接前优雅地通知MQTT代理

／

10.服务端实现

数十个 MQTT 服务器端程序                                    Mosquitto(C/C++)

emqttd(Erlang/OTP)

Moquette

HiveMQ(Java)

Scala  官方实现的系统

11.总结

两者都是从传统的Pub/Sub消息系统演化出来的，但是进化的方向不一样 。                                                                             Kafka是为了数据集成的场景，通过分布式架构提供了海量消息处理、高容错的方式存储海量数据流、保证数据流的顺序等特性。

MQTT是为了物联网场景而优化，提供多个QoS选项（exact once、at least once、at most once），还有层级主题、遗嘱等特性。

12.有意思的东西

Mqtt to Apache Kafka Connect

https://github.com/evokly/kafka-connect-mqtt

Mosca

Kafka MQTT Bridge Example

https://github.com/mcollina/mosca/tree/master/examples/kafka

Mosca supports different backends such as redis and mongodb, but also kafka. A Kafka MQTT Bridge application is included in the Mosca examples.