一、消息队列(MQ)概述
消息队列（Message Queue），是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：
当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。
消息队列主要解决了应用耦合、异步处理、流量削锋等问题。
当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。
二、消息队列使用场景
消息队列在实际应用中包括如下四个场景：
- 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
- 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
- 限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
- 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；
下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用：
2.1 异步处理
具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。
（1）串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信；
在这种方式下，需要最终发送验证短信后再返回给客户端。
（2）并行处理：新注册信息写入后，由发短信和发邮件并行处理；
在这种方式下，发短信和发邮件 需处理完成后再返回给客户端。
假设以上三个子系统处理的时间均为50ms，且不考虑网络延迟，则总的处理时间：
串行：50+50+50=150ms
并行：50+50 = 100ms
若使用消息队列：
并在写入消息队列后立即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间本身是可以很快的，基本可以忽略不计，因此总的处理时间相比串行提高了2倍，相比并行提高了一倍；
2.2 应用耦合
具体场景：用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行人脸识别，一般的做法是，服务器接收到图片后，图片上传系统立即调用人脸识别系统，调用完成后再返回成功，如下图所示：
该方法有如下缺点：
- 人脸识别系统被调失败，导致图片上传失败；
- 延迟高，需要人脸识别系统处理完成后，再返回给客户端，即使用户并不需要立即知道结果；
- 图片上传系统与人脸识别系统之间互相调用，需要做耦合；
若使用消息队列：
客户端上传图片后，图片上传系统将图片信息如uin、批次写入消息队列，直接返回成功；而人脸识别系统则定时从消息队列中取数据，完成对新增图片的识别。
此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。事实上，由于用户并不需要立即知道人脸识别结果，人脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时间，对队列中的图片信息进行处理。
2.3 限流削峰
具体场景：购物网站开展秒杀活动，一般由于瞬时访问量过大，服务器接收过大，会导致流量暴增，相关系统无法处理请求甚至崩溃。而加入消息队列后，系统可以从消息队列中取数据，相当于消息队列做了一次缓冲。
该方法有如下优点：
- 请求先入消息队列，而不是由业务处理系统直接处理，做了一次缓冲,极大地减少了业务处理系统的压力；
- 队列长度可以做限制，事实上，秒杀时，后入队列的用户无法秒杀到商品，这些请求可以直接被抛弃，返回活动已结束或商品已售完信息；
2.4 消息驱动的系统
具体场景：用户新上传了一批照片， 人脸识别系统需要对这个用户的所有照片进行聚类，聚类完成后由对账系统重新生成用户的人脸索引(加快查询)。这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。
该方法有如下优点：
- 避免了直接调用下一个系统导致当前系统失败；
- 每个子系统对于消息的处理方式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间段按不同处理速度处理；
三、消息队列的两种模式
消息队列包括两种模式，点对点模式（point to point， queue）和发布/订阅模式（publish/subscribe，topic）。
3.1 点对点模式
点对点模式下包括三个角色：
- 消息队列
- 发送者 (生产者)
- 接收者（消费者）
消息发送者生产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。
点对点模式特点：
- 每个消息只有一个接收者（Consumer）(即一旦被消费，消息就不再在消息队列中)；
- 发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；
- 接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；
3.2 发布/订阅模式
发布/订阅模式下包括三个角色：
- 角色主题（Topic）
- 发布者(Publisher)
- 订阅者(Subscriber)
发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
发布/订阅模式特点：
- 每个消息可以有多个订阅者；
- 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
- 为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；
Kafka
使用场景
使用
- 第一步：首先需要创建一个Kafka集群，但如果你是在字节工作，恭喜你这一步消息团队的小伙伴已经帮你完成了
- 第二步：需要在这个集群中创建一个Topic，并且设置好分片数量
- 第三步：引入对应语言的SDK，配置好集群和Topic等参数，初始化一个生产者，调用Send方法，将你的Hello World发送出去
- 第四步：引入对应语言的SDK，配置好集群和Topic等参数，初始化一个消费者，调用Poll方法，你将收到你刚刚发送的Hello World
基本概念
- Topic：Kakfa中的逻辑队列，可以理解成每一个不同的业务场景就是一个不同的topic，对于这个业务来说，所有的数据都存储在这个topic中
- Cluster：Kafka的物理集群，每个集群中可以新建多个不同的topic
- Producer：顾名思义，也就是消息的生产端，负责将业务消息发送到Topic当中
- Consumer：消息的消费端，负责消费已经发送到topic中的消息
- Partition：通常topic会有多个分片，不同分片直接消息是可以并发来处理的，这样提高单个Topic的吞吐
Offset
Offset：消息在partition内的相对位置信息，可以理解为唯一ID, 在partition内部严格递增。
对于每一个Partition来说，每一条消息都有一个唯一的Offset，消息在partition内的相对位置信息，并且严格递增
Replica
每个分片有多个Replica，Leader Replica 将会从ISR中选出。
Replica：分片的副本，分布在不同的机器上，可用来容灾，Leader对外服务，Follower异步去拉取leader的数据进行一个同步，如果leader挂掉了，可以将Follower提升成leader再堆外进行服务
ISR：意思是同步中的副本，对于Follower来说，始终和leader是有一定差距的，但当这个差距比较小的时候，我们就可以将这个follower副本加入到ISR中，不在ISR中的副本是不允许提升成Leader的
数据复制
下面这幅图代表着Kafka中副本的分布图。
图中Broker代表每一个Kafka的节点，所有的Broker节点最终组成了一个集群。 图中整个集群，包含了4个Broker机器节点，集群有两个Topic，分别是Topic1和Topic2，Topic1有两个分片，Topic2有1个分片，每个分片都是三副本的状态。这里中间有一个Broker同时也扮演了Controller的角色，Controller是整个集群的大脑，负责对副本和Broker进行分配。
Kafka架构
而在集群的基础上，还有一个模块是ZooKeeper，这个模块其实是存储了集群的元数据信息，比如副本的分配信息等等，Controller计算好的方案都会放到这个地方
一条消息的历程
从一条消息的视角，看看为什么Kafka 能支撑这么高的吞吐?
思考：如果发送条消息，等到其成功后再发一条会有什么问题？
Producer-批量发送
数据压缩：
Broker-数据的存储
如何写入到磁盘呢，我们先来看一下Kafka最终存储的文件结构是什么样子的？
Broker 消息文件结构：
在每一个Broker，都分布着不同Topic的不同分片
磁盘结构：
移动磁头找到对应磁道，磁盘转动，找到对应扇区，最后写入。寻道成本比较高，因此顺序写可以减少寻道所带来的时间成本。
Broker-顺序写： 采用顺序写的方式进行写入，以提高写入效率
Broker-如何找到消息： Consumer通过发送FetchRequest请求消息数据，Broker 会将指定Offset处的消息,按照时间窗口和消息大小窗口发送给Consumer，寻找数据这个细节是如何做到的呢?
此时我们的消息写入到Broker的磁盘上了，那这些数据又该怎么被找到然后用来消费呢
Broker偏移量索引文件： 介绍文件：文件名是文件中第一条消息的offset 然后，第一步，通过二分找到小于目标文件的最大文件
通过二分找到小于目标offset最大的索引位置，再遍历找到目标offset
如果我们需要使用时间戳来寻找的时候，和offset相比只是多加了以及索引，也就是通过二分找到时间戳对应的offset，再重复之前的步骤找到相应的文件数据
Broker-传统数据拷贝：
Broker-零拷贝：
Consumer从Broker中读取数据，通过sendfile的方式，将磁盘读到os内核缓冲区后，直接转到socket buffer进行网络发送 Producer生产的数据持久化到broker。 采用mmap文件映射，实现顺序的快速写入
Consumer-消息的接收端
对于一个Consumer Group来说，多个分片可以并发的消费，这样可以大大提高消费的效率，但需要解决的问题是，Consumer和Partition的分配问题，也就是对于每一个Partition来讲，该由哪一个Consumer来消费的问题。
对于这个问题，我们一般有两种解决方法，手动分配和自动分配
Consumer- Low Level： 通过手动进行分配，哪一个Consumer消费哪一个Partition完全由业务来决定。
第一，手动分配，也就是Kafka中所说的Low Level消费方式进行消费，这种分配方式的一个好处就是启动比较快，因为对于每一个Consumer来说，启动的时候就已经知道了自己应该去消费哪个消费方式，就好比图中的Consumer Group1来说，Consumer1去消费Partition123；Consumer2去消费456；Consumer3去消费78。
这些Consumer再启动的时候就已经知道分配方案了，但这样这种方式的缺点又是什么呢，想象一下，如果我们的Consumer3挂掉了，我们的7,8分片是不是就停止消费了。又或者，如果我们新增了一台Consumer4，那是不是又需要停掉整个集群，重新修改配置再上线，保证Consumer4也可以消费数据，其实上面两个问题，有时候对于线上业务来说是致命的。
Consumer-High Level： 所以Kafka也提供了自动分配的方式，这里也叫做High Level的消费方式。
简单的来说，就是在我们的Broker集群中，对于不同的Consumer Group来讲，都会选取一台Broker当做Coordinator，而Coordinator的作用就是帮助Consumer Group进行分片的分配，也叫做分片的rebalance，使用这种方式，如果ConsumerGroup中有发生宕机，或者有新的Consumer加入，整个partition和Consumer都会重新进行分配来达到一个稳定的消费状态
Consumer Rebalance
Rebalance：
小结
刚刚总共讲了哪一些可以帮助Kafka提高吞吐或者稳定性的功能?
- Producer：批量发送、数据压缩
- Broker：顺序写，消息索引，零拷贝
- Consumer： Rebalance
Kafka-数据复制问题
通过前面的介绍我们可以知道，对于Kafka来说，每一个Broker上都有不同topic分区的不同副本，而每一个副本，会将其数据存储到该Kafka节点上面，对于不同的节点之间，通过副本直接的数据复制，来保证数据的最终一致性，与集群的高可用。
Kafka-重启操作
Kafka-替换、扩容、缩容
Kafka-负载不均衡
这个场景当中，同一个Topic有4个分片，两副本，可以看到，对于分片1来说，数据量是明显比其他分片要大的，当我们机器IO达到瓶颈的时候，可能就需要把第一台Broker上面的Partition3迁移到其他负载小的Broker上面，接着往下看
为了解决Io问题进行迁移，但迁移带来数据复制问题，再次引入IO问题。 解决方案复杂。
Kafka-问题总结
- 运维成本高
- 对于负载不均衡的场景，解决方案复杂
- 没有自己的缓存，完全依赖
Page Cache Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降
我们对以上两个问题进行总结：
- 第一，因为有数据复制的问题，所以
Kafka运维的时间成本和人力人本都不低。 - 第二，对于负载不均衡的场景，我们需要有一个较为复杂的解决方案进行数据迁移，从而来权衡IO升高的问题 除了以上两个问题以外，
Kafka自身还存在其他的问题 比如，Kafka没有自己的缓存，在进行数据读取的时候，只有Page Cache可以用，所以不是很灵活 另外在前面的介绍当中，相信大家也了解到了，Kafka的Controller和Coordinator都是和Broker部署在一起的，Broker因为承载大量IO的原因，会导致Controller和Coordinator的性能下降，如果到一定程度，可能会影响整个集群的可用性
