消息队列Message Queue，简称MQ。
是一种应用间的通信方式，主要由三个部分组成。
消息队列的应用场景较多，常用的可以分为三种：
在架构技术选型的时候一般根据业务的需求选择合适的中间件：
比如中小型公司，低吞吐量的一般用 ActiveMQ、RabbitMQ 较为合适，大数据高吞吐量的大型公司一般选用 Kafka 和RocketMQ。
在实际应用中，如果我们需要把磁盘中的某个文件内容发送到远程服务器上，那么它必须要经过几个拷贝的过程，如图（贴图）。
在这个过程中我们可以发现，数据从磁盘到最终发送出去，要经历 4 次拷贝，而在这四次拷贝过程中，有两次拷贝是浪费的，分别是：
除此之外，由于用户空间和内核空间的切换会带来 CPU 的上线文切换，对于 CPU 性能也会造成性能影响。
而零拷贝，就是把这两次多于的拷贝省略掉，应用程序可以直接把磁盘中的数据从内核中直接传输给Socket，而不需要再经过应用程序所在的用户空间，如下图所示
零拷贝通过DMA（Direct Memory Access）技术把文件内容复制到内核空间中的Read Buffer，
接着把包含数据位置和长度信息的文件描述符加载到Socket Buffer 中，DMA 引擎直接可以把数据从内核空间中传递给网卡设备。
在这个流程中，数据只经历了两次拷贝就发送到了网卡中，并且减少了 2 次cpu 的上下文切换，对于效率有非常大的提高。
所以，所谓零拷贝，并不是完全没有数据赋值，只是相对于用户空间来说，不再需要进行数据拷贝。对于前面说的整个流程来说，零拷贝只是减少了不必要的拷贝次数而已。
在程序中如何实现零拷贝呢？
除此之外，还有一个 mmap 的文件映射机制;
它的原理是：将磁盘文件映射到内存, 用户通过修改内存就能修改磁盘文件。使用这种方式可以获取很大的 I/O 提升，省去了用户空间到内核空间复制的开销。
kafka 是一个用来实现异步消息通信的中间件，它的整个架构由Producer、 Consumer、Broker 组成。
所以，对于kafka 如何保证消息不丢失这个问题，可以从三个方面来考虑和实现。
首先是Producer 端，需要确保消息能够到达 Broker 并实现消息存储，在这个层面，有可能出现网络问题，导致消息发送失败，所以，针对Producer 端，可以通过 2 种方式来避免消息丢失
然后是Broker 端，Broker 需要确保Producer 发送过来的消息不会丢失，也就是只需要把消息持久化到磁盘就可以了。
（如图）但是，Kafka 为了提升性能，采用了异步批量刷盘的实现机制，也就是说按照一定的消息量和时间间隔来刷盘，而最终刷新到磁盘的这个动作，是由操作系统来调度的，所以如果在刷盘之前系统崩溃，就会导致数据丢失。
Kafka 并没有提供同步刷盘的实现，所以针对这个问题，需要通过Partition的副本机制和acks 机制来一起解决。
最后，就是Consumer 必须要能消费到这个消息，实际上，我认为，只要producer和broker 的消息可靠的到了保障，那么消费端是不太可能出现消息无法消费的问题，除非是Consumer 没有消费完这个消息就直接提交了，但是即便是这个情况，也可以通过调整offset 的值来重新消费。
首先，（如图）Kafka Broker 上存储的消息，都有一个Offset 标记。然后kafka 的消费者是通过 offSet 标记来维护当前已经消费的数据，
每消费一批数据，Kafka Broker 就会更新OffSet 的值，避免重复消费。
默认情况下，消息消费完以后，会自动提交 Offset 的值，避免重复消费。
Kafka 消费端的自动提交逻辑有一个默认的 5 秒间隔，也就是说在 5 秒之后的下一次向 Broker 拉取消息的时候提交。
所以在Consumer 消费的过程中，应用程序被强制 kill 掉或者宕机，可能会导致 Offset没提交，从而产生重复提交的问题。
除此之外，还有另外一种情况也会出现重复消费。
（如图）在Kafka 里面有一个Partition Balance 机制，就是把多个Partition 均衡的分配给多个消费者。
Consumer 端会从分配的Partition 里面去消费消息，如果 Consumer 在默认的 5 分钟内没办法处理完这一批消息。
就会触发Kafka 的Rebalance 机制，从而导致Offset 自动提交失败。
而在重新Rebalance 之后，Consumer 还是会从之前没提交的 Offset 位置开始消费，也会导致消息重复消费的问题。
基于这样的背景下，我认为解决重复消费消息问题的方法有几个:
首先，发送到 Kafka Broker 上的消息，最终是以 Partition 的物理形态来存储到磁盘上的。
（如图）而Kafka 为了保证Parititon 的可靠性，提供了 Paritition 的副本机制，然后在这些Partition 副本集里面。存在Leader Partition 和Flollower Partition。
生产者发送过来的消息，会先存到 Leader Partition 里面，然后再把消息复制到 Follower Partition，
这样设计的好处就是一旦Leader Partition 所在的节点挂了，可以重新从剩余的 Partition 副本里面选举出新的 Leader。
然后消费者可以继续从新的 Leader Partition 里面获取未消费的数据。
在Partition 多副本设计的方案里面，有两个很关键的需求。
这两个需求都需要涉及到网络通信，Kafka 为了避免网络通信延迟带来的性能问题，以及尽可能的保证新选举出来的Leader Partition 里面的数据是最新的，所以设计了 ISR 这样一个方案。
ISR 全称是 in-sync replica，它是一个集合列表，里面保存的是和 Leader Parition 节点数据最接近的 Follower Partition
如果某个Follower Partition 里面的数据落后 Leader 太多，就会被剔除 ISR 列表。
简单来说，ISR 列表里面的节点，同步的数据一定是最新的，所以后续的Leader 选举，只需要从ISR 列表里面筛选就行了。
所以，我认为引入ISR 这个方案的原因有两个:
首先，在 kafka 的架构里面，用到了 Partition 分区机制来实现消息的物理存储（如图），在同一个topic 下面，可以维护多个partition 来实现消息的分片。
生产者在发送消息的时候，会根据消息的 key 进行取模（如图），来决定把当前消息存储到哪个partition 里面。
并且消息是按照先后顺序有序存储到 partition 里面的。
在这种情况下，（如图），假设有一个topic 存在三个partition，而消息正好被路由到三个独立的partition 里面。
然后消费端有三个消费者通过 balance 机制分别指派了对应消费分区。因为消费者是完全独立的网络节点，
所有可能会出现，消息的消费顺序不是按照发送顺序来实现的，从而导致乱序的问题。
针对这个问题，一般的解决办法就是自定义消息分区路由的算法，然后把指定的key都发送到同一个 Partition 里面。（如图）
接着指定一个消费者专门来消费某个分区的数据，这样就能保证消息的顺序消费了。
另外，有些设计方案里面，在消费端会采用异步线程的方式来消费数据来提高消息的处理效率，那这种情况下，因为每个线程的消息处理效率是不同的，所以即便是采用单个分区的存储和消费也可能会出现无序问题，针对这个问题的解决办法就是在消费者这边使用一个阻塞队列，把获取到的消息先保存到阻塞队列里面，然后异步线程从阻塞队列里面去获取消息来消费。
当我们向某个Topic 发送消息的时候，在 Kafka 的Broker 上，会通过Partition 分区的机制来实现消息的物理存储。
一个Topic 可以有多个Partition，相当于把一个 Topic 里面的N 个消息数据进行分片存储。
消费端去消费消息的时候，会从指定的Partition 中去获取。
在同一个消费组中，一个消费者可以消费多个Partition 中的数据。但是消费者的数量只能小于或者等于Partition 分区数量。
理解了Kafka 的工作机制以后，再来理解一下exactlyOnce 的意思，在MQ 的消息投递的语义有三种：
准确来说，目前市面上的MQ 产品，基本上都没有提供Exactly Once 语义的实现。我们只能通过一些其他手段来达到 Exactly Once 的效果。也就是确保生产者只发送一次，消费端只接受一次
