精华内容
参与话题
问答
  • 通过上图,我们可以大概了解到一点,Kafka是通过主题进行对数据进行分类的,而一个主题可以划分为多个partition分区,同一topic的不同partition可能分布在不同机器上,进而实现分布式高性能的特点。对于partition在...

    4. Kafka 存储形式

    4.1 存储结构

    image-20201104154440754

    通过上图,我们可以大概了解到一点,Kafka是通过主题进行对数据进行分类的,而一个主题可以划分为多个partition分区,同一topic的不同partition可能分布在不同机器上,进而实现分布式高性能的特点。对于partition在系统中是一个文件夹,其中可能包含多个segment。

    我们可以设置segment在内存中的大小,当保存的消息大于segment的大小时,会再建一个segment。一个segment段由三个文件组成,分别为 .log , .index , .timeindex .

    topic结构

    • topic包含多个partition,
    • topic只是逻辑概念,不涉及到存储,partition才是物理概念
    • 同一topic的不同partition可能分布在不同机器上

    partition结构

    • partition是一个文件夹,其中包含多个segment
    • 如果其中有n个segment,则共有2*n个文件
    • 每个partition是一个有序的队列
    • partition中的每条消息都会分配一个有序的id,即offset

    segment结构

    • 由一对文件组成,一个稀疏索引文件(.index),一个数据文件(.log),一个时间索引文件(.timeindex)
    • 文件命名规则
      • 上一个segment在partition中的最大offset数值,即,比如00000000000000345678.log文件中的第一条消息的offset为345679
      • 最大为64位的long,不足位数补0,如00000000000000345678.log
      • 索引文件后缀.index,日志数据文件后缀.log

    segment索引文件结构

    • 存储一系列的元数据,每条元数据就是一条索引
    • 元数据条数小于消息条数,是稀疏索引
    • 元数据(即索引)构成
      • 索引所指向的message在数据日志文件中的相对序号,即相对的offset,从1开始,该相对offset加上文件名当中的值就是该message在整个partition中的绝对offset了
      • 索引所指向的message在数据日志文件中的位置,即文件游标,从0开始,方便直接指定游标打开数据文件

    segment日志数据文件结构

    • 存储一系列的message

    message结构

    • offset 偏移量,消息的唯一标识,通过offset能找到唯一消息,类型long 8bytes
    • MessageSize 消息长度,类型int32 4bytes
    • crc32校验码, 4bytes,校验message
    • magic, 表示本次发布kafka服务程序协议版本号 1byte
    • attributes 独立版本,标识压缩类型,编码类型 1byte
    • key length 4bytes 当key length=-1时,key字段可不写
    • key 可选
    • payload 实际消息内容

    message特点

    • message是无状态的,即不会标识是否已被消费过
    • message不能同时被多个consumer来消费,可以等前一个消费完成,下一个继续消费。
    • consumer可以同时消费多条message

    4.2 kafka如何实现高并发存储-如何找到一条需要消费的数据(阿里)

    kafka的底层用了稀疏索引的方式,使用了二分查找法,其实很多索引都是二分查找法。 二分查找法的时间复杂度:O(logn)。除了Kafka外,其实 redis,B+树的底层都采用了二分查找法

    参考: redis的索引底层的 跳表原理 实现 聊聊Mysql索引和redis跳表 —redis的跳表原理 (阿里)

    参考: :一步步分析为什么B+树适合作为索引的结构 以及索引原理 (阿里面试)

    参考::各种排序算法的时间复杂度和空间复杂度(阿里)

    在partition中如何通过offset查找message?

    我们都知道,Kafka消费者读取数据时,只需要通过一个offset就可以精准的拉取数据,例如读取offset=368776的message,需要通过下面2个步骤查找。

    第一步查找segment file

    image-20201106142619322

    上述图2为例,

    其中第一个文件00000000000000000000.index表示最开始的文件,起始偏移量(offset)为0. 第二个文件00000000000000368769.index的消息量起始偏移量为368770 = 368769 + 1. 同样,第三个文件00000000000000737337.index的起始偏移量为737338=737337 + 1,其他后续文件依次类推,以起始偏移量命名并排序这些文件,只要根据offset 二分查找文件列表,就可以快速定位到具体文件。

    当offset=368776时定位到00000000000000368769.index|log

    第二步通过segment file查找message

    通过第一步定位到segment file,当offset=368776时,依次定位到00000000000000368769.index的元数据物理位置和 00000000000000368769.log的物理偏移地址,然后再通过00000000000000368769.log顺序查找直到 offset=368776为止。

    从上述图3可知这样做的优点,segment index file采取稀疏索引存储方式,它减少索引文件大小,通过mmap可以直接内存操作,稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间,但查找起来需要消耗更多的时间。

    展开全文
  • 数据存储结构Kafka中的Message是以topic为基本单位组织的,不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的),每个partition存储一部分...

    数据存储结构:

    Kafka中的Message是以topic为基本单位组织的,不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的),每个partition存储一部分Message。


    partition是以文件的形式存储在文件系统中,比如,创建了一个名为page_visits的topic,其有5个partition,那么在Kafka的数据目录中(由配置文件中的log.dirs指定的)中就有这样5个目录: page_visits-0, page_visits-1,page_visits-2,page_visits-3,page_visits-4,其命名规则为<topic_name>-<partition_id>,里面存储的分别就是这5个partition的数据。

    Partition中的每条Message由offset来表示它在这个partition中的偏移量,这个offset不是该Message在partition数据文件中的实际存储位置,而是逻辑上一个值,它唯一确定了partition中的一条Message。类似于下面的一个图片,消息存储在每个log文件中,index对应的是消息的索引信息,另外,为了让消息消费的时候更快,又将文件分成很多段。

     

    数据消费查询:

       我们要查询 offset 为7的消息,那kafka就会快速定位到这个index文件,得知offset 为7的消息在6,9807后面,这时候就可以通过9807快速定位到数据文件,然后从位置为9807的那个地方开始顺序扫描直到找到offset为7的那条Message。

      

     

    转载于:https://www.cnblogs.com/leochenliang/p/10082120.html

    展开全文
  • 一、为什么选择Kafka 为什么选Kafka?鉴于庞大的数据量,需要将其做成分布式,这时需要将Q里面的数据分到许多...Realtime的Kafka集群通过Mirror Maker将数据全部同步到Analysis的Kafka集群。 Realtime的Kafka集群主...

    一、为什么选择Kafka

    为什么选Kafka?鉴于庞大的数据量,需要将其做成分布式,这时需要将Q里面的数据分到许多机器上进行存储,除此之外还有分布式的计算需求。同时需要支持多语言,如Java、GO、php等,另外还有高可用的需求。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    二、Kafka集群

    Realtime的Kafka集群通过Mirror Maker将数据全部同步到Analysis的Kafka集群。

    Realtime的Kafka集群主要负责在线实时读写,Analysis负责很多工作,诸如数据的导入导出,数据的多次流出给集群和网络硬盘带来了较大压力。为保证线上的稳定性,要保证两边是隔开的。另外关于Topic目前有五万多,每秒可能会有100多万的数据流入流出。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    三、Kafka的用户使用问题

    1.参数配置问题, Kafka有很多参数需要配置,常用的集群配置,延迟,重要性等,需要封装。

    1. 开发测试不方便,使用者通常会有这样的需求:我的数据写进去没,消费没,他写的数据长什么样子,结构化的数据还需自己写代码来解析,等等。这些问题没有工具和平台来解决,会大大降低开发效率。

    2. Topic申请不方便,topic是不能开放自己创建的,我们曾在测试环境开放过Topic,发现一周内涨到了好几万,而且参数千奇百怪,有全用默认参数的,有根据文档,时间先来10个9的,也有partition直接来100的。工单方式对管理者很不友好,需要登上服务器敲命令,效率低下,且容易出错。

    3. 结构化数据查询不方便,瓜子的结构化使用的是AVRO, 序列化之后的数据很难查看原始数据。

    4. 消费异常定位不便,比如消费的数据或者位置不对,如果想要回滚重新消费或跳过脏数据就面临各种问题。从哪个offset开始重新消费呢?或者跳到之后的哪个offset呢?另外就是滚动重启了一个服务,结果发现消费的数据少了一批,很有可能是某一个隐藏的consumer同时在用这个consumer group,但是找了一圈没找到哪个服务还没关掉。

    5. 不知道下游,如果写了生产者生产的Topic数据,却不知道有哪些consumer,如果要对Topic信息发生改变时,不知该通知谁,这是很复杂的事情。要么先上,下游出问题了自己叫,要么踌躇不前,先收集下游,当然实际情况一般是前者,经常鸡飞狗跳。

    6. 运维复杂,日常运维包括topic partition增加,帮助定位脏数据(因为他们不知道有脏数据),帮助排除配置问题等等。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    四、解决方案:Kafka platform

    为解决上述问题,瓜子上线了Kafka platform,主要面向用户和管理两方面的功能。

    面向用户包括:查看数据,了解消费情况,方便地添加监控报警,以及如果出现问题后,快速查错的工具。

    管理方面包括: 权限管理, 申请审批,还有一些常用操作。比如,seek offset, 或是删掉一个Topic,对partitions进行扩容等。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    1. 数据查询

    可以通过offset查询对应offset的数据,也可以通过进入Kafka的大致时间,查询那段内的数据,可以看到每条信息的partition,offset,入Kafka的时间,AVRO的版本信息等。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    1. 消费查询

    通过下图显示的界面可以查看一条消息,了解哪些consumer group已经消费了,哪些没有消费。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    同时可以查看它现在正在被哪个IP进行消费,这时我们可以方便地定位到有个consumer没有关闭,它是在哪台机器上,这些来自于我们的实践经验。还可以看到每个consumer group的消费延迟情况,精确到条数,partition的延迟。也可以看到partition消息总数,可以排查一些消息不均的问题。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    下图为监控报警,可以了解Topic的流入、流出数据,每秒写入多少条消息,多大的size,每秒流出的情况。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    报警是对Topic建一些流量报警,或是一些延迟报警,建好之后只需要订阅一下即可,非常方便。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    五、瓜子结构化数据流

    目前有许多使用场景,比如前端埋点,tracking日志,Mysql数据同步,操作日志,一些诸如服务之间的交换,基于SQL的streaming,APM的数据,还有基于SQL的ETL等,都可以通过结构化将其快速同步到大数据中做后续分析。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    我们是通过confluent提供的一整套解决方案来实现的。其中最主要的两个组件是:Schema Registry和Kafka Connect。Schema Registry用于存储schema信息,Kafka connect用于数据转移。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    目前,瓜子除日志部分外,90%以上为结构化。为什么选择Avro?因为Avro速度快,并且跨语言支持,所有的Schema AVSC都是用JSON做的,对JSON支持的特别好,如果可能没人想为一个schema定义再学一门语言吧。而且通过JSON无需code generation。

    但仅有avro还不够,我们在使用中会面临更多的问题,比如:

    • 统一的schema中心,这与配置中心的必要性是一样的道理,没有统一的地方,口口相传,配置乱飞不是我们想看到的。

    • 多版本的需求,schema是肯定会有更新需求的,也肯定有回滚需求,也会有兼容需求,所以多版本是需要满足的。

    • 版本兼容性检查,设想一下上游改了一个schema的列名,下游写到hive的时候就蒙了,历史数据咋办啊,现在这列数据又怎么处理。所以得有版本兼容,而且最好满足下游所有组件的需求。

    • schema得有注释,给人展示的schema最好能有给人读的注释,很多人昨天定义的enum,今天就忘了,这个事情很常见。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    为解决这些问题,我们引入了confluence的Schema Registry。Confluence的Schema registry,通过RESTful接口,提供了类似配置中心的能力,还有完善的UI,支持版本兼容性检查,支持多版本等,完全满足了我们的需求。而且自带HA,通过Kafka存储配置信息,保证一致性。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    五、瓜子的实践

    当然,仅有这些还不够,我们在实践中遇到了很多问题,比如schema注册不可能完全开放,历史告诉我们完全的自由意味着混乱。为在实践中利用好avro,我们前后改了两个方案,来保证schema可控。

    1. 最初的方案

    为实现统一管控,所有schema会通过git来管理,如果需要使用可以fork该git。如果要做一个上线,更新或添加一个schema,可以通过提merge request提交给管理员。管理员检查没有问题后直接通过gitlab-ci自动注册,管理员只需完成确认的操作。

    但这样会出现一些问题,首先是上线流程太长,要上线或更新一个schema时,需要提交merge request,要等管理员收到邮件后才可查看,届时如果管理员发现schema写的不对,还需重新再走一次流程,中间可能花一天时间。且回滚复杂,没有权限管理。而且很多人会犯同样的错误,客服表示相当的浪费时间。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    六、平台化解决方案

    通过平台化解决方案,我们提供了一个类似于git的页面,可在上面直接提交schema,在下面直接点击校验,在评估新上线的schema是否有问题后,等待后台审批即可。其中可以加诸如权限管理等一些功能。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    七、为什么用到Kafka connect

    Kafka connect专注copy数据,把一个数据从data source转到Kafka,再从Kafka转到其它地方。它支持批和流,同时支持实时和批处理,比如5min同步一次。

    另外,它支持多个系统之间互相copy,数据源可能是Mysql、SQL Server 也可能是Oracle 。sink可以是Hbase、Hive等。它自己定义了一套plugin接口,可以自己写很多数据源和不支持的sink。

    并且他自己做到了分布式并行,支持完善的HA和load balance,还提供方便的RESTful 接口。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    在没有Kafka connect之前,运维ETL非常麻烦。拿canal来说,canal有server和client,都需手动部署,如果你有100台canal节点1000个数据库,想想看吧,管理员如何知道哪台机器上跑了哪些库表,新增的任务又放在哪台机来运行。

    此外,如果Mysql修改了一个字段,还需要让程序员去机器上看一下那张表是如何修改的,相应的所有下游都需相应的完成表结构修改之后, 才能跑起来,响应速度非常慢。

    目前Kafka connect已经解决了这些问题。其具备一个非常重要的特性,如果上游数据根据AVRO兼容性进行的修改,connect会在下游同样做一些兼容性的修改,自动更改下游表结构,减轻了运维负担。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    我们来看看Kafka connect 的架构,Kafka connect会把所有信息存到Kafka 中,其中config topic存元数据,Stutas topic指当前哪些节点正在跑什么样的job,offset topic指当前比如某个Topic的某个partitions到底消费到哪条数据。

    WorKer都是无状态的,在上面可以跑许多task,同样一个task1,可能对应5个partitions,如果只给它三个并发,它会分布在三台机器上。如果一台机器挂了,这些job都会分配到另外两台机器,而且是实时同步的。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    八、瓜子Plugins

    瓜子对Kafka connect的很多plugins做了修改。

    1. Maxwell

    其中我们把canal通过maxwell替换,并且把maxwell做成了Kafka connect的plugin。

    原生的Maxwell不支持AVRO,瓜子通过debezium思想对Maxwell进行了修改,使其支持avro格式,并用Mysql管理meta,并且支持Mysql的数据库切换。

    1. HDFS

    我们采用的是confluence公司的hdfs插件,但是其本身存在很多问题,比如写入hive的时候会把当做partition的列也写到主表数据中,虽然不影响hive的使用,但是影响presto读取hive,这里我们改了源码,去掉了主表中的这些列。

    Hdfs在插件重启时会去hdfs中读取所有文件来确定从哪个offset继续,这里会有两个问题:耗时太长,切换集群时offset无法接续,我们也对他做了修改。

    plugin写入hive时支持用Kafka的timestamp做分区,也支持用数据内的某些列做分区,但是不支持两者同时用,我们也修改了一下。

    1. HBase

    Hbase的plugin只支持最原始的导出,我们会有些特殊的需求,比如对rowkey自定义一下,通常mysql主键是自增ID,hbase不推荐用自增ID做rowkey,我们会有reverse的需求,还有多列联合做rowkey的需求等,这个我们也改了源码,支持通过配置自定义rowkey生成。

    原始plugin不支持kerberos,而我们online hbase是带权限的,所以也改了一下

    还有一些小功能,比如把所有类型都先转成string再存,支持delete,支持json等。

    1. KUDU

    我们对kudu的使用很多,kudu开源的plugin有些bug,我们发现后也fix了一下。

    Kudu的数据来源都是mysql,但是经常会有mysql刷库的情况,这时量就会很大,kudu sink会有较大的延时,我们改了一下plugin,添加了自适应流量控制,自动扩充成多线程处理,也会在流量小时,自动缩容。

    九、瓜子数据库的Data Pipeline

    瓜子的数据仓库完全是基于Kafka、AVRO的结构化数据来做的。数据源非常多,需要将多个业务线的几千张表同步到数仓,对外提供服务。

    整个数据仓库采用Lambda架构,分为T+1的存量处理和T+0.1的增量处理两个流程。

    先说T+1的存量处理部分,目前瓜子将所有mysql表通过Maxwell插件放到Kafka中,再通过Kafka connect写到Hbase里,Hbase每天晚上做一次snapshot(快照),写到hive中,然后经过多轮ETL:DWB-->DWD-->DW-->DM,最后将DM层数据导入Kudu中,对外提供BI分析服务,当然离线olap分析还是通过presto直接访问Hive查询。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    再说T+0.1的增量流程,同T+1一样,数据通过maxwell进入Kafka,这部分流程共用,然后增量数据会实时通过kudu的插件写入kudu中,再通过impala做ETL,生成数据对外提供T+0.1的查询,对外提供的查询是通过另一套impala来做的。 未来我们还会考虑通过Flink直接读取Kafka中数据来做实时ETL,提高实时性。

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    这是我们数仓架构的整体架构图

    DataPipeline丨瓜子二手车基于Kafka的结构化数据流

    转载于:https://blog.51cto.com/13905119/2386681

    展开全文
  • Docker安装Kafka,su进入管理员界面,由于kafka服务需要依赖注册zookeeper服务, 首先需要安装zookeeper。输入命令docker pull zookeeper,此时默认的是最新版本laster,如果要安装指定版本镜像文件,可到docker hub...
    本列采用Orcale VM软件安装Centos7虚拟机,相关分配内存/显存大小1024M/12M.

    Docker安装Kafka,su进入管理员界面,由于kafka服务需要依赖注册zookeeper服务, 首先需要安装zookeeper。输入命令docker pull zookeeper,此时默认的是最新版本laster,如果要安装指定版本镜像文件,可到docker hub上查询指定镜像对应版本号,比如docker pull zookeeper:3.2.1。本文直接拉取最新版本,需要注意的是,拉取之前最好配置docker镜像源地址 1、如何配置镜像源地址: 输入如下命令,编辑 docker 的 daemon.json 配置文件vi /etc/dock

    阅读全文: http://gitbook.cn/gitchat/activity/5e59cbc19692000e8e26a03e

    您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ,阅读更多 GitChat 专享技术内容哦。

    FtooAtPSkEJwnW-9xkCLqSTRpBKX

    展开全文
  • Kafka 体系结构

    千次阅读 2014-09-03 21:42:11
    总的来说就是消息的生产者(producer)发送消息到某个主题(topic),消息的消费者(consumer)从这个主题中接收数据。其中 kafka 集群(cluster)可以由多个服务器组成,每个服务器称之为代理(broker). -- 更多参见:...
  • 参考:
  • 通过本模块的学习,能够掌握Kafka的负载均衡、Producer生产数据Kafka文件存储机制、Kafka自定义partition 课程大纲: 1、 Kafka整体结构图 2、 Consumer与topic关系 3、 Kafka Producer消息分发
  • Kafka整体结构以及模块分析

    千次阅读 2016-07-06 15:26:58
    一、Kafka源代码的工程结构 如下图所示:     二、各模板简要说明 admin:管理员模块,操作和管理topic,paritions相关,包含create,delete topic,扩展patitions Api:该模块主要负责交互数据的组装,...
  • 1.topic注册信息 路径/brokers/topics/[topic] : {  "version": 1,  "partitions": {"0": [0, 1, 3] } } } 2.分区状态信息 路径/brokers/topics/[topic]/partitions/[partitionId]... 
  • 文 |彭超 瓜子大数据架构师交流微信 | datapipeline2018本文整理自丨4月13日,DataPipeline联合Apache RocketMQ在北京举办的消息中间件Meetup为什么选择Kafka为什么选Kafka?鉴于庞大的数据量,需要将其做成分布式,...
  • Kafka中的Message是以topic为基本单位组织的,不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的),每个partition存储一部分Message。借用官方...
  • kafka内部结构笔记

    2017-09-01 17:11:00
    在系统架构中,将消息系统独立可起到架构解耦、易扩展、灵活性强、可恢复、数据冗余、异步通讯等优点。 kafka是分布式消息系统软件,实现了消息发布/订阅功能。还有一些其他的消息队列软件,比如RabbitMQ、Redis、...
  • kafka数据可靠性深度解读一、概述二、Kafka体系结构三、高可靠性存储分析1.Kafka文件存储机制2.复制原理和同步方式3.ISR4.数据可靠性和持久性保证5.关于HW的进一步探讨6.Leader选举7.Kafka的发送模式四、高可靠性...
  • {"card_count":[{"count_phone":1,"count":1}],"search_count":[{"count_phone":4,"count":4}]},"card":[{"des":"阿里云数据库专家保驾护航,为用户的数据库应用系统进行性能和风险评估,参与配合进行数据压测演练,...
  • Kafka数据一致性

    2018-10-06 22:05:40
    文章目录数据存储Topic逻辑结构多Parition的优点/缺点Partition存储结构根据offset查找msg的过程Partition recovery过程数据的同步数据数据可靠性保证数据一致性保证HDFS数据组织 数据存储 Topic逻辑结构 Top...
  • tianjinsong2016-10-31 21:03:136141收藏 展开 http://yonghuiyang.github.io/2015/12/04/kafka_data_store/ 数据存储 ...Topic逻辑结构 Topic可分为多个Parition; Parition内部保证数据的有...
  • Kafka数据存储详解

    2020-10-13 20:23:14
    每一个partion(文件夹)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件里。但每一个段segment file消息数量不一定相等,这样的特性方便old segment fifile高速被删除。(默认情况下每一个文件大小...
  • Kafka中的Message是以topic为基本单位组织的,不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的),每个partition存储一部分Mes...
  • 本文翻译自DataBricks官方博客,主要描述了Apache Spark 2.0中推出的新功能Structured Streaming(结构化流处理)从Kafka中读取消息,实时处理后再写入不同的下游系统的使用示例。 结构化流处理API使得以一种兼具一.....
  • 本文译自Processing ... Data in Apache Kafka with Structured Streaming in Apache Spark 2.2, 28 APRIL 2017, 类似编者翻译的另一篇文章,本文用实际的例子演示了Spark Structured Streaming和Ka
  • Kafka中的Message是以topic为基本单位组织的,不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的),每个partition存储一部分Message。借用官方...

空空如也

1 2 3 4 5 ... 20
收藏数 1,382
精华内容 552
关键字:

kafka数据结构

数据结构 订阅