1、为什么要使用kafka?
- 缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。
- 解耦和扩展性：项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。
- 冗余：可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。
- 健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。
- 异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
2、kafka消费过的消息如何再消费?
kafka消费消息的offset是定义在zookeeper中的，如果想重复消费kafka的消息，可以在redis中自己记录offset的checkpoint点(n个)，当想重复消费消息时，通过读取redis中的checkpoint点进行zookeeper的offset重设，这样就可以达到重复消费消息的目的了。
3、kafka的数据是放在磁盘上还是内存上，为什么速度会快?
kafka使用的是磁盘存储。速度快是因为：
- 顺序写入：因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个"机械动作"，它是耗时的。所以硬盘"讨厌"随机I/O，喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。
- MemoryMappedFiles（内存映射文件）：64位操作系统中一般可以表示20G的数据文件,它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上。
- Kafka高效文件存储设计：Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。通过索引信息可以快速定位message和确定response的大小。通过index元数据全部映射到memory（内存映射文件），可以避免segmentfile的IO磁盘操作。通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。
注：
- Kafka解决查询效率的手段之一是将数据文件分段，比如有100条Message，它们的offset是从0到99。假设将数据文件分成5段，第一段为0-19，第二段为20-39，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中小的offset命名。这样在查找指定offset的Message的时候，用二分查找就可以定位到该Message在哪个段中。
- 为数据文件建索引，数据文件分段使得可以在一个较小的数据文件中查找对应offset的Message了，但是这依然需要顺序扫描才能找到对应offset的Message。为了进一步提高查找的效率，Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index。
在这里，给大家重点推荐一下我的几个热门畅销专栏，欢迎订阅：（博客主页还有其他专栏，可以去查看）
专栏1： （该精品技术专栏的订阅量已达到600多个，专栏中包含大量项目实战分析案例，有很强的实战参考价值，广受好评！专栏文章持续更新中，已经更新到200篇以上！欢迎订阅！）
C++软件调试与异常排查从入门到精通系列文章汇总
https://blog.csdn.net/chenlycly/article/details/125529931
本专栏根据多年C++软件异常排查的项目实践，系统地总结了引发C++软件异常的常见原因以及排查C++软件异常的常用思路与方法 ，详细讲述了C++软件的调试方法与手段，以图文并茂的方式给出具体的项目问题实战分析实例（很有实战参考价值），带领大家逐步掌握C++软件调试与异常排查的相关技术，适合基础进阶和想做技术提升的相关C++开发人员！
考察一个开发人员的水平，一是看其编码及设计能力，二是要看其软件调试能力 ！所以软件调试能力（排查软件异常的能力）很重要，必须重视起来！能解决一般人解决不了的问题，既能提升个人能力及价值，也能体现对团队及公司的贡献！
**专栏中的文章都是通过项目实战总结出来的，包含大量项目问题实战分析案例，有很强的实战参考价值！**专栏文章还在持续更新中，预计文章篇数能更新到200篇以上！
专栏2： （本专栏涵盖了C++多方面的内容，是当前重点打造的专栏，订阅量已达300多个，专栏文章已经更新到500多篇，持续更新中...）
C/C++实战进阶（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_11931267.html
以多年的开发实战为基础，总结并讲解一些的C/C++基础与项目实战进阶内容，以图文并茂的方式对相关知识点进行详细地展开与阐述！专栏涉及了C/C++领域多个方面的内容，包括C++基础及编程要点（模版泛型编程、STL容器及算法函数的使用等）、数据结构与算法、C++11及以上新特性（不仅看开源代码会用到，日常编码中也会用到部分新特性，面试时也会涉及到）、常用C++开源库的介绍与使用、代码分享（调用系统API、使用开源库）、常用编程技术（动态库、多线程、多进程、数据库及网络编程等）、软件UI编程（Win32/duilib/QT/MFC）、C++软件调试技术（排查软件异常的手段与方法、分析C++软件异常的基础知识、常用软件分析工具使用、实战问题分析案例等）、设计模式、网络基础知识与网络问题分析进阶内容等。
专栏3：
C++常用软件分析工具从入门到精通案例集锦汇总（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/131405795
常用的C++软件辅助分析工具有SPY++、PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clumsy、Windbg、IDA Pro等，本专栏详细介绍如何使用这些工具去巧妙地分析和解决日常工作中遇到的问题，很有实战参考价值！
专栏4：
VC++常用功能开发汇总（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/124272585
将10多年C++开发实践中常用的功能，以高质量的代码展现出来。这些常用的高质量规范代码，可以直接拿到项目中使用，能有效地解决软件开发过程中遇到的问题。
专栏5：
C++ 软件开发从入门到精通（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_12695902.html
根据多年C++软件开发实践，详细地总结了C/C++软件开发相关技术实现细节，分享了大量的实战案例，很有实战参考价值。
4、kafka数据怎么保障不丢失?
分三个点说，一个是生产者端，一个消费者端，一个broker端。
4.1、生产者数据的不丢失
kafka的ack机制：在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到，其中状态有0，1，-1。
如果是同步模式 ：
ack设置为0，风险很大，一般不建议设置为0。即使设置为1，也会随着leader宕机丢失数据。所以如果要严格保证生产端数据不丢失，可设置为-1。
如果是异步模式 ：
也会考虑ack的状态，除此之外，异步模式下的有个buffer，通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，有个选项是配置是否立即清空buffer。可以设置为-1，永久阻塞，也就数据不再生产。异步模式下，即使设置为-1。也可能因为程序员的不科学操作，操作数据丢失，比如kill-9，但这是特别的例外情况。
注：
- ack=0：producer不等待broker同步完成的确认，继续发送下一条(批)信息。
- ack=1（默认）：producer要等待leader成功收到数据并得到确认，才发送下一条message。
- ack=-1：producer得到follwer确认，才发送下一条数据。
4.2、消费者数据的不丢失
通过offsetcommit来保证数据的不丢失，kafka自己记录了每次消费的offset数值，下次继续消费的时候，会接着上次的offset进行消费。
而offset的信息在kafka0、8版本之前保存在zookeeper中，在0、8版本之后保存到topic中，即使消费者在运行过程中挂掉了，再次启动的时候会找到offset的值，找到之前消费消息的位置，接着消费，由于offset的信息写入的时候并不是每条消息消费完成后都写入的，所以这种情况有可能会造成重复消费，但是不会丢失消息。
唯一例外的情况是，我们在程序中给原本做不同功能的两个consumer组设置KafkaSpoutConfig、bulid-er、setGroupid的时候设置成了一样的groupid，这种情况会导致这两个组共享同一份数据，就会产生组A消费partition1、partition2中的消息，组B消费partition3的消息，这样每个组消费的消息都会丢失，都是不完整的。为了保证每个组都独享一份消息数据，groupid一定不要重复才行。
4.3、kafka集群中的broker的数据不丢失
每个broker中的partition我们一般都会设置有replication(副本)的个数，生产者写入的时候首先根据分发策略(有partition按partition,有key按key,都没有轮询)写入到leader中，follower(副本)再跟leader同步数据，这样有了备份，也可以保证消息数据的不丢失。
5、采集数据为什么选择kafka?
采集层主要可以使用Flume、Kafka等技术。
- Flume：Flume是管道流方式，提供了很多的默认实现，让用户通过参数部署，及扩展API。
- Kafka：Kafka是一个可持久化的分布式的消息队列。Kafka是一个非常通用的系统。你可以有许多生产者和很多的消费者共享多个主题Topics。
相比之下，Flume是一个专用工具被设计为旨在往HDFS，HBase发送数据。它对HDFS有特殊的优化，并且集成了Hadoop的安全特性。
所以，Cloudera建议如果数据被多个系统消费的话，使用kafka；如果数据被设计给Hadoop使用，使用Flume。
6、kafka重启是否会导致数据丢失?
kafka是将数据写到磁盘的，一般数据不会丢失。
但是在重启kafka过程中，如果有消费者消费消息，那么kafka如果来不及提交offset，可能会造成数据的不准确(丢失或者重复消费)。
7、kafka宕机了如何解决?
先考虑业务是否受到影响
kafka宕机了，首先我们考虑的问题应该是所提供的服务是否因为宕机的机器而受到影响，如果服务提供没问题，如果实现做好了集群的容灾机制，那么这块就不用担心了。
节点排错与恢复
想要恢复集群的节点，主要的步骤就是通过日志分析来查看节点宕机的原因，从而解决，重新恢复节点。
8、为什么kafka不支持读写分离?
在Kafka中，生产者写入消息、消费者读取消息的操作都是与leader副本进行交互的，从而实现的是一种主写主读的生产消费模型。Kafka并不支持主写从读，因为主写从读有2个很明显的缺点：
- 数据一致性问题：数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中A数据的值都为X，之后将主节点中A的值修改为Y，那么在这个变更通知到从节点之前，应用读取从节点中的A数据的值并不为最新的Y，由此便产生了数据不一致的问题。
- 延时问题：类似Redis这种组件，数据从写入主节点到同步至从节点中的过程需要经历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在Kafka中，主从同步会比Redis更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。
而kafka的主写主读的优点就很多了：
- 可以简化代码的实现逻辑，减少出错的可能；
- 将负载粒度细化均摊，与主写从读相比，不仅负载效能更好，而且对用户可控；
- 没有延时的影响；
- 在副本稳定的情况下，不会出现数据不一致的情况。
9、kafka数据分区和消费者的关系?
每个分区只能由同一个消费组内的一个消费者(consumer)来消费，可以由不同的消费组的消费者来消费，同组的消费者则起到并发的效果。
10、kafka的数据offset读取流程
- 1）连接ZK集群、从ZK中拿到对应topic的partition信息和partition的Leader的相关信息
- 2）连接到对应Leader对应的broker
- 3）consumer将自己保存的offset发送给Leader
- 4）Leader根据offset等信息定位到segment(索引文文件和日日志文文件)
- 5）根据索引文文件中的内容，定位到日日志文文件中该偏移量对应的开始位置读取相应长度的数据并返回给consumer
11、kafka内部如何保证顺序，结合外部组件如何保证消费者的顺序?
kafka只能保证partition内是有序的，但是partition间的有序是没办法的。爱奇艺的搜索架构，是从业务上把需要有序的打到同一个partition。
12、kafka消息数据积压，Kafka消费能力不足怎么处理?
- 如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。(两者缺一不可)
- 如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少(拉取数据/处理时间<生产速度)，使处理的数据小于生产的数据，也会造成数据积压。
13、kafka单条日志传输大小
kafka对于消息体的大小默认为单条最大值是1M但是在我们应用场景中，常常会出现一条消息大于1M，如果不对kafka进行配置。则会出现生产者无法将消息推送到kafka或消费者无法去消费kafka里面的数据，这时我们就要对kafka进行以下配置server、properties：
bash
# broker可复制的消息的最⼤字节数, 默认为1M
replica.fetch.max.bytes: 1048576
# kafka 会接收单个消息size的最⼤限制， 默认为1M左右
message.max.bytes: 1000012注意：message、max、bytes必须小于等于replica、fetch、max、bytes，否则就会导致replica之间数据同步失败。