Kafka 为什么快？ Kafka 和其他消息队列的区别？ Kafka 这么快，它是如何保证不丢失消息？
Kafka 的消息是保存或缓存在磁盘上的，一般认为在磁盘上读写数据是会降低性能的，因为寻址会比较消耗时间，但是实际上，Kafka 的特性之一就是高吞吐率。Kafka 之所以能这么快，无非是：「顺序写磁盘、大量使用内存页 、零拷贝技术的使用」…
下面我就从数据写入和读取两方面分析，为大家分析下为什么 Kafka 速度这么快。
对于数据持久化到磁盘中， 数据写入 Kafka 会把收到的消息都写入到硬盘中，它绝对不会丢失数据。为了优化写入速度 Kafka 采用了两个技术， 顺序写入和 Memory Mapped File 。
Kafka 会把收到的消息都写入到硬盘中，它绝对不会丢失数据。为了优化写入速度 Kafka 采用了两个技术， 顺序写入和 MMFile（Memory Mapped File）内存映射文件。
磁盘读写的快慢取决于你怎么使用它，也就是顺序读写或者随机读写。在顺序读写的情况下，磁盘的顺序读写速度和内存持平。因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。「所以硬盘最讨厌随机 I/O，最喜欢顺序 I/O」。为了提高读写硬盘的速度，Kafka 就是使用顺序 I/O。
而且 Linux 对于磁盘的读写优化也比较多，包括 read-ahead 和 write-behind，磁盘缓存等。
如果在内存做这些操作的时候，一个是 Java 对象的内存开销很大，另一个是随着堆内存数据的增多，Java 的 GC 时间会变得很长。 使用磁盘操作有以下几个好处： （1）磁盘顺序读写速度超过内存随机读写。 （2）JVM 的 GC 效率低，内存占用大。使用磁盘可以避免这一问题。 （3）系统冷启动后，磁盘缓存依然可用。
下图就展示了 Kafka 是如何写入数据的， 每一个 Partition 其实都是一个文件 ，收到消息后 Kafka 会把数据插入到文件末尾（虚框部分）：
对于这个图的解释，左边old表示是旧数据，右边new表示是新写入的数据，下面一个箭头很明显，这里表示一个topic下面的三个partition，不断的往里面写数据。
这种方法有一个缺陷——没有办法删除数据 ，所以 Kafka 是不会删除数据的，它会把所有的数据都保留下来，每个 消费者（Consumer）对每个 Topic 都有一个 Offset 用来表示读取到了第几条数据 。
对于上图的解释： 对于producer，producer生产的数据不断增加， 对于Consumer消费kafka中的数据，提供一个offset，consumer消费的数据不会减少，只是移动offset，offset之前是已经被消费的，offset之后是没有被消费的。 注意，kafka不会删除数据，只是提供一个offset，这个offset可以用zookeeper管理， 特别注意，这个offset只对consumer消费有用，对producer生产没用。
一般情况下 Offset 由客户端 SDK 负责保存 ，会保存到 Zookeeper 里面 。
关于存在硬盘中的消息，Kafka 也有它的解决方法，可以基于时间和 Partition 文件的大小，正常 Kafka 是默认七天的保存，也可以通过命令来修改，以 users topic 为例。 修改kafka 7天 默认保存周期 kafka-topics.sh --zookeeper 6 --alter --topic users --config retention.ms=100000
上面说了，kafka不会删除数据，即使被消费掉也是移动offset，不删除数据，所有的数据都持久化到磁盘中，所以，为了避免磁盘被撑满的情况，Kakfa 提供了两种策略来删除数据： 「基于时间」 （默认七天） 「基于 Partition 文件大小」
这个和Java NIO中的内存映射基本相同，在大学的计算机原理里我们学过（划重点），mmf （Memory Mapped Files）直接利用操作系统的Page来实现文件到物理内存的映射，完成之后对物理内存的操作会直接同步到硬盘。mmf 通过内存映射的方式大大提高了IO速率，省去了用户空间到内核空间的复制。它的缺点显而易见–不可靠，当发生宕机而数据未同步到硬盘时，数据会丢失，Kafka 提供了produce.type参数来控制是否主动的进行刷新
Kafka 提供了一个参数 producer.type 来控制是不是主动 Flush： 如果 Kafka 写入到 mmf 之后就立即 Flush，然后再返回 Producer 叫同步 (Sync) 如果 Kafka 写入 mmf 之后立即返回 Producer 不调用 Flush 叫异步 (Async)。
作为一个消息系统，不可避免的便是消息的拷贝，常规的操作，一条消息，需要从创建者的socket到应用，再到操作系统内核，然后才能落盘。同样，一条消息发送给消费者也要从磁盘到内核到应用再到接收者的socket，中间经过了多次不是很有必要的拷贝。
传统 Read 方式进行网络文件传输，在传输过程中，文件数据实际上是经过了四次 Copy 操作，其具体流程细节如下： （1）调用 Read 函数，文件数据被 Copy 到内核缓冲区。 （2）Read 函数返回，文件数据从内核缓冲区 Copy 到用户缓冲区 （3）将文件数据从用户缓冲区 Copy 到内核与 Socket 相关的缓冲区。 （4）数据从 Socket 缓冲区 Copy 到相关协议引擎。 传统Read方式(四次Copy操作)：硬盘—>内核 buf—>用户 buf—>Socket buf—>协议引擎
Sendfile 系统调用则提供了一种减少以上多次 Copy，提升文件传输性能的方法。 在内核版本 2.1 中，引入了 Sendfile 系统调用，以简化网络上和两个本地文件之间的数据传输。Sendfile 的引入不仅减少了数据复制，还减少了上下文切换。相较传统 Read/Write 方式，2.1 版本内核引进的 Sendfile 已经减少了内核缓冲区到 User 缓冲区，再由 User 缓冲区到 Socket 相关缓冲区的文件 Copy。减少两次copy。 而在内核版本 2.4 之后，文件描述符结果被改变，Sendfile 实现了更简单的方式，再次减少了一次 Copy 操作。减少了三次copy。
Kafka 把所有的消息都存放在一个一个的文件中，当消费者需要数据的时候 Kafka 直接把文件发送给消费者，配合 mmap 作为文件读写方式，直接把它传给 Sendfile。
传统Read方式(四次Copy操作)：硬盘—>内核 buf—>用户 buf—>Socket buf—>协议引擎 SendFile 2.1，硬盘—>内核 buf—>协议引擎 SendFile 2.4，硬盘—>协议引擎
producer发送消息两种方式：同步发送 + 异步发送（异步发送解释：Kafka允许进行批量发送消息，producter发送消息的时候，可以将消息缓存在本地，等到了固定条件发送到 Kafka ），同步发送就是马上发送，异步发送就攒一波再发送，那攒一波到什么使用发送呢？两种方式： （1）等消息条数到固定条数。 （2）一段时间发送一次。
Kafka支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩。压缩的好处就是减少传输的数据量，减轻对网络传输的压力。
Producer压缩之后，在Consumer需进行解压，虽然增加了CPU的工作，但在对大数据处理上，瓶颈在网络上而不是CPU，所以这个成本很值得。
注意：「批量发送」和「数据压缩」一起使用，单条做数据压缩的话，效果不明显
金手指：数据压缩后发送的优点和缺点 1、优点：压缩包的大小一定比直接发送的大小要小，提高网络传输效率； 2、缺点：producer要压缩，consumer要解压，增加producer和consumer的CPU压力 小结：大数据处理上，瓶颈在网络上而不是CPU，只要优点可以覆盖缺点，就应该使用这种方式 good
问题：为什么 Apache Kafka虽然使用了硬盘存储，但是仍然可以速度很快? 标准答案：原因五点： 1、对于producer：把所有的消息都变成一个批量的文件，并且进行合理的批量压缩，减少网络 IO 损耗， 2、对于broker：写磁盘两招：通过 mmap 提高 I/O 速度；写入数据的时候由于单个 Partion 是末尾添加，所以速度最优；读磁盘一招：读取数据的时候配合 Sendfile 直接暴力输出。
写磁盘持久化的是broker,从磁盘中读取发送给consumer的，也是broker，producer和consumer只有内存操作。
Kafka的设计目标是高吞吐量，为了达到这个高吞吐量的目标，那它与其它消息队列的区别就显而易见了：
1、对于broker，顺序写磁盘，内存映射文件写磁盘：Kafka操作的是序列文件 I/O（序列文件的特征是按顺序写，按顺序读），为保证顺序，Kafka强制点对点的按顺序传递消息，这意味着，一个consumer在消息流（或分区）中只有一个位置。
2、对于broker，Kafka的消息存储在OS pagecache（页缓存，page cache的大小为一页，通常为4K，在Linux读写文件时，它用于缓存文件的逻辑内容，从而加快对磁盘上映像和数据的访问）。
3、对于broker-consumer，基于SendFile零拷贝读磁盘，并且，不保存消息状态（是否被消费），使用offset记录消费位置：Kafka不保存消息的状态，即消息是否被“消费”。一般的消息系统需要保存消息的状态，并且还需要以随机访问的形式更新消息的状态。而Kafka 的做法是保存Consumer在Topic分区中的位置offset，在offset之前的消息是已被“消费”的，在offset之后则为未“消费”的，并且offset是可以任意移动的，这样就消除了大部分的随机IO。
4、对于broker，批量发送、压缩后发送，kafka在producer端加速/高吞吐量的措施：Kafka支持点对点的批量消息传递。
RabbitMQ:分布式，支持多种MQ协议，重量级 ActiveMQ：与RabbitMQ类似 ZeroMQ：以库的形式提供，使用复杂，无持久化 Redis：单机、纯内存性好，持久化较差 Kafka：分布式，消息不是使用完就丢失【较长时间持久化】，吞吐量高【高性能】，轻量灵活
问题：Kafka 为什么这么快，又能保证不丢失消息？
为了得到更好的性能，Kafka 支持在生产者一侧进行本地buffer，也就是累积到一定的条数才发送，如果这里设置不当是会丢消息的。
生产者端设置：producer.type=async, sync，默认是 sync。
当设置为 async，会大幅提升性能，因为生产者会在本地缓冲消息，并适时批量发送。
如果对可靠性要求高，那么这里可以设置为 sync 同步发送。
一般时候我们还需要设置：min.insync.replicas> 1 ，消息至少要被写入到这么多副本才算成功，也是提升数据持久性的一个参数，与acks配合使用。
但如果出现两者相等，我们还需要设置 replication.factor = min.insync.replicas + 1 ，避免在一个副本挂掉，整个分区无法工作的情况！
为了保证 leader 副本能有 follower 副本能同步消息，我们一般会为 topic 设置 replication.factor >= 3。这样就可以保证每个 分区(partition) 至少有 3 个副本，以确保消息队列的安全性。
我们最开始也说了我们发送的消息会被发送到 leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步。多个 follower 副本之间的消息同步情况不一样，当我们配置了 unclean.leader.election.enable = false 的话，当 leader 副本发生故障时就不会从 follower 副本中和 leader 同步程度达不到要求的副本中选择出 leader ，这样降低了消息丢失的可能性。
Kafka 架构深入 ，通过 ACK 机制保证消息送达。Kafka 采用的是至少一次（At least once），消息不会丢，但是可能会重复传输。
acks 的默认值即为1，代表我们的消息被leader副本接收之后就算被成功发送。我们可以配置 acks = all ，代表则所有副本都要接收到该消息之后该消息才算真正成功被发送。
consumer端丢失消息的情形比较简单：
如果在消息处理完成前就提交了offset，那么就有可能造成数据的丢失。
由于Kafka consumer默认是自动提交位移的，所以在后台提交位移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长，则建议把逻辑放到另一个线程中去做。
为了避免数据丢失，现给出几点建议：设置 enable.auto.commit=false
关闭自动提交位移，在消息被完整处理之后再手动提交位移。
从producer broker/partition consumer 三个方面来回答，拉高逼格
问题：为什么 Apache Kafka虽然使用了硬盘存储，但是仍然可以速度很快? 标准答案：原因五点： 1、对于producer：把所有的消息都变成一个批量的文件，并且进行合理的批量压缩，减少网络 IO 损耗， 2、对于broker：写磁盘两招：通过 mmap 提高 I/O 速度；写入数据的时候由于单个 Partion 是末尾添加，所以速度最优；读磁盘一招：读取数据的时候配合 Sendfile 直接暴力输出。
写磁盘持久化的是broker,从磁盘中读取发送给consumer的，也是broker，producer和consumer只有内存操作。
重要的点： 第一，producer批量发送
producer发送消息两种方式：同步发送 + 异步发送（异步发送解释：Kafka允许进行批量发送消息，producter发送消息的时候，可以将消息缓存在本地，等到了固定条件发送到 Kafka ），同步发送就是马上发送，异步发送就攒一波再发送，那攒一波到什么使用发送呢？两种方式： （1）等消息条数到固定条数。 （2）一段时间发送一次。 第二，producer压缩发送 金手指：数据压缩后发送的优点和缺点 1、优点：压缩包的大小一定比直接发送的大小要小，提高网络传输效率； 2、缺点：producer要压缩，consumer要解压，增加producer和consumer的CPU压力 小结：大数据处理上，瓶颈在网络上而不是CPU，只要优点可以覆盖缺点，就应该使用这种方式 good 第三，broker写磁盘，顺序写入（磁盘寻址 + 磁盘写入，磁盘寻址是机械运动，速度慢，去掉前者，磁盘写入和内存写入速度相差无几） 对于producer，producer生产的数据不断增加； 对于consumer，消费kafka中的数据，提供一个offset，consumer消费的数据不会减少，只是移动offset，offset之前是已经被消费的，offset之后是没有被消费的。 注意，kafka不会删除数据，只是提供一个offset，这个offset可以用zookeeper管理， 特别注意，这个offset只对consumer消费有用，对producer生产没用。 上面说了，kafka不会删除数据，即使被消费掉也是移动offset，不删除数据，所有的数据都持久化到磁盘中，所以，为了避免磁盘被撑满的情况，Kakfa 提供了两种策略来删除数据： 「基于时间」 （默认七天） 「基于 Partition 文件大小」 第四，broker写磁盘 优点：mmf （Memory Mapped Files）直接利用操作系统的Page来实现文件到物理内存的映射，完成之后对物理内存的操作会直接同步到硬盘。mmf 通过内存映射的方式大大提高了IO速率，省去了用户空间到内核空间的复制。 缺点：不可靠，当发生宕机而数据未同步到硬盘时，数据会丢失，Kafka 提供了produce.type参数来控制是否主动的进行刷新，如果 Kafka 写入到 mmf 后立即flush再返回给生产者则为同步模式，反之为异步模式。 第五，读磁盘，零复制 传统Read/Write方式(四次Copy操作)：硬盘—>内核 buf—>用户 buf—>Socket 相关缓冲区—>协议引擎 基于 Sendfile 实现零拷贝（Zero Copy）
从producer broker/partition consumer 三个方面来回答，拉高逼格
Kafka的设计目标是高吞吐量，为了达到这个高吞吐量的目标，那它与其它消息队列的区别就显而易见了： 1、对于broker，顺序写磁盘：Kafka操作的是序列文件I / O（序列文件的特征是按顺序写，按顺序读），为保证顺序，Kafka强制点对点的按顺序传递消息，这意味着，一个consumer在消息流（或分区）中只有一个位置。 2、对于broker-consumer，不保存消息状态（是否被消费），使用offset记录消费位置：Kafka不保存消息的状态，即消息是否被“消费”。一般的消息系统需要保存消息的状态，并且还需要以随机访问的形式更新消息的状态。而Kafka 的做法是保存Consumer在Topic分区中的位置offset，在offset之前的消息是已被“消费”的，在offset之后则为未“消费”的，并且offset是可以任意移动的，这样就消除了大部分的随机IO。 3、对于broker，批量发送、压缩后发送，kafka在producer端加速/高吞吐量的措施：Kafka支持点对点的批量消息传递。 4、对于broker，Kafka的消息存储在OS pagecache（页缓存，page cache的大小为一页，通常为4K，在Linux读写文件时，它用于缓存文件的逻辑内容，从而加快对磁盘上映像和数据的访问）。
从producer broker/partition consumer 三个方面来回答，拉高逼格
第一，对于broker-consumer，关于 ACK 机制，添加 acks=all 这个条件，保证broker发送给consumer的消息不会被丢 Kafka 通过 ACK 机制保证消息送达，Kafka 采用的是至少一次（At least once），消息不会丢，但是可能会重复传输。 acks 的默认值即为1，代表我们的消息被leader副本接收之后就算被成功发送。我们可以配置 acks = all ，代表则所有副本都要接收到该消息之后该消息才算真正成功被发送。 所以，添加 acks=all 这个条件，保证broker发送给consumer的消息不会被丢。
**第二，对于broker，partition数据设置至少3个副本分区，保证存储在 broker/partition 中的消息不丢失 ** 为了保证 leader 副本能有 follower 副本能同步消息，我们一般会为 topic 设置 replication.factor >= 3。这样就可以保证每个 分区(partition) 至少有 3 个副本，以确保消息队列的安全性。
第三，对于broker，leader partition宕机后，关闭 unclean leader 选举，减低数据丢失可能性 我们最开始也说了我们发送的消息会被发送到 leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进行同步。多个 follower 副本之间的消息同步情况不一样，当我们配置了 unclean.leader.election.enable = false 的话，当 leader 副本发生故障时就不会从 follower 副本中和 leader 同步程度达不到要求的副本中选择出 leader ，这样降低了消息丢失的可能性。
第四，对于producer，攒一波批量发送消息，同步发送/异步发送 异步发送定义：为了得到更好的性能，Kafka 支持在生产者一侧进行本地buffer，也就是累积到一定的条数才发送，如果这里设置不当是会丢消息的。 同步发送/异步发送设置：生产者端设置：producer.type=async, sync，默认是 sync。 异步消息：当设置为 async，会大幅提升性能，因为生产者会在本地缓冲消息，并适时批量发送。 同步消息：如果对可靠性要求高，那么这里可以设置为 sync 同步发送。
第四2，对于producer-broker，消息至少要被写入到这么多副本才算成功 一般时候我们还需要设置：min.insync.replicas> 1 ，消息至少要被写入到这么多副本才算成功，也是提升数据持久性的一个参数，与acks配合使用。 但如果出现两者相等，我们还需要设置 replication.factor = min.insync.replicas + 1 ，避免在一个副本挂掉，整个分区无法工作的情况！
第五，对于consumer，关闭自动提交位移，在消息被完整处理之后再手动提交位移。 consumer端丢失消息的情形比较简单：如果在消息处理完成前就提交了offset，那么就有可能造成数据的丢失。 由于Kafka consumer默认是自动提交位移的，所以在后台提交位移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长，则建议把逻辑放到另一个线程中去做。 为了避免数据丢失，现给出几点建议：设置 enable.auto.commit=false 关闭自动提交位移，在消息被完整处理之后再手动提交位移。
Kafka面试三个问题，完成了。
天天打码，天天进步！！！
