Grape，这几天对Kafka有了一点了解，看了一些书，查了一些资料。结合这些，我简单总结了一些Kafka的基础知识，作为记录~老规矩，给我们的文章抛出三个问题：什么是Kafka？有什么优点和缺点？适用范围是什么？知道的就简单想一下吧~1.什么是Kafka？首先我们看一下百度百科的定义：Kafka是Apache软件基金会开发的开源流处理平台，用Scala和Java编写。Kafka是一个高吞吐量的分布式发布-订阅消息系统，可以处理网站中消费者的所有动作流数据。这里有两个关键点：消息系统和发布订阅。那么我们就重点关注这两个方面。消息系统什么是消息系统？简单来说，它主要是一个数据采集、处理和传输的系统。数据工程最具挑战性的部分之一是如何从不同点收集大量数据并将其传输到分布式系统进行处理和分析。大量的数据需要通过消息队列进行适当的隔离，因为如果部分数据无法传递，其他数据可以在系统恢复时传输和分析。通常有两种类型的消息队列：点对点和发布者-订阅者。对于上述目的，它们既可靠又异步。发布和订阅：说到发布和订阅，我们先来看看通常存在的两种消息队列中的另一个玩家：点对点。在点对点或一对一中，有一个发送者和多个正在收听发送者的消费者。当一个消费者从队列中收到一条消息时，该特定消息将从队列中消失，其他消费者无法获取该消息。发布-订阅：一个发布者向多个同时收听发布者的消费者或订阅者发送消息，每个订阅者都可以获得相同的消息。数据应该通过数据管道传输，数据管道负责整合来自数据源的数据。也就是说，点对点只能将一条信息发送给一个人，而发布-订阅则可以将相同的信息发送给不同的人。这里不讨论哪种方法好坏，因为方法的好坏取决于业务场景。理解了定义之后，我们需要知道Kafka的结构式是什么样子的。大致是下图：我们可以看到发布-订阅模型非常清晰。以上三张图也是由浅入深。第一篇大致介绍了整个Kafka架构。我们可以看到多个发布者发送给不同的经纪人。消息，然后broker管理不同的topic，最后订阅者去不同的分区去消费消息。当然，您可能不理解发布者和订阅者等术语。我来回答几个常见的术语：(1)主题（topic）：属于特定类别的消息流称为主题。数据存储在主题中。Topic相当于Queue。主题被分成多个分区。每个这样的分区都包含一个不可变的有序消息序列。一个分区被实现为一组大小相等的段文件。(2)Partition（分区）一个Topic可以划分为多个Partition，用于并行处理。每个Partition的内部消息都是有序的，每条消息都有一个偏移序号。一个Partition只对应一个Broker，一个Broker可以管理多个Partition。(3)分区偏移量（partitionoffset）每个分区消息都有一个唯一的序列标识符，称为偏移量。(4)Replicasofpartition(分区备份)副本只是一个分区的备份。副本从不读取或写入数据。它们用于防止数据丢失。(5)Brokers：单个Kafka服务器称为“broker”。Kafka中间人接收生产者发送的消费，分配偏移量，并存储在物理空间中；同时，中间人也收到消费者的请求，并在物理空间回复消息。(6)KafkaCluster(卡夫卡集群)Kafka有多个代理，称为Kafka集群。可以在不停机的情况下扩展Kafka集群。这些集群用于管理消息数据的持久性和复制。（7）生产者（producers）：生产者是向一个或多个Kafka主题发送消息的发布者。生产者将数据发送给Kafka经纪人。每当生产者向代理发布消息时，代理只需将消息附加到最后一个段文件。实际上，消息将附加到分区。生产者还可以将消息发送到他们选择的分区。（8）Consumer（消费者）：Consumer从broker读取数据。消费者订阅一个或多个主题，并通过从代理中提取数据来消费已发布的消息。消费者维护要消费的偏移量。每个消费者都有一个对应的组。group内是队列消费模型：每个Consumer消费不同的partition，所以一条消息在group内只被消费一次。组之间存在发布-订阅消费模型：每个组独立消费，互不影响，所以一条消息每个组消费一次。对offset感兴趣的可以参考一篇关于offset的文章：KafkaOffsetManagement到此为止，总结一下。发布-订阅系统的一般过程是生产者将消息推送给代理，每个代理将消息发送到不同的主题。分区上，然后由消费者消费（当然这是最简单的模式）。注意：生产者还可以指定一个主题来将消息发送到他们选择的分区。2、有什么优点和缺点？发布/订阅系统有很多，但是Kafka哪里好呢？解耦在项目之初就预测项目未来会遇到什么需求是极其困难的。消息系统在处理中间插入了一个隐式的、基于数据的接口层，两边的处理都必须实现这个接口。这允许您独立地扩展或修改两侧的处理，只要它们遵守相同的接口约束。冗余在某些情况下，处理数据的过程会失败。除非数据被持久化，否则它会丢失。消息队列通过持久化数据直到它们被完全处理来避免数据丢失的风险。在很多消息队列采用的“插入-获取-删除”范式中，在从队列中删除消息之前，您需要您的处理系统清楚地表明该消息已被处理，以确保您的数据被安全保存。直到你用完它。可扩展性因为消息队列解耦了你的处理，所以很容易增加消息入队和处理的频率，只要你增加额外的处理。无需更改代码，无需调整参数。扩展就像打开电源按钮一样简单。灵活性&峰值处理能力在访问量急剧增加的情况下，应用仍然需要继续运行，但这种突发流量并不常见；以能够处理这种高峰访问的标准，无疑需要投入资源待命。巨大的浪费。使用消息队列可以让关键组件承受突发的访问压力，而不会因为突发的过载请求而完全崩溃。可恢复性系统的一部分发生故障不会影响整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉了，加入到队列中的消息在系统恢复后仍然可以继续处理。顺序保证在大多数使用场景中，数据处理的顺序很重要。大多数消息队列天生就是有序的，可以保证数据按照特定的顺序进行处理。Kafka保证Partition中消息的顺序。缓冲在任何重要的系统中，都会有一些元素需要不同的处理时间。例如，加载图像比应用过滤器花费的时间更少。消息队列通过缓冲层帮助任务以最大效率执行。尽快处理对队列的写入。这种缓冲有助于控制和优化数据流经系统的速度。异步通信很多时候，用户不希望或不需要立即处理消息。消息队列提供了一种异步处理机制，允许用户将消息放入队列而不立即处理。将任意多的消息放入队列，并在需要时处理它们。持久化到磁盘Kafka实际上将所有记录存储到磁盘并且不会在RAM中持久化任何内容。它保存在磁盘上的数据格式与生产者发送或发送给消费者的消息格式相同。由于磁盘存储和网络传输使用相同的消息格式，Kafka可以使用零拷贝技术将消息直接发送给消费者，避免了对已经被生产者压缩过的消息进行解压和重新压缩。3、适用范围是什么？ActivityTrackingKafka可以记录用户访问前端应用的活动日志，这也是LinkedIn开发Kafka的初衷。Kafka收集的用户点击鼠标、浏览页面、更改个人主页的事件都可以作为后端程序进行处理，成为有价值的产品。系统监控和日志可以将系统运行日志发送给Kafka，通过分析这些日志，可以对系统的各项指标进行评估。同时，Kafka记录的日志可以被其他日志分析系统消费。发送消息Kafka可以向其他应用程序发送中间件消息。例如，如果数据库发生变化，可以将变化的信息发送给应用程序。流式处理Kafka提供了对数据的流式操作，类似于Hadoop的Map/Reduce模型，可以实现数据的实时处理。其他参考文章：入门KafkaKafka基本架构介绍书籍：Kafka权威指南
