从入门到入土 04-2 kafka理论(面试)篇

这篇文章是理论篇；如果想看 实操请点击这里

一般想要了解什么中间件的步骤都有几个步骤：

1. 1是什么
2. 2使用场景
3. 3优缺点是啥
4. 4和同类型中间件对比的核心优势
5. 5关键技术点

1、什么是kafka

Kafka是分布式的发布-订阅消息系统，它是有LinkedIn公司开发的，之后成为了Apache项目的一部分，它是一个分布式，异步解耦，冗余备份的可持久化的日志服务，它主要用于处理流式数据。

2、使用场景和：

1、缓冲和流量削峰
上游数据有时候会突发流量，下游系统可能扛不住尔导致挂掉，或者是下游没有足够的能力去处理，那么就可以先把流量都缓冲在kafka里面，下游服务就可以按照自己的节奏去慢慢处理。
2、日志收集
ELK 做日志收集。
3、物联网
可以作为物联网的数据集中收集中间件；或者也可以用MQTT
4、异步、解耦、扩展
项目开始的时候并不能确定具体需求，那么可以使用消息队列作为一个接口层，解耦重要的业务流程，消息通讯等或者当你需要一个高吞吐量的一个消息队列中间件，有的时候不想立即处理消息那么就利用队列异步处理，有需要的时候就去处理；
5、冗余
可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费，供多个无关联的业务使用。

3、使用Kafka有什么优点和缺点？

优点：
1、支持跨数据中心的消息复制；
2、单机吞吐量：十万级，最大的优点，就是吞吐量高;
3、topic数量都吞吐量的影响：topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源;
4、时效性：ms级;
5、可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用;
6、消息可靠性：经过参数优化配置，消息可以做到0丢失;
7、功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用。
缺点：
1、由于是批量发送，数据并非真正的实时； 仅支持统一分区内消息有序，无法实现全局消息有序；
2、有可能消息重复消费；
3、依赖zookeeper进行元数据管理，等等。
消费场景是主动消费，怕给数据收集端搞挂了，就是说你得写一个死循环去请求他（我自己是这么李理解得）；

4、Kafka相对传统技术有什么优势?

1、快速：单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。
2、可伸缩：在一组机器上对数据进行分区和简化，以支持更大的数据
3、持久：消息是持久性的，并在集群中进行复制，以防止数据丢失。
4、设计：它提供了容错保证和持久性
5、发布订阅模式：消费者可以订阅一个或者多个topic

5、为什么说Kafka性能很好，体现在哪里？

1、顺序读写
由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。
2、零拷贝 （重点）
Zero-copy 零拷技术减少拷贝次数，零拷贝就是一种避免 CPU 将数据从一块存储拷贝到另外一块存储的技术。针对操作系统中的设备驱动程序、文件系统以及网络协议堆栈而出现的各种零拷贝技术极大地提升了特定应用程序的性能，并且使得这些应用程序可以更加有效地利用系统资源。这种性能的提升就是通过在数据拷贝进行的同时，允许 CPU 执行其他的任务来实现的。

这个地方要注意得是 windows 会降低效率，因为win不开放不开源，内核里面得东西可能没法编辑修改，所以效率会比linux低

①一个read系统调用后，DMA执行了一次数据拷贝，从磁盘到内核空间
②read结束后，发生第二次数据拷贝，由cpu将数据从内核空间拷贝至用户空间
③send系统调用，cpu发生第三次数据拷贝，由cpu将数据从用户空间拷贝至内核空间(socket缓冲区)
④send系统调用结束后，DMA执行第四次数据拷贝，将数据从内核拷贝至协议引擎
⑤另外，这四个过程中，每个过程都发生一次上下文切换
内存缓冲数据，主要是为了提高性能，内核可以预读部分数据，当所需数据小于内存缓冲区大小时，将极大的提高性能。零拷贝是为了消除这个过程中冗余的拷贝同时避免了第2，3步的数据拷贝，参考下图：

3、分区
当key为空时，消息随机发送到各个分区（各个版本会有不同，有的是采用轮询的方式，有的是随机，有的是一定时间内只发送给固定partition,隔一段时间后随机换一个）
用key的ha’sh值对partion个数取模，决定要把消息发送到哪个partition上
4、批量发送
批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。
5、数据压缩
生产者 为了数据在传输到 Kafka 可以更快，那么在生产者启动压缩自然是很正常的。
Broker端 Broker 主要是负责储存数据，压缩能够很好的减少磁盘的占用。一般情况而言，如果数据已经在生产者端压缩了，那么其实就不需要在Broker端再做处理，
实际上也确实是这样，但是如果发生以下这些情况，那么Broker端会再进行压缩，这样无疑会导致性能问题，所以应该尽量避免：
Broker端指定了和Producer端不同的压缩算法，这很好理解，因为压缩算法不一致，Broker 就需要解压缩，并在此压缩成设定好的算法，所以一定要避免这种情况。
**Broker端发生了消息格式转换。**这里所谓的消息格式转换，是因为在Kafka更新的过程中，进行了一次消息格式的修改，如果生产者 和 Kafka 集群版本的消息格式不一致，那么 Broker端为了兼容考虑，会将 生产者的消息格式修改为当前版本的消息格式，而转换消息格式是必然涉及 解压缩 和 重压缩的，

6、Kafka测试及性能调优详细总结

结果分析：
1）kafka在批处理，多线程，不适用同步复制的情况下，吞吐率是比较高的，可以达26MB/s,消息数达17w条/s以上。
2）使用批处理或多线程对提升生产者吞吐率效果明显。
3）复制因子会对吞吐率产生较明显影响
使用同步复制时，复制因子会对吞吐率产生较明显的影响。复制因子为2比因子为1（即无复制）时，吞吐率下降40%左右。

4）使用sync方式，性能有明显下降。
使用Sync方式producer吞吐率会有明显下降
5)压缩与吞吐率
使用Gzip及Snappy方式压缩，吞吐率反而有下降，原因待分析。而Snappy方式吞吐率高于gzip方式。
6）分区数与吞吐率
分区数增加生产者吞吐率反而有所下降

2、消费者结果及分析

结果分析：
1）kafka consumer吞吐率在parition，threads较大的情况下，在测试场景下，最大吞吐率达到了34MB/s
2）复制因子，影响较小。replication factor并不会影响consumer的吞吐率测试， consumer从每个partition的leader读数据，而与replication factor无关。同样，consumer吞吐率也与同步复制还是异步复制无关。
3)线程数和partition与吞吐率关系
当分区数较大时，增加thread数可显著提升consumer的吞吐率。
但要注意在分区较大时线程数不改大于分区数，否则会出现No broker partitions consumed by consumer，对提升吞吐率也没有帮助。
4）批处理数对吞吐率影响
改变批处理数对吞吐率影响不大
5）压缩与吞吐率
压缩对吞吐率影响小。
段落来自于 这里–具体测试报告参考请点击这个文章，因为我是从这拷贝过来的

暂时我就先写到这吧。 如果面试能照着看一看在说那就完美了 哈哈。。。 可惜基本不会这样；
如果都能理解+实践的话 针对面试造火箭的过程应该还说的过去吧。 我感觉把这些被下来实在是太困难了。 况且还有 Redis RabbitMq ES NetCore 数据库 等面试题目需要背诵，哎太难了。 哭；

实操请点击这里