Kafka介绍
kafka topic类型
kafka topic类型摘要：1.主题介绍2.Kafka 简介3.Kafka 主题类型a.保留主题b.轮询主题c.键值主题d.顺序主题4.主题类型的应用场景5.总结正文：【主题介绍】本文将介绍Kafka 中的主题类型，帮助大家了解不同类型的主题及其应用场景。
【Kafka 简介】Kafka 是一个分布式流处理平台，主要用于构建实时数据流管道和流处理应用程序。
它具有高吞吐量、可扩展性和容错能力，广泛应用于大数据、实时计算和日志收集等领域。
【Kafka 主题类型】Kafka 中的主题（Topic）是用于存储消息的逻辑容器。
根据不同的需求，Kafka 提供了以下几种主题类型：a.保留主题（Topic with retention）: 保留主题允许你设置消息的最大保留时间。
当消息被发送到保留主题时，如果在指定的时间内没有消费者消费该消息，Kafka 会将消息从主题中删除。
这种主题类型适用于有明确过期时间的数据，如日志记录。
b.轮询主题（Topic with partition count）: 轮询主题允许你为每个分区和消费者组设置轮询偏移量。
这种主题类型适用于需要按顺序消费消息的应用程序，如消息队列。
c.键值主题（Topic with key）: 键值主题是一种特殊类型的主题，它将消息与键关联起来。
这使得消费者可以按键对消息进行分组和处理。
键值主题适用于需要对消息进行复杂查询和处理的应用程序，如实时数据仓库。
d.顺序主题（Topic with orderliness）: 顺序主题确保生产的消息按照发送顺序存储和消费。
这种主题类型适用于需要确保消息顺序的应用程序，如金融交易系统。
【主题类型的应用场景】1.保留主题：适用于有明确过期时间的数据，如日志收集。
2.轮询主题：适用于需要按顺序消费消息的应用程序，如消息队列。
3.键值主题：适用于需要对消息进行复杂查询和处理的应用程序，如实时数据仓库。
4.顺序主题：适用于需要确保消息顺序的应用程序，如金融交易系统。
kafka消息广播原理
kafka消息广播原理Kafka是一种高吞吐量的分布式发布-订阅消息系统，它被广泛应用于大数据处理、实时分析、流处理等领域。
Kafka通过其独特的消息广播机制，实现了消息的快速传递和高效处理。
本篇文档将详细介绍Kafka的广播机制原理。
一、Kafka广播机制概述Kafka的广播机制主要通过Kafka集群中的Broker节点实现。
当有新的消息产生时，生产者会将消息发送到Kafka集群中的某一个Broker节点，该节点会将消息广播到所有的订阅该主题的消费者中。
这种广播机制保证了消息的高效传递和实时性。
二、Kafka广播流程1. 生产者将消息发送到Kafka集群中的某一个Broker节点，该节点接收到消息后，将其存储到本地磁盘上。
2. Broker节点会将接收到的消息广播到所有的订阅该主题的消费者中。
具体实现方式是通过Kafka的分布式协调服务（Zookeeper）来实现。
3. 消费者接收到消息后，对其进行处理，并将结果存储到本地磁盘上。
三、Kafka广播原理分析Kafka广播机制的实现原理主要基于以下几个关键点：1. 分布式协调服务（Zookeeper）：Kafka的分布式协调服务（Zookeeper）用于维护Kafka集群的元数据，包括Broker节点的状态、Topic的配置等。
当有新的消息产生时，Broker节点会将其注册到Zookeeper中，以便消费者能够快速找到并订阅该消息。
2. Broker节点间的同步：Kafka采用了基于拉取模式的分布式协调策略，Broker节点间会定期同步彼此的状态和消息数据。
这样，当某个Broker节点接收到新的消息时，其他Broker节点也会同步收到该消息。
3. 消息负载均衡：Kafka会根据消费者的ID、分组等信息将消息分发到不同的消费者中，实现了负载均衡。
这样可以确保不同的消费者都能接收到同一份消息，避免消息的不均匀分布。
4. 消息持久化：Kafka将接收到的消息存储到本地磁盘上，并通过日志文件的形式实现了数据的持久化存储。
Kafaka详细介绍机制原理
Kafaka详细介绍机制原理1. kafka介绍1.1. 主要功能根据官⽹的介绍，ApacheKafka®是⼀个分布式流媒体平台，它主要有3种功能： 1：It lets you publish and subscribe to streams of records.发布和订阅消息流，这个功能类似于消息队列，这也是kafka归类为消息队列框架的原因 2：It lets you store streams of records in a fault-tolerant way.以容错的⽅式记录消息流，kafka以⽂件的⽅式来存储消息流 3：It lets you process streams of records as they occur.可以再消息发布的时候进⾏处理1.2. 使⽤场景1：Building real-time streaming data pipelines that reliably get data between systems or applications.在系统或应⽤程序之间构建可靠的⽤于传输实时数据的管道，消息队列功能2：Building real-time streaming applications that transform or react to the streams of data。
构建实时的流数据处理程序来变换或处理数据流，数据处理功能1.3. 详细介绍Kafka⽬前主要作为⼀个分布式的发布订阅式的消息系统使⽤，下⾯简单介绍⼀下kafka的基本机制1.3.1 消息传输流程 Producer即⽣产者，向Kafka集群发送消息，在发送消息之前，会对消息进⾏分类，即Topic，上图展⽰了两个producer发送了分类为topic1的消息，另外⼀个发送了topic2的消息。
Topic即主题，通过对消息指定主题可以将消息分类，消费者可以只关注⾃⼰需要的Topic中的消息 Consumer即消费者，消费者通过与kafka集群建⽴长连接的⽅式，不断地从集群中拉取消息，然后可以对这些消息进⾏处理。
kafka内存设置原则
Kafka内存设置原则1. 介绍Kafka是一个高性能、分布式的消息队列系统，被广泛应用于大规模数据的实时处理场景。
在使用Kafka时，合理设置内存参数对于系统的性能和稳定性至关重要。
本文将详细介绍Kafka内存设置的原则，帮助读者避免出现内存相关的问题。
2. Kafka内存参数在理解Kafka内存设置原则之前，我们首先需要了解一些相关的内存参数。
2.1 堆内存（Heap Memory）堆内存是JVM分配给Kafka Broker的内存空间，用于存储Kafka的元数据和消息等数据结构。
堆内存可以通过JVM_HEAP_OPTS参数进行设置。
2.2 直接内存（Direct Memory）直接内存是操作系统分配给Kafka Broker的内存空间，用于存储Kafka的消息缓冲区（Message Buffer）实例。
直接内存可以通过KAFKA_HEAP_OPTS参数进行设置。
2.3 操作系统文件缓存操作系统会将磁盘上的文件缓存到内存中，以加快读写速度。
Kafka Broker会利用操作系统文件缓存来加速读取和写入消息的速度。
3. Kafka内存设置原则3.1 合理设置堆内存合理设置堆内存可以避免Kafka Broker因为内存溢出而崩溃。
3.1.1 尽量不要设置过大的堆内存由于堆内存需要完全加载到JVM中，过大的堆内存可能导致JVM的GC（Garbage Collection）时间增加，从而影响Kafka Broker的性能。
3.1.2 根据实际情况设置堆内存大小堆内存的大小应根据实际负载情况进行设置。
如果Kafka Broker处理的消息量较大，可以适当增加堆内存大小；如果处理的消息量较小，可以适当减小堆内存大小。
3.1.3 使用合理的堆内存分配比例在设置堆内存大小时，可以考虑使用以下的堆内存分配比例： - 30%用于Kafka Brokers的元数据和消息等数据结构； - 70%用于Kafka Brokers的消息缓冲区实例。
kafka在实际项目中的使用
kafka在实际项目中的使用在实际项目中，Kafka是一种非常流行的分布式消息传递系统，被广泛应用于大规模数据处理、实时日志收集、事件驱动架构等场景。
它的高吞吐量、低延迟、可持久化的特性使得它成为很多企业的首选解决方案。
本文将介绍Kafka在实际项目中的使用，并探讨其主要的应用场景。
一、Kafka的介绍Kafka是由Apache软件基金会开发的一个开源项目，它是一种高吞吐量的分布式发布-订阅消息系统。
Kafka的设计目标是成为社交媒体、日志收集等领域的统一数据收集和分发源。
Kafka能够处理大规模的消息流，并将消息持久化到硬盘上，以供后续的数据处理、离线分析和实时查询等任务使用。
二、Kafka在实际项目中的使用1. 数据流处理Kafka常用于大数据流处理项目中，如实时ETL（抽取、转换、加载）、流式处理等。
Kafka以其高吞吐量的特性，能够快速、可靠地处理大量的数据流，保证数据不丢失。
2. 实时日志收集Kafka作为中间件，可用于实时日志收集和传输。
在分布式系统中，各个节点产生的日志可通过Kafka进行收集和传输，再通过日志分析工具进行处理和分析。
这样可实现对系统运行状况的实时监控，并快速发现和解决潜在问题。
3. 事件驱动架构Kafka的发布-订阅模型使其非常适合事件驱动架构。
各个服务之间可以通过Kafka进行解耦，服务之间只需要关注自己感兴趣的事件，而无需关心其他服务的操作。
这种松耦合的架构能够提高系统的可扩展性和灵活性。
4. 流媒体处理随着视频、音频等流媒体数据的快速增长，Kafka被广泛应用于流媒体处理领域。
Kafka的高吞吐量和低延迟特性使得其能够快速处理大规模的流媒体数据流，并将数据发送给消费者进行处理和展示。
5. 构建实时大数据平台众所周知，大数据分析对实时性和准确性有很高的要求。
Kafka作为数据传输和收集的中间件，可以与其他大数据处理平台（如Hadoop、Spark等）结合使用，构建起实时大数据平台，以满足各种实时数据处理和分析的需求。
kafka jvm参数
kafka jvm参数摘要：1.Kafka简介2.JVM参数的作用3.Kafka JVM参数优化建议正文：Kafka是一款高性能、可扩展的分布式消息队列系统，广泛应用于大数据处理、实时数据流分析和日志收集等场景。
Kafka在运行时，JVM参数的设置对系统的性能和稳定性有着重要影响。
本文将详细介绍Kafka JVM参数的相关知识。
JVM参数是Java虚拟机参数的简称，它影响Java程序运行时的性能和稳定性。
对于Kafka这样的Java应用程序来说，合理调整JVM参数可以提高资源利用率、提高系统性能，同时避免一些潜在的稳定性问题。
以下是一些建议的Kafka JVM参数优化设置：1.调整堆大小（-Xms和-Xmx）堆大小是JVM分配给应用程序的最大内存。
Kafka作为大数据处理系统，需要大量的堆内存来存储消息数据和元数据。
通常，可以将Kafka的堆大小设置为服务器总内存的50%-70%。
具体数值需要根据服务器实际硬件资源和Kafka的负载情况来调整。
2.启用压缩指针（-XX:+UseCompressedOops）启用压缩指针可以减少堆内存的使用，提高堆内存的利用率和垃圾回收效率。
对于Kafka这种大数据处理系统来说，可以显著减少内存消耗。
3.调整垃圾回收器（G1和CMS）Kafka在生产环境中，可以根据服务器的硬件资源和负载情况，选择合适的垃圾回收器。
G1垃圾回收器适用于大内存、高吞吐量的场景，而CMS垃圾回收器适用于对低延迟要求不高的场景。
4.调整新生代与老年代的比例（-XX:NewRatio和-XX:SurvivorRatio）调整新生代与老年代的比例可以影响垃圾回收的频率和性能。
通常，可以将新生代与老年代的比例设置为1:2，以平衡垃圾回收的性能和内存占用。
5.启用类数据共享（-XX:+UseClassDataSharing）启用类数据共享可以减少垃圾回收时的内存访问开销，提高垃圾回收性能。
对于Kafka这种大数据处理系统来说，可以显著提高性能。
kafka底层原理
kafka底层原理Kafka是一个开源分布式流处理平台，它提供了可靠的发布-订阅消息系统，以及流处理功能。
Kafka最初是由LinkedIn开发的，但现在已经成为Apache软件基金会的一部分。
Kafka的底层原理是建立在分布式系统基础之上的。
它使用主题（topic）作为消息的逻辑分组，消息可以在主题中发布和订阅。
Kafka的分布式系统使用集群来存储和处理消息，集群由多个服务器组成，每个服务器都可以处理消息，即使一台服务器出现故障，也不会影响集群的功能。
Kafka底层原理的核心是zookeeper。
zookeeper是一个高可用的分布式协调服务，它可以检测服务器的状态，使Kafka集群可以安全运行。
zookeeper可以通过临时节点（ephemeral node）来监控Kafka的节点，如果某个节点出现故障，zookeeper可以将该节点从Kafka集群中删除，以确保Kafka的高可用性。
在Kafka的底层原理中，消息传递通过分区（partition）实现。
Kafka支持多个分区，这样可以提高Kafka的吞吐量。
每个分区都有一个主副本和多个从副本，主副本负责处理消息读取，而从副本负责复制消息，以确保消息的安全性。
Kafka的底层原理还支持消息持久性，也就是说，Kafka可以将消息存储到磁盘上，并在需要时将其读取出来。
Kafka支持多种文件系统，包括本地文件系统和分布式文件系统，例如HDFS。
这样一来，Kafka可以将消息保存到不同的文件系统中，以确保数据的安全性和可用性。
Kafka的底层原理还支持消息路由（message routing）。
Kafka消息可以在不同的主题中发布和订阅，Kafka可以根据消息的内容（如标签、关键字等）来路由消息，比如，如果某个消息包含标签“news”，那么Kafka可以将该消息路由到“news”主题中。
Kafka的底层原理还支持流处理（stream processing）。
Kafka版本介绍
Kafka版本介绍1. Kafka 只是⼀个消息引擎系统吗？Apache Kafka 是消息引擎系统，也是⼀个分布式流处理平台（Distributed Streaming Platform）Kafka 在设计之初就旨在提供三个⽅⾯的特性：提供⼀套 API 实现⽣产者和消费者降低⽹络传输和磁盘存储开销实现⾼伸缩性架构批处理：批量处理冷数据，单个处理数据量⼤流处理：处理在线，实时产⽣的数据，单次处理的数据量⼩，但处理速度更快流处理要最终替代它的“兄弟”批处理需要具备两点核⼼优势：1. 要实现正确性，实现正确性是流处理能够匹敌批处理的基⽯2. 提供能够推导时间的⼯具。
正确性⼀直是批处理的强项，⽽实现正确性的基⽯则是要求框架能提供精确⼀次处理语义，即处理⼀条消息有且只有⼀次机会能够影响系统状态。
⽬前主流的⼤数据流处理框架都宣称实现了精确⼀次处理语义，但这是有限定条件的，即它们只能实现框架内的精确⼀次处理语义，⽆法实现端到端的。
l Kafka Streams 正是它提供了 Kafka 实时处理流数据的能⼒l Kafka Connect 通过⼀个个具体的连接器（Connector），串联起上下游的外部系统2. apache Kafka 流处理平台主要组件介绍Kafka Streams 正是它提供了 Kafka 实时处理流数据的能⼒Kafka Connect 通过⼀个个具体的连接器（Connector），串联起上下游的外部系统3.不同版本间的Kafka应该如何选择？1. Apache KafkaApache Kafka 是最“正宗”的 Kafka，⾃ Kafka 开源伊始，它便在 Apache 基⾦会孵化并最终毕业成为顶级项⽬，它也被称为社区版 Kafka，也就是说，后⾯提到的发⾏版要么是原封不动地继承了 Apache Kafka，要么是在此之上扩展了新功能，总之 Apache Kafka 是我们学习和使⽤ Kafka 的基础优点：是开发⼈数最多、版本迭代速度最快的 Kafka，当使⽤ Apache Kafka 碰到任何问题并提交问题到社区，社区都会⽐较及时地作出响应。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
producer
• 生产者可以发布数据到它指定的topic中，并可以 指定在topic里哪些消息分配到哪些分区（比如简 单的轮流分发各个分区或通过指定分区语义分配 key到对应分区） • 生产者直接把消息发送给对应分区的broker，而 不需要任何路由层。
• 批处理发送，当message积累到一定数量或等待 一定时间后进行发送。
message
• message（消息）是通信的基本单位，每个producer 可以向一个topic（主题）发布一些消息。如果 consumer订阅了这个主题，那么新发布的消息就会 广播给这些consumer。 • message format： message length : 4 bytes (value: 1+4+n) "magic" value : 1 byte crc : 4 bytes payload : n bytes
Kafka介绍
概述
• Kafka是Linkedin于2010年12月份开源的消息系统，它主要用于处理 活跃的流式数据。活跃的流式数据在web网站应用中非常常见，这些 数据包括网站的pv、用户访问了什么内容，搜索了什么内容等。 这 些数据通常以日志的形式记录下来，然后每隔一段时间进行一次统计 处理。传统的日志分析系统提供了一种离线处理日志信息的可扩展方 案，但若要进行实时处理，通常会有较大延迟。而现有的消（队列） 系统能够很好的处理实时或者近似实时的应用，但未处理的数据通常 不会写到磁盘上，这对于Hadoop之类（一小时或者一天只处理一部 分数据）的离线应用而言，可能存在问题。Kafka正是为了解决以上
设计特点
• 消息持久化：通过O(1)的磁盘数据结构提供消息的持久化。 • 高吞吐量：每秒百万级的消息读写。 • 分布式： Kafka是显式分布式的，多个producer、consumer和 broker可以运行在一个大的集群上，作为一个逻辑整体对外提 供服务。对于consumer，多个consumer可以组成一个group， 这个message只能传输给某个group中的某一个consumer。 • 多客户端支持：java、php、ruby、pathon、c、c++ 。 • 实时性：生产者生产的message立即被消费者可见。
的，但不连续。要计算下一消息的ID，可以在其逻辑偏移的基础上加上当前
消息的长度。 • 消费者始终从特定分区顺序地获取消息，如果消费者知道特定消息的偏移量， 也就说明消费者已经消费了之前的所有消息。消费者向代理发出异步拉请求， 准备字节缓冲区用于消费。每个异步拉请求都包含要消费的消息偏移量
Kafka构造及原理
Zookeeper的使用
• Consumers and Consumer Groups
consumers也把它们自己注册到zookeeper上，用以保持消费负载平衡和offset记 录。 group id相同的多个consumer构成一个消费租，共同消费一个topic，同一个组
的consumer会尽量均匀的消费，其中的一个consumer只会消费一个partion的数据。
Kafka构造及原理
四、 副本管理
• kafka将日志复制到指定多个服务器上。 • 复本的单元是partition。在正常情况下，每个分区有一个
leader和0到多个follower。
• leader处理对应分区上所有的读写请求。分区可以多于broker 数，leader也是分布式的。 • follower的日志和leader的日志是相同的， ollower被动的复制 leader。如果leader挂了，其中一个follower会自动变成新的
kafka组件
Kafka内是分布式的，一个Kafka集群通常包括多个broker。为了均衡负载，将话题分 成多个分区，每个broker存储一或多个分区。多个生产者和消费者能够同时生产和获 取消息。
kafka组件
topics
• 一个topic是一个用于发布消息的分类或feed名，kafka集群使用分区 的日志，每个分区都是有顺序且不变的消息序列。commit的log可以 不断追加。消息在每个分区中都分配了一个叫offset的id序列来唯一 识别分区中的消息。
consumer
• 传统消费一般是通过queue方式（消息依次被感兴趣的消费者接受）和发布 订阅的方式（消息被广播到所有感兴趣的消费者）。kafka采用一种更抽象的 方式：消费组（consumer group）来囊括传统的两种方式。首先消费者标记 自己一个消费组名。消息将投递到每个消费组中的某一个消费者实例上。如
1.探测broker和consumer的添加或移除
2.当1发生时触发每个消费者进程的重新负载。 3.维护消费关系和追踪消费者在分区消费的消息的offset。
Zookeeper的使用
• Broker Node Registry /brokers/ids/[0...N] --> host:port (ephemeral node)
topics
• 无论发布的消息是否被消费，kafka都会持久化 一定时间（可配置）。 • 在每个消费者都持久化这个offset在日志中。通 常消费者读消息时会使offset值线性的增长，但 实际上其位置是由消费者控制，它可以按任意顺 序来消费消息。比如复位到老的offset来重新处 理。 • 每个分区代表一个并行单元。
Kafቤተ መጻሕፍቲ ባይዱa构造及原理
二、 传输效率
传统方式 zero-copy
Kafka构造及原理
三、 无状态的broker
与其它消息系统不同，Kafka代理是无状态的。这意味着消费者 必须维护已消费的状态信息。这些信息由消费者自己维护，代理完全 不管。这种设计非常微妙，它本身包含了创新。 从代理删除消息变得很棘手，因为代理并不知道消费者是否已经 使用了该消息。Kafka创新性地解决了这个问题，它将一个简单的基 于时间的SLA应用于保留策略。当消息在代理中超过一定时间后，将 会被自动删除。 这种创新设计有很大的好处，消费者可以故意倒回到老的偏移量
broker启动时在/brokers/ids下创建一个znode，把broker id写进去。 因为broker把自己注册到zookeeper中实用的是瞬时节点，所以这个注 册是动态的，如果broker宕机或者没有响应该节点就会被删除。
• Broker Topic Registry /brokers/topics/[topic]/[0...N] --> nPartions (ephemeral node) 每个broker把自己存储和维护的partion信息注册到该路径下。
再次消费数据。这违反了队列的常见约定，但被证明是许多消费者的
基本特征。
Kafka构造及原理
三、 交付保证 • Kafka默认采用at least once的消息投递策略。即 在消费者端的处理顺序是获得消息->处理消息-> 保存位置。这可能导致一旦客户端挂掉，新的客 户端接管时处理前面客户端已处理过的消息。
leader.
Kafka构造及原理
Kafka构造及原理
四、 副本管理
• 和其他分布式系统一样，节点“活着”的定义在于我们能否处理一些失败情况。
kafka需要两个条件保证是“活着” 1.节点在zookeeper注册的session还在且可维护（基于zookeeper心跳机制）
2.如果是slave则能够紧随leader的更新不至于落得太远。
一、 持久化
Kafka构造及原理
二、 传输效率
• 生产者提交一批消息作为一个请求。消费者虽然利用api遍历消 息是一个一个的，但背后也是一次请求获取一批数据，从而减 少网络请求数量。 • Kafka层采用无缓存设计，而是依赖于底层的文件系统页缓存。 这有助于避免双重缓存，及即消息只缓存了一份在页缓存中。 同时这在kafka重启后保持缓存warm也有额外的优势。因kafka 根本不缓存消息在进程中，故gc开销也就很小。 • zero-copy：kafka为了减少字节拷贝，采用了大多数系统都会 提供的sendfile系统调用。如下图：
果所有的消费者实例都有相同的消费组，这样就像传统的queue方式。如果
所有的消费者实例都有不同的消费组，这样就像传统的发布订阅方式。消费 组就好比是个逻辑的订阅者，每个订阅者由许多消费者实例构成(用于扩展或 容错)。
• 相对于传统的消息系统，kafka拥有更强壮的顺序保证。kafka由于topic采用 了分区，故能够很好在多个消费者进程操作时保证顺序性和负载均衡。如下 图：
consumer
• 传统消费一般是通过queue方式（消息依次被感兴趣的消费者接受） 和发布订阅的方式（消息被广播到所有感兴趣的消费者）。kafka采 用一种更抽象的方式：消费组（consumer group）来囊括传统的两种 方式。首先消费者标记自己一个消费组名。消息将投递到每个消费组 中的某一个消费者实例上。如果所有的消费者实例都有相同的消费组， 这样就像传统的queue方式。如果所有的消费者实例都有不同的消费 组，这样就像传统的发布订阅方式。消费组就好比是个逻辑的订阅者， 每个订阅者由许多消费者实例构成(用于扩展或容错)。 • 相对于传统的消息系统，kafka拥有更强壮的顺序保证。kafka由于 topic采用了分区，故能够很好在多个消费者进程操作时保证顺序性和 负载均衡。
consumer
Kafka构造及原理
一、 持久化
• Kafka的存储布局非常简单。话题的每个分区对应一个逻辑日志。物理上，一 个日志为相同大小的一组分段文件。每次生产者发布消息到一个分区，代理 就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者经过 一定的时间后，段文件真正flush磁盘中。写入完成后，消息公开给消费者。 • 与传统的消息系统不同，Kafka系统中存储的消息没有明确的消息Id。 • 消息通过日志中的逻辑偏移量来公开。这样就避免了维护配套的密集寻址， 用于映射消息ID到实际消息地址的随机存取索引结构的开销。消息ID是增量