消息队列和Kafka的基本介绍
一、什么是消息队列
消息队列，英文名：Message Queue，经常缩写为MQ。从字面上来理解，消息队列是一种用来存储消息的队列 。来看一下下面的代码
上述代码，创建了一个队列，先往队列中添加了一个消息，然后又从队列中取出了一个消息。这说明了队列是可以用来存取消息的
总结: 消息队列指的就是将数据放置到一个队列中, 从队列一端进入, 然后从另一端流出的过程
二、消息队列的应用场景
消息队列在实际应用中包括如下四个场景：
1、应用耦合：
多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
2、异步处理：
多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
3、 限流削峰：
广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
4、消息驱动的系统：
系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理
下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用
异步处理
具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。
1) 串行方式: 新注册信息生成后 , 先发送注册邮件, 再发送验证短信
注意 : 在这种方式下，需要最终发送验证短信后再返回给客户端
2) 并行处理：新注册信息写入后，由发短信和发邮件并行处理
注意: 在这种方式下，发短信和发邮件 需处理完成后再返回给客户端。
假设以上三个子系统处理的时间均为 50ms ，且不考虑网络延迟，则总的处理时间：
串行： 50 50 50=150ms
并行： 50 50 = 100ms
如果引入消息队列 , 在来看整体的执行效率 :
在写入消息队列后立即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间本身是可以很快的，基本可以忽略不计，因此总的处理时间相比串行提高了2倍，相比并行提高了一倍；
应用耦合
具体场景：
用户使用 QQ 相册上传一张图片，人脸识别系统会对该图片进行人脸识别，一般的做法是，服务器接收到图片后，图片上传系统立即调用人脸识别系统，调用完成后再返回成功，如下图所示: 如果引入消息队列 , 在来看整体的执行效率
该方法有如下缺点:
1) 人脸识别系统被调失败，导致图片上传失败；
2) 延迟高，需要人脸识别系统处理完成后，再返回给客户端，即使用户并不需要立即知道结果；
3) 图片上传系统与人脸识别系统之间互相调用，需要做耦合；
若使用消息队列:
此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。
事实上，由于用户并不需要立即知道人脸识别结果，人脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时 间，对队列中的图片信息进行处理。
限流削峰
具体场景：
购物网站开展秒杀活动，一般由于瞬时访问量过大，服务器接收过大，会导致流量暴增，相关系统无法处理请求甚至崩溃。而加入消息队列后，系统可以从消息队列中取数据，相当于消息队列做了一次缓冲。
该方法有如下优点：
请求先入消息队列，而不是由业务处理系统直接处理，做了一次缓冲 , 极大地减少了业务处理系统的压力；
队列长度可以做限制，事实上，秒杀时，后入队列的用户无法秒杀到商品，这些请求可以直接被抛弃，返回活动已结束或商品已售完信息；
消息驱动系统
具体场景：
用户新上传了一批照片， 人脸识别系统需要对这个用户的所有照片进行聚类，聚类完成后由对账系统重新生成用 户的人脸索引( 加快查询 ) 。这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。
该方法有如下优点：
避免了直接调用下一个系统导致当前系统失败；
每个子系统对于消息的处理方式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间 段按不同处理速度处理；
三、消息队列的两种方式
点对点模式
点对点模式下包括三个角色
- 消息队列
- 发送者 (生产者)
- 接收者（消费者）
消息发送者生产消息发送到 queue 中，然后消息接收者从 queue 中取出并且消费消息。消息被消费以后， queue 中不再有存储，所以消息接收者不可能消费到已经被消费的消息。
点对点模式特点：
- 每个消息只有一个接收者（Consumer）(即一旦被消费，消息就不再在消息队列中)；
- 发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；
- 接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；
发布/订阅模式
发布 / 订阅模式下包括三个角色：
- 角色主题（Topic）
- 发布者(Publisher)
- 订阅者(Subscriber)
发布者将消息发送到 Topic, 系统将这些消息传递给多个订阅者。
发布 / 订阅模式特点：
- 每个消息可以有多个订阅者；
- 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
- 为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；
四、常见的消息队列的产品
1) RabbitMQ
RabbitMQ 2007 年发布，是一个在 AMQP ( 高级消息队列协议 ) 基础上完成的，可复用的企业消息系统，是当前最主 流的消息中间件之一。
2) activeMQ:
ActiveMQ 是由 Apache 出品， ActiveMQ 是一个完全支持 JMS1.1 和 J2EE 1.4 规范的 JMS Provider 实现。它非常快速 ，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能, 目前市场的活跃 度比较低, 在 java 领域正在被 RabbitMQ 替代
3) RocketMQ
RocketMQ 出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka ，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。 RocketMQ 在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理 等
4) kafka
Apache Kafka 是一个分布式消息发布订阅系统。它最初由 LinkedIn 公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log) ，之后成为 Apache 项目的一部分。 Kafka 系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。
各种消息队列产品的对比图：
五、Kafka的基本介绍
官网： http://kafka.apache.org/
kafka 是最初由 linkedin 公司开发的，使用 scala 语言编写， kafka 是一个分布式，分区的，多副本的，多订阅者的日 志系统（分布式MQ 系统），可以用于搜索日志，监控日志，访问日志等
Kafka is a distributed,partitioned,replicated commit logservice 。它提供了类似于 JMS 的特性，但是在设计实现上完全不同，此外它并不是JMS 规范的完整实现。 kafka 对消息保存时根据 Topic 进行归类，发送消息者成为 Producer, 消息 接受者成为Consumer, 此外 kafka 集群有多个 kafka 实例组成，每个实例 (server) 成为 broker 。无论是 kafka 集群，还是producer和 consumer 都依赖于 zookeeper 来保证系统可用性集群保存一些 meta 信息
kakfa的特点:
- 可靠性: 分布式, 分区 , 复制 和容错等
- 可扩展性: kakfa消息传递系统轻松缩放, 无需停机
- 耐用性: kafka使用分布式提交日志, 这个意味着消息会尽可能快速的保存在磁盘上, 因此它是持久的
- 性能: kafka对于发布和订阅消息都具有高吞吐量, 即使存储了许多TB的消息, 他也爆出稳定的性能-kafka非常快: 保证零停机和零数据丢失
apache kafka 是一个分布式发布 - 订阅消息系统和一个强大的队列，可以处理大量的数据，并使能够将消息从一个 端点传递到另一个端点，kafka 适合离线和在线消息消费。 kafka 消息保留在磁盘上，并在集群内复制以防止数据丢失。kafka构建在 zookeeper 同步服务之上。它与 apache 和 spark 非常好的集成，应用于实时流式数据分析。
kafka的主要应用场景:
1) 指标分析 : kafka 通常用于操作监控数据 , 这设计聚合来自分布式应用程序和统计信息 , 以产生操作的数据集中反馈
2) 日志聚合解决方法 : kafka 可用于跨组织从多个服务器收集日志 , 并使他们一标准的合适提供给多个服务器
3) 流式处理 : 流式的处理框架 (spark, storm , flink) 从主题中读取数据 , 对其进行处理 , 并将处理后的结果数据写入新的主题, 供用户和应用程序使用 , kafka 的强耐久性在流处理的上下文中也非常的有用
版本说明:
- Kafka版本为2.4.1，是2020年3月12日发布的版本。
- 可以注意到Kafka的版本号为：kafka_2.12-2.4.1，因为kafka主要是使用scala语言开发的，2.12为scala的版本号。
http://kafka.apache.org/downloads 可以查看到每个版本的发布时间。
