消息队列的使用场景有哪些？
- 异步通信：有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
- 解耦：降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束
- 冗余：有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
- 扩展性：因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容
- 过载保护：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃
- 可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
- 顺序保证：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
- 缓冲：在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。
- 数据流处理：分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择
MQ缺点
- 系统可用性降低：系统引入的外部依赖越多，越容易挂掉。本来你就是
A系统调用BCD三个系统的接口就好了，ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整，MQ一挂，整套系统崩溃的，你不就完了？如何保证消息队列的高可用。 - 系统复杂度提高：硬生生加个
MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。 - 一致性问题：
A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。
ISR是什么？
ISR（in-sync replica） 就是 Kafka 为某个分区维护的一组同步集合，即每个分区都有自己的一个 ISR 集合，就是从分区的从节点中找出一些节点加入到ISR集合（min.insync.replicas这个参数设定ISR中的最小副本数是多少，默认值为1）。处于 ISR 集合中的副本，意味着 follower 副本与 leader 副本保持同步状态，只有处于 ISR 集合中的副本才有资格被选举为 leader。follower从leader同步数据有一些延迟（延迟时间replica.lag.time.max.ms），一旦超过延迟时间，就会把这个这个follower从ISR列表中移除。被移除的followe会从leader复制数据进行追赶，一旦追赶上又可以重新进入ISR列表。一条 Kafka 消息，只有被 ISR 中的副本都接收到，才被视为“已同步”状态。这跟 zk 的同步机制不一样，zk 只需要超过半数节点写入，就可被视为已写入成功。
什么是零拷贝技术？
传统的IO接口像read和write系统调用，在执行过程中都是涉及到数据拷贝操作的，比如调用read()接口去读取一个文件时，首先需要将CPU由用户切换成内核态，然后把文件从磁盘读取到
read()和write()
read()系统调用的步骤： 1.会涉及到到一次用户态到内核态的切换，然后会发出 sys_read()系统调用，从文件读取数据。(一次上下文切换) 2.磁盘控制器会使用DMA技术将磁盘文件拷贝到内核内存空间的缓冲区。(一次DMA拷贝) 3.CPU会将数据从内核内存空间的缓冲区拷贝到用户进程内存空间的缓冲区。(一次CPU拷贝) 4.然后read()系统调用返回后，会进行内核态往用户态的切换，这样用户程序进程就可以修改数据了。(一次上下文切换)
write()系统调用的步骤： 1.首先会涉及CPU从用户态切换到内核态，然后会将数据从用户程序的内存空间拷贝到内核内存空间中的Socket缓冲区。(一次上下文切换，一次CPU拷贝) 2.网卡会使用DMA技术，将数据从内核内存空间中的缓冲区拷贝到网卡。(一次DMA拷贝) 3.write()调用完成后会从内核态切换到用户态。(一次上下文切换)
2.MMAP和write()
mmap
1.CPU从用户态切换到内核态，磁盘控制器使用DMA技术将数据从磁盘拷贝到内核的内存空间。不会将数据拷贝到用户程序的内存空间，而是将一块物理内存让用户进程的空间与内核空间进行共享，将内核中的这部分内存空间映射到用户进程的内存空间，从而让用户进程可以直接访问这部分内存。(一次上下文切换，一次DMA拷贝)
2.mmap调用完毕后，CPU会从内核态切换到用户态。(一次上下文切换)
mmap相比于read()系统调用还是会有2次上下文切换，但是可以减少一次CPU拷贝，因为数据是存在内核的内存空间中。
write
1.首先CPU从用户态切换到内核态，然后把数据从内核的内存空间拷贝到内核中Socket缓冲区。(一次上下文切换，一次CPU拷贝)
2.网卡使用DMA技术，将数据从Socket缓冲区拷贝到网卡。发送完毕后，从内核态切换为用户态。(一次上下文切换，一次DMA拷贝)
https://mp.weixin.qq.com/s/xDZ9NnyUZSoR9npuMLdpWAhttps://blog.csdn.net/choumu8867/article/details/100658332
sendfile
这种方式只能用于发送文件，不能修改文件，在Kakfa发送消息给消费者时有用到。
读取时：
1.首先CPU从用户态切换成内核态，然后磁盘控制器使用DMA技术将文件从磁盘拷贝到内核空间的缓冲区中。
（一次上下文切换，一次DMA拷贝）
发送时：
2.早期的版本是将数据从内核空间中的缓存区拷贝到内核空间的Socket缓冲区，在Linux 2.4以后，是只需要将数据在内核空间的文件数据缓存中的位置和偏移量写入到Socket缓存中，然后网卡直接从Socket缓存中读取文件的位置和偏移量，使用DMA技术拷贝到网卡。发送完毕后，从内核态切换为用户态。
（一次上下文切换，一次DMA拷贝。）
总结：
传统read()和write()方案：数据拷贝了4次，CPU上下文切换了很多次
mmap和write()方案：数据拷贝了3次，会减少一次CPU拷贝，上下文切换了4次。(可以减少1次CPU拷贝)
sendfile方案：数据拷贝了2次，上下文切换了2次。但是用户进程不能修改数据。(可以减少2次CPU拷贝，至少2次上下文切换)
Kafka刷盘时机是怎么样的？
log.flush.interval.messages 最大刷盘消息数量 log.flush.interval.interval.ms 最大刷盘时间间隔 log.flush.scheduler.interval.ms 定期刷盘间隔 可以通过设置 最大刷盘消息数量 和 最大刷盘时间间隔 来控制fsync系统调用的时间，但是Kafka不推荐去设置这些参数，希望让操作系统来决定刷盘的时机，这样可以支持更高的吞吐量。而且Kafka保证可用性是通过多副本来实现的，一个机器挂掉了就会选举副本作为leader。
