合肥制作网站企业,百度首页排名代发,深圳市地图,php网站开发教材kafka为什么要在topic里加入分区的概念#xff1f;如果没有分区,topic中的segment消息写满后,直接给订阅者不是也可以吗#xff1f; Kafka可以将主题划分为多个分区#xff08;Partition#xff09;#xff0c;会根据分区规则选择把消息存储到哪个分区中#xff0c;只要如…kafka为什么要在topic里加入分区的概念如果没有分区,topic中的segment消息写满后,直接给订阅者不是也可以吗 Kafka可以将主题划分为多个分区Partition会根据分区规则选择把消息存储到哪个分区中只要如果分区规则设置的合理那么所有的消息将会被均匀的分布到不同的分区中这样就实现了负载均衡和水平扩展。另外多个订阅者可以从一个或者多个分区中同时消费数据以支撑海量数据处理能力 Kafka的设计也是源自生活好比是为公路运输不同的起始点和目的地需要修不同高速公路主题高速公路上可以提供多条车道分区流量大的公路多修几条车道保证畅通流量小的公路少修几条车道避免浪费。收费站好比消费者车多的时候多开几个一起收费避免堵在路上车少的时候开几个让汽车并道就好了嗯……
顺便说一句由于消息是以追加到分区中的多个分区顺序写磁盘的总效率要比随机写内存还要高引用Apache Kafka – A High Throughput Distributed Messaging System的观点是Kafka高吞吐率的重要保证之一。
为了保证数据的可靠性Kafka会给每个分区找一个节点当带头大哥Leader以及若干个节点当随从Follower。消息写入分区时带头大哥除了自己复制一份外还会复制到多个随从。如果随从挂了Kafka会再找一个随从从带头大哥那里同步历史消息如果带头大哥挂了随从中会选举出新一任的带头大哥继续笑傲江湖。 详见下卡夫卡的副本机制。
观点2
这里其实有2个问题可以逐一回答
1.kafka为什么要在topic里加入分区的概念 topic是逻辑的概念partition是物理的概念对用户来说是透明的。
producer只需要关心消息发往哪个topic而consumer只关心自己订阅哪个topic并不关心每条消息存于整个集群的哪个broker。 为了性能考虑如果topic内的消息只存于一个broker那这个broker会成为瓶颈无法做到水平扩展。
所以把topic内的数据分布到整个集群就是一个自然而然的设计方式。
Partition的引入就是解决水平扩展问题的一个方案。
如同我在Kafka设计解析一里所讲每个partition可以被认为是一个无限长度的数组新数据顺序追加进这个数组。
物理上每个partition对应于一个文件夹。一个broker上可以存放多个partition。
这样producer可以将数据发送给多个broker上的多个partitionconsumer也可以并行从多个broker上的不同paritition上读数据实现了水平扩展
2.如果没有分区,topic中的segment消息写满后,直接给订阅者不是也可以吗
“segment消息写满后”consume消费数据并不需要等到segment写满只要有一条数据被commit就可以立马被消费
segment对应一个文件实现上对应2个文件一个数据文件一个索引文件一个partition对应一个文件夹一个partition里理论上可以包含任意多个segment。
所以partition可以认为是在segment上做了一层包装。 这个问题换个角度问可能更好“为什么有了partition还需要segment”。
如果不引入segment一个partition直接对应一个文件应该说两个文件一个数据文件一个索引文件那这个文件会一直增大。
同时在做data purge时需要把文件的前面部分给删除不符合kafka对文件的顺序写优化设计方案。
引入segment后每次做data purge只需要把旧的segment整个文件删除即可保证了每个segment的顺序写
参考kafka中的topic为什么要进行分区? - 知乎 卡夫卡的副本机制 由于Producer和Consumer都只会与Leader角色的分区副本相连所以kafka需要以集群的组织形式提供主题下的消息高可用。kafka支持主备复制所以消息具备高可用和持久性。 一个分区可以有多个副本这些副本保存在不同的broker上。每个分区的副本中都会有一个作为Leader。当一个broker失败时Leader在这台broker上的分区都会变得不可用kafka会自动移除Leader再其他副本中选一个作为新的Leader。
在通常情况下增加分区可以提供kafka集群的吞吐量。然而也应该意识到集群的总分区数或是单台服务器上的分区数过多会增加不可用及延迟的风险。 创建副本的2种模式——同步复制和异步复制
kafka动态维护了一个同步状态的副本的集合a set of In-Sync Replicas简称ISR。
在这个集合中的节点都是和leader保持高度一致的任何一条消息只有被这个集合中的每个节点读取并追加到日志中才会向外部通知说“这个消息已经被提交”。
只有当消息被所有的副本加入到日志中时才算是“committed”只有committed的消息才会发送给consumer这样就不用担心一旦leader down掉了消息会丢失。
消息从leader复制到follower, 我们可以通过决定producer是否等待消息被提交的通知(ack)来区分同步复制和异步复制。
如果等待ack则为同步如果不需要等待所有follower复制完成即回传ack则为异步模式。
同步复制 1.producer联系zk识别leader 2.向leader发送消息 3.leadr收到消息写入到本地log 4.follower从leader pull消息 5.follower向本地写入log 6.follower向leader发送ack消息 7.leader收到所有follower的ack消息 8.leader向producer回传ack
异步复制 和同步复制的区别在于leader写入本地log之后 直接向client回传ack消息不需要等待所有follower复制完成。 卡夫卡支持副本模式那么其中一个broker里的挂掉一个新的leader就能通过ISR机制推选出来继续处理读写请求。 Kafka集群partition replication默认自动分配分析
下面以一个Kafka集群中4个Broker举例创建1个topic包含4个Partition2 Replication数据Producer流动如图所示
(1) (2)当集群中新增2节点Partition增加到6个时分布情况如下 副本分配逻辑规则如下
在Kafka集群中每个Broker都有均等分配Partition的Leader机会。上述图Broker Partition中箭头指向为副本以Partition-0为例:broker1中parition-0为LeaderBroker2中Partition-0为副本。上述图中每个Broker(按照BrokerId有序)依次分配主Partition,下一个Broker为副本如此循环迭代分配多副本都遵循此规则。副本分配算法如下
将所有N Broker和待分配的i个Partition排序.将第i个Partition分配到第(i mod n)个Broker上.将第i个Partition的第j个副本分配到第((i j) mod n)个Broker上.
