高并发面试必问：分布式消息系统Kafka简介
卡夫卡是分布式发布 - 订阅消息系统它最初由LinkedIn公司开发，之后成为Apache的项目的一部分.Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务它主要用于处理。活跃的流式数据。
在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能，低延迟的不停流转。传统的企业消息系统并不是非常适合大规模的数据处理为了已在同时搞定在线应用（消息）和离线应用（数据文件，日志）卡夫卡就出现了.Kafka可以起到两个作用：
- 降低系统组网复杂度。
- 降低编程复杂度，各个子系统不在是相互协商接口，各个子系统类似插口插在插座上，卡夫卡承担高速数据总线的作用。
卡夫卡主要特点：
- 同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。
- 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及复制防止数据丢失。
- 分布式系统，易于向外扩展。所有的制片人，经纪人和消费者都会有多个，均为分布式的。无需停机即可扩展机器。
- 消息被处理的状态是在消费端维护，而不是由服务器端维护。当失败时能自动平衡。
- 支持在线和离线的场景。
卡夫卡的架构：
Kayka的整体架构非常简单，是显式分布式架构，制作人，经纪人（卡夫卡）和消费者都可以有多个.Producer，消费者实现卡夫卡注册的接口，数据从生产者发送到经纪人，经纪人承担一个中间缓存和分发的作用.broker分发注册到系统中的consumer.broker的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。客户端和服务器端的通信，是基于简单，高性能，且与编程语言无关的TCP协议几个基本概念：
- 主题：特指Kafka处理的消息源（消息的来源）的不同分类。
- 分区：主题物理上的分组，一个话题可以分为多个分区，每个分区是一个有序的队列.partition中的每条消息都会被分配一个有序的ID（偏移）。
- 消息：消息，是通信的基本单位，每个生产商可以向一个主题（主题）发布一些消息。
- 制片人：消息和数据生产者，向卡夫卡的一个主题发布消息的过程叫做生产者。
- 消费者：消息和数据消费者，订阅主题并处理其发布的消息的过程叫做消费者。
- 经纪人：缓存代理，卡夫卡集群中的一台或多台服务器统称为经纪人。
消息发送的流程：
- 生产者根据指定的分区方法（循环赛，哈希等），将消息发布到指定主题的分区里面
- 卡夫卡集群接收到生产者发过来的消息后，将其持久化到硬盘，并保留消息指定时长（可配置），而不关注消息是否被消费。
- 消费者从卡夫卡集群拉数据，并控制获取消息的偏移
Kayka的设计：
1，吞吐量
高吞吐是卡夫卡需要实现的核心目标之一，为此卡夫卡做了以下一些设计：
- 数据磁盘持久化：消息不在内存中缓存，直接写入到磁盘，充分利用磁盘的顺序读写性能
- 零拷贝：减少IO操作步骤
- 数据批量发送
- 数据压缩
- 主题划分为多个分区，提高并行
2，负载均衡
- 生产者根据用户指定的算法，将消息发送到指定的分区
- 存在多个partiiton，每个分区有自己的副本，每个副本分布在不同的代理节点上
- 多个分区需要选取出引导分区，引导分区负责读写，并由zookeeper负责进行故障转移
- 通过动物园管理员管理经纪人与消费者的动态加入与离开
3，拉取系统
由于kafka broker会持久化数据，经纪人没有内存压力，因此，消费者非常适合采取拉的方式消费数据，具有以下几点好处：
- 简化卡夫卡设计
- 消费者根据消费能力自主控制消息拉取速度
- 消费者根据自身情况自主选择消费模式，例如批量，重复消费，从尾端开始消费等
如图4所示，可扩展性
当需要增加券商结点时，新增的经纪人会向饲养员注册，而生产者及消费者会根据注册在饲养员上的观察者感知这些变化，并及时作出调整。
Kayka的应用场景：
1，消息队列
比起大多数的消息系统来说，卡夫卡有更好的吞吐量，内置的分区，冗余及容错性，这让卡夫卡成为了一个很好的大规模消息处理应用的解决方案。消息系统一般吞吐量相对较低，但是需要更小的端到端延时，并尝尝依赖于卡夫卡提供的强大的持久性保障。在这个领域，卡夫卡足以媲美传统消息系统，如ActiveMR或RabbitMQ的。
2，行为跟踪
卡夫卡的另一个应用场景是跟踪用户浏览页面，搜索及其他行为，以发布 - 订阅的模式实时记录到对应的话题里那么这些结果被订阅者拿到后，就可以做进一步的实时处理，或。实时监控，或放到的hadoop /离线数据仓库里处理。
3，元信息监控
作为操作记录的监控模块来使用，即汇集记录一些操作信息，可以理解为运维性质的数据监控吧。
4，日志收集
日志收集方面，其实开源产品有很多，包括Scribe，Apache Flume。很多人使用Kafka代替日志聚合（log aggregation）。日志聚合一般来说是从服务器上收集日志文件，然后放到一个集中的位置（文件）服务器或HDFS）进行处理。然而卡夫卡忽略掉文件的细节，将其更清晰地抽象成一个个日志或事件的消息流。这就让卡夫卡处理过程延迟更低，更容易支持多数据源和分布式数据处理。比起以日志为中心的系统比如抄写或者水槽来说，卡夫卡提供同样高效的性能和因为复制导致的更高的耐用性保证，以及更低的端到端延迟。
5，流处理
这个场景可能比较多，也很好理解。保存收集流数据，以提供之后对接的风暴或其他流式计算框架进行处理。很多用户会将那些从原始的话题来的数据进行阶段性处理，汇总，扩充或者以其他的方式转换到新的主题下再继续后面的处理。例如一个文章推荐的处理流程，可能是先从RSS数据源中抓取文章的内容，然后将其丢入一个叫做“文章”的话题中;后续操作可能是需要对这个内容进行清理，比如回复正常数据或者删除重复数据，最后再将内容匹配的结果返还给用户这就在一个独立的话题之外，产生了一系列的实时数据处理的流程.Strom和Samza是非常著名的实现这种类型数据转换的框架。
6，事件源
事件源是一种应用程序设计的方式，该方式的状态转移被记录为按时间顺序排序的记录序列.Kafka可以存储大量的日志数据，这使得它成为一个对这种方式的应用来说绝佳的后台。比如动态汇总（新闻提要）。
7，持久性日志（commit log）
卡夫卡可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据回复提供一种重新同步的机制.Kafka中日志压缩功能为这种用法提供了条件。在这种用法中，Kafka类似于Apache BookKeeper项目。
Kayka的设计要点：
1，直接使用linux文件系统的缓存，来高效缓存数据。
2，采用linux零拷贝提高发送性能。传统的数据发送需要发送4次上下文切换，采用sendfile系统调用之后，数据直接在内核态交换，系统上下文切换减少为2次。根据测试结果，可以提高60 ％的数据发送性能.Zero-复制详细的技术细节可以参考：HTTPS：//www.ibm.com/developerworks/linux/library/j-zerocopy/
3，数据在磁盘上存取代价为O（1）.kafka以主题来进行消息管理，每个主题包含多个部分（银行足球比赛），每个部分对应一个逻辑日志，有多个区段组成。每个段中存储多条消息（见下图），消息ID由其逻辑位置决定，即从消息ID可直接定位到消息的存储位置，避免ID到位置的额外映射。每个部分在内存中对应一个索引，记录每个区段中的第一条消息偏移。发布者发到某个主题的消息会被均匀的分布到多个部分上（随机或根据用户指定的回调函数进行分布），代理收到发布消息往对应部分的最后一个段上添加该消息，当某个段上的消息条数达到配置值或消息发布时间超过阈值时，段上的消息会被冲洗到磁盘，只有刷新到磁盘上的消息订阅者才能订阅到，段达到一定的大小后将不会再往该段写数据，代理会创建新的段。
4，显式分布式，即所有的制片人，经纪人和消费者都会有多个，均为分布式的.Producer和经纪人之间没有负载均衡机制.broker和消费者之间利用饲养员进行负载均衡。所有经纪人和消费者都会在动物园管理员中进行注册，且动物园管理员会保存他们的一些元数据信息。如果某个经纪人和消费者发生了变化，所有其他的经纪人和消费者都会得到通知。
1，请说明什么是Apache Kafka？
Apache Kafka是由Apache开发的一种发布订阅消息系统，它是一个分布式的，分区的和重复的日志服务。
2，请说明什么是传统的消息传递方法？
传统的消息传递方法包括两种：
-
排队：在队列中，一组用户可以从服务器中读取消息，每条消息都发送给其中一个人。
-
发布 - 订阅：在这个模型中，消息被广播给所有的用户。
3，请说明卡夫卡相对传统技术有什么优势？
Apache Kafka与传统的消息传递技术相比优势之处在于：
快速：单一的卡夫卡代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。
可伸缩：在一组机器上对数据进行分区和简化，以支持更大的数据
持久：消息是持久性的，并在集群中进行复制，以防止数据丢失。
设计：它提供了容错保证和持久性
4，在卡夫卡中券商的意义是什么？
在卡夫卡集群中，经纪人术语用于引用服务器。
5，卡夫卡服务器能接收到的最大信息是多少？
卡夫卡服务器可以接收到的消息的最大大小是百万字节。
6，解释卡夫卡的动物园管理员是什么？我们可以在没有动物园管理员的情况下使用卡夫卡吗？
动物园管理员是一个开放源码的，高性能的协调服务，它用于卡夫卡的分布式应用。
不，不可能越过Zookeeper，直接联系Kafka broker。一旦Zookeeper停止工作，它就不能服务客户端请求。
-
动物园管理员主要用于在集群中不同节点之间进行通信
-
在卡夫卡中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取
-
除此之外，它还执行其他活动，如：leader检测，分布式同步，配置管理，识别新节点何时离开或连接，集群，节点实时状态等等。
7，解释卡夫卡的用户如何消费信息？
在Kafka中传递消息是通过使用sendfile API完成的。它支持将字节从套接口转移到磁盘，通过内核空间保存副本，并在内核用户之间调用内核。
8，解释如何提高远程用户的吞吐量？
如果用户位于与经纪人不同的数据中心，则可能需要调优套接口缓冲区大小，以对长网络延迟进行摊销。
9，解释一下，在数据制作过程中，你如何能从卡夫卡得到准确的信息？
在数据中，为了精确地获得Kafka的消息，你必须遵循两件事：在数据消耗期间避免重复，在数据生产过程中避免重复。
这里有两种方法，可以在数据生成时准确地获得一个语义：
-
每个分区使用一个单独的写入器，每当你发现一个网络错误，检查该分区中的最后一条消息，以查看您的最后一次写入是否成功
-
在消息中包含一个主键（UUID或其他），并在用户中进行反复制
10，解释如何减少ISR中的扰动？经纪人什么时候离开ISR？
ISR是一组与领导者完全同步的消息副本，也就是说ISR中包含了所有提交的消息的.isr应该总是包含所有的副本，直到出现真正的故障。如果一个副本从领导中脱离出来，将会从ISR中删除。
11，卡夫卡为什么需要复制？
卡夫卡的信息复制确保了任何已发布的消息不会丢失，并且可以在机器错误，程序错误或更常见些的软件升级中使用。
12，如果副本在ISR中停留了很长时间表明什么？
如果一个副本在ISR中保留了很长一段时间，那么它就表明，跟踪器无法像在领导者收集数据那样快速地获取数据。
13，请说明如果首选的副本不在ISR中会发生什么？
如果首选的副本不在ISR中，控制器将无法将领导转移到首选的副本。
14，有可能在生产后发生消息偏移吗？
在大多数队列系统中，作为生产者的类无法做到这一点，它的作用是触发并忘记消息.broker将完成剩下的工作，比如使用ID进行适当的元数据处理，偏移量等。
作为消息的用户，你可以从Kafka broker中获得补偿。如果你注视SimpleConsumer类，你会注意到它会获取包括偏移量作为列表的MultiFetchResponse对象。此外，当你对Kafka消息进行迭代时，你会拥有包括偏移量和消息发送的MessageAndOffset对象。