1 什么是消息队列
（1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）
点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。
（2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者）
发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。
2 为什么需要消息队列
1）解耦：允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2）冗余：消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
3）扩展性：因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。
4）灵活性 & 峰值处理能力：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5）可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
6）顺序保证：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka保证一个Partition内的消息的有序性）
7）缓冲：有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
8）异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
3 什么是kafka
Kafka是一种高吞吐量的分布式发布订阅消息系统【也是一个分布式的流处理平台】，最初由 LinkedIn 公司开发，使用 Scala 语言编写，目前是 Apache 的开源项目。用户通过Kafka系统可以发布大量的消息，同时也能实时订阅消费消息，Kafka可以同时满足在线实时处理和批量离线处理。
在大数据生态系统中，可以把Kafka作为数据交换枢纽，不同类型的分布式系统（关系数据库、NoSQL数据库、流处理系统、批处理系统等），可以统一接入到Kafka，实现和Hadoop各个组件之间的不同类型数据的实时高效交换。
在流式计算中，Kafka 一般用来缓存数据，Storm 通过消费 Kafka 的数据进行计算。Kafka 是一个分布式消息队列。Kafka 对消息保存时根据 Topic 进行归类，发送消息者称为 Producer，消息接受者称为Consumer，此外 Kafka 集群有多个 Kafka 实例组成，每个实例 Server 称为 Broker。无论是 Kafka 集群，还是 Consumer 都依赖于 Zookeeper 保存一些 Meta 信息，来保证系统可用性。
它具有以下特点：
- 支持消息的发布和订阅，类似于 RabbtMQ、ActiveMQ 等消息队列；
- 支持数据实时处理；
- 能保证消息的可靠性投递；
- 支持消息的持久化存储，并通过多副本分布式的存储方案来保证消息的容错；
- 高吞吐率，单 Broker 可以轻松处理数千个分区以及每秒百万级的消息量。
4 kafka核心概念
4.1 架构详情
| 名词 | 解释 |
| -------------- | :----------------------------------------------------------- |
| Broker | Kafka集群包含一个或多个服务器，这种服务器被称为broker |
| Topic | 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个Broker上，但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处） |
| Partition | Partition是物理上的概念，每个Topic包含一个或多个Partition |
| Offset| 消息在日志中的位置，可以理解是消息在 Partition 上的偏移量，也是代表该消息的唯一序号 |
| Producer | 负责发布消息到Kafka broker |
| Consumer | 消息消费者，向Kafka broker读取消息的客户端 |
| Consumer Group | 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group） |
| Zookeeper | 保存着集群 Broker、Topic、Partition 等 Meta 数据；负责 Broker 故障发现，Partition Leader 选举，负载均衡等功能 |
4.2 消息和批【Messages And Batches】
Kafka 的基本数据单元被称为 Message(消息)，为减少网络开销，提高效率，多个消息会被放入同一批次 (Batch) 中后再写入。
4.3 主题和分区【Topics And Partitions】
Kafka 的消息通过 Topics(主题) 进行分类，一个主题可以被分为若干个 Partitions(分区)，一个分区就是一个提交日志 (Commit Log)。消息以追加的方式写入分区，然后以先入先出的顺序读取。Kafka 通过分区来实现数据的冗余和伸缩性，分区可以分布在不同的服务器上，这意味着一个 Topic 可以横跨多个服务器，以提供比单个服务器更强大的性能。
由于一个 Topic 包含多个分区，因此无法在整个 Topic 范围内保证消息的顺序性，但可以保证消息在单个分区内的顺序性。
4.4 生产者和消费者【Producers And Consumers】
生产者
生产者负责创建消息。一般情况下，生产者在把消息均衡地分布到在主题的所有分区上，而并不关心消息会被写到哪个分区。如果我们想要把消息写到指定的分区，可以通过自定义分区器来实现。
消费者
消费者是消费者群组的一部分，消费者负责消费消息。消费者可以订阅一个或者多个主题，并按照消息生成的顺序来读取它们。消费者通过检查消息的偏移量 (Offset) 来区分读取过的消息。偏移量是一个不断递增的数值，在创建消息时，Kafka 会把它添加到其中，在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的偏移量保存在 Zookeeper 或 Kafka 上，如果消费者关闭或者重启，它还可以重新获取该偏移量，以保证读取状态不会丢失。
一个分区只能被同一个消费者群组里面的一个消费者读取，但可以被不同消费者群组中所组成的多个消费者共同读取。多个消费者群组中消费者共同读取同一个主题时，彼此之间互不影响。
4.5 服务器和集群【Brokers And Clusters】
一个独立的 Kafka 服务器被称为 Brokern.经纪人。Broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。Broker 为消费者提供服务，对读取分区的请求做出响应，返回已经提交到磁盘的消息。
Broker 是集群 (Cluster) 的组成部分。每一个集群都会选举出一个 Broker 作为集群控制器(Controller)，集群控制器负责管理工作，包括将分区分配给 Broker 和监控 Broker。
在集群中，一个分区 (Partition) 从属一个 Broker，该 Broker 被称为分区的首领 (Leader)。一个分区可以分配给多个 Brokers，这个时候会发生分区复制。这种复制机制为分区提供了消息冗余，如果有一个Broker 失效，其他 Broker 可以接管领导权。
