MQ(Message Queue)消息队列，是一种跨进程的通信方式，应用程序通过写入和检索出入队列的消息来通信，而无需通过专用连接来链接它们。针对上面这句话我再举个列子，之前我们说过的Dubbo也是跨进程的通信方式，但它是建立在服务消费者调用服务提供者的基础上，而此时我们说的MQ，消息生产者借助消息队列传递数据，做一个比喻：消息生产者如果想要发表什么言论，它不是自己散播，而是会先把这个“言论”传给“代言人”(消息队列)，经由代言人传给消息的消费者。这样做有什么好处呢？
消息队列的好处
- 解耦：消息生产者和消费者解耦，交互系统之间没有直接的调用关系，只通过消息传输，耦合度低。
- 异步：消息进入队列后，不用立即处理，以异步方式处理，加快响应速度。
- 削峰限流：若是遇到流量很大的秒杀业务，通过MQ能减缓数据库的压力。
消息队列的通信模式
点对点模式：
点对点也叫消费集群，生产者将消息发送到MQ，消费者主动pull拉取消息，消息被消费以后，队列中不再储存消息，所以点对点模式中，一个消息最多有一个消费者，消息不会被重复消费。
优点：消费者拉取消息的频率可以由自己控制。
缺点：消费者需要安排额外的线程监控消息队列中是否有消息可以消费。
发布/订阅模式：
发布/订阅模式也叫广播模式，生产者将消息发布到消息队列中，订阅该消息的消费者们都会被动push收到该消息，类似于你订阅的公众号推文一样。
优点：消费者被动接受消息，无需额外线程去监控消息队列中是否有待消费的消息。
缺点：不支持顺序消费；不同消费者的处理消息的速度不一致，但push模式下想尽快让消息送达消费者，可能会导致部分消费者来不及处理消息导致拒绝消息或网络拥塞；出现消息重复消费的概率大于点对点模式；不支持消息堆积的查询。
以上是对MQ的介绍，我们还是要选一个MQ的代表——Kafka再来详细介绍一番。
Kafka的框架：
借着上图，我们来捋一捋kafka的框架组成和过程：
组件
Producer：消息生产者。
Kafka Cluster：
Broker：Kafka是以集群模式存在的，每个Broker相当于一个Kafka的实例，每个Broker的编号在Kafka Cluster内是不重复的。
Topic：消息根据不同的主题分成不同的Topic，Topic里保存了消息的数据，一个Broker里可以包含多个Topic。
Partition：一个Topic可以划分为多个Partition，作为负载，提高kafka的吞吐量，同一个topic在不同的Partition的数据是不重复的。Partition在物理上对应一个文件夹，该文件夹存储对应Partition的所有数据和索引文件。
Leader和Follower：Leader是作为主体的Partition，其他Follower作为副本，若Leader故障，则选择一个Follower称为新Leader顶上。在kafka中默认副本的最大数量是10个，且Follower的数量不能大于Broker的数量，Follower和Leader绝对是在不同的Broker，同一Broker对同一个分区也只可能存放一个Follower（包括自己）。
Consumer Group：不同的单个消费者组成一个消费者组，每个消费者组都有组id，
多个消费者组成一个大的消费者，一个Partition的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同Partition的数据，这也是为了提高kafka的吞吐量！
Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。
Kafka的过程：
- 消息生产者产生消息，在刚刚的组件中，我们知道，一般都是把消息归类成不同的Topic，而且消息首先会发到Broker的作为Leader的Partition上，所以消息生产者
需要知道消息隶属的Topic，和Broker的列表，有了这两个前提，生产者才会把消息push给Leader。 - Leader拿到消息后，将数据写入本地文件。
- Follower从Leader通过pull 拉取数据。
- Follower也将消息写入本地文件，并向Leader发送ACK确认。
- Leader收到所有Follower的ACK后，向消息生产者发送ACK。
- 消息存好后，就可以进行消费了，Kafka采用的是点对点的模式，消费者主动的去找kafka集群的Leader拉取消息。
以上就是Kafka的简要过程，以下还有两个需要思考的问题：
Consumer&Partition
同一个消费者组的消费者可以消费同一个Topic下的不同Partition的数据，但同一个消费者组里的多个消费者不能去消费同一个Partition里的数据。Consumer和Partition的数目最好是持平；若Consumer数目大于Partition的数目，可能导致部分Consumer空闲（资源浪费）；若Consumer数目小于Partition的数目，可能导致至少一个Consumer消费多个Partition（也不算违规，但不算最优配置）。
Kafka为什么那么快？
Kafka是以高性能著称，它的快，取决于以下几点：
写入数据
1.硬盘顺序写入
对机械硬盘来说，读写请求来了之后，会算出数据所处的位置，然后就进行：
(1) 寻道：磁头沿半径方向移动，直到移动到所在的柱面。
(2) 旋转盘片：盘片高速旋转，到达数据的起始位置。
(3) 磁头沿磁道从磁盘读写数据。
顺序写入：寻道和旋转盘片只需一次开销，剩下的是数据传输的固有开销。
随机写入：寻道和旋转盘片需两次开销。
综上所述，顺序写入的性能优于随机写入。
对于固态硬盘来说，它是一个支持随机寻址的存储芯片，本来也没有寻道和旋转盘片的开销，所以顺序写入和随机写入的主要性能差异在垃圾回收时：
闪存不支持update-in-place，需要更新的数据需要写在新的区域，然后把原始数据标位失效，当空间不足，则需要清除这部分失效数据，然而清楚的最小单位是一个大块Block，所以又得把周围的有效数据挪走，这样就带来新的损耗。顺序写入在垃圾回收时，只需一次简单的擦除即可，性能优于随机写入。
- 内存映射文件（Memory Mapped Files）
即使是顺序写入，但磁盘I/O的性能还是赶不上内存I/O的效率。所以
Kafka充分利用了现代操作系统的OS分页存储来利用内存提高I/O效率
Kafka使用mmap写文件，使用零拷贝(zero-copy)减少了用户态与内核态之间的切换，让拷贝次数降到最低，从而实现高性能。
为了更有对比性，我将传统缓存I/O和mmap I/O的图引用如下：
two ways of I/O.png
传统缓存I/O写入数据：用户空间→内核空间缓冲区→磁盘（由操作系统决定时间）；
mmap I/O写入数据：只有一次页缓存的复制，写到mmap中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。
读出数据
Kafka使用零拷贝（zero copy）
传统的文件传输: 通过java.io.DataOutputStream，java.io.FileInputStream来实现的，然后通过while循环来读取input，然后写入到output。
File.read()：磁盘→内核缓冲区→用户缓冲区；
Socket.send()：用户缓冲区→内核缓冲区→网卡（硬件）缓冲区。
零拷贝 ：通过File.Channel.transferTo 方法（该方法底层是基于操作系统的sendfile这个system call来实现的），不再经过用户态，文件→（经由DMA）内核ReadBuffer→网卡接口buffer。
