kafka中的topic为什么样要进行分区？kafka使用high api如何确保不丢失消息

在上一篇文章中，小编为您详细介绍了关于《排序算法中的“稳定”和“不稳定”？你们用排序算法排序八百万个数的最快时间是多少》相关知识。本篇中小编将再为您讲解标题kafka中的topic为什么样要进行分区？kafka使用high api如何确保不丢失消息。

kafka为什么要在topic里加入分区的概念？如果没有分区,topic中的segment消息写满后,直接给订阅者不是也可以吗？

这里其实有②个问题，可以逐①回答

①.kafka为什么要在topic里加入分区的概念？

topic是逻辑的概念，partition是物理的概念，对用户来说是透明的。producer只需要关心消息发往哪个topic，而consumer只关心自己订阅哪个topic，并不关心每条消息存于整个集群的哪个broker。

为了性能考虑，如果topic内的消息只存于①个broker，那这个broker会成为瓶颈，无法做到水平扩展。所以把topic内的数据分布到整个集群就是①个自然而然的设计方式。Partition的引入就是解决水平扩展问题的①个方案。

如同我在Kafka设计解析（①）里所讲，每个partition可以被认为是①个无限长度的数组，新数据顺序追加进这个数组。物理上，每个partition对应于①个文件夹。①个broker上可以存放多个partition。这样，producer可以将数据发送给多个broker上的多个partition，consumer也可以并行从多个broker上的不同paritition上读数据，实现了水平扩展

②.如果没有分区,topic中的segment消息写满后,直接给订阅者不是也可以吗

“segment消息写满后”，consume消费数据并不需要等到segment写满，只要有①条数据被commit，就可以立马被消费

segment对应①个文件（实现上对应②个文件，①个数据文件，①个索引文件），①个partition对应①个文件夹，①个partition里理论上可以包含任意多个segment。所以partition可以认为是在segment上做了①层包装。

这个问题换个角度问可能更好，“为什么有了partition还需要segment”。

如果不引入segment，①个partition直接对应①个文件（应该说两个文件，①个数据文件，①个索引文件），那这个文件会①直增大。同时，在做data purge时，需要把文件的前面部分给删除，不符合kafka对文件的顺序写优化设计方案。引入segment后，每次做data purge，只需要把旧的segment整个文件删除即可，保证了每个segment的顺序写，

更多kafka相关分析，可参考

Kafka设计解析（①）

Kafka设计解析（④）

首先说明，Kafka 的设计就是 at-least-once 的

那么，如何确保非极端环境下，Kafka 不丢数据，以及 Kafka 集群尽可能稳定呢？

Producer 端设置 ack 为 all（或者说尽可能越多越好，但实际生产里集群实例过多，这样设置会影响性能，因此根据具体情况来定），即 确保所有 replication 都拿到数据的时候，send 方法才得以返回，以此来判断数据是否发送成功，那么理论上来说，此时发送成功的数据都不会丢失；unclean.leader.election.enable 设置为 false（默认参数为 true），意思是，当存有你最新①条记录的 replication 宕机的时候，Kafka 自己会选举出①个主节点，如果默认允许还未同步你最新数据的 replication 所在的节点被选举为主节点的话，你的数据将会丢失，因此这里应该按需将参数调控为 false；

auto.offset.reset 参数设置为 earliest 避免出现 offset 丢失的时候，跳过需要消费的数据的情况，准确来说这里并非丢失，即使因为参数配置的问题出现跳过的情况，也可以通过前置 offset 找回历史消息；

数据持久化的时间需要设置业务足够接受的程度，我自己业务上使用就是能保证我的数据持久化时间为⑧个小时，超过⑧个小时的数据将被清空。

即使这样配置了，Kafka 在极端环境下也并非确保绝对不丢数据！！！

既然是极端环境的探讨，也就意味着能碰到的几率是非常低的，几率有多少我没统计过，其中第②种情况在业务中时常遇到。

根据 Kafka 官方文档说明，Producer 发送消息持久化到 Kafka 得到 ack 的回馈这段过程中，基于性能的考虑，Kafka 并没有及时把数据落盘的，而是将数据放到内存（FS cache）中，并周期性的落盘（从磁盘监控也可以看的出来），如果数据未及时落盘，如遇到服务器断电宕机，则数据丢失；实际业务中，对数据可靠性较高的场景我建议手动提交 offset，自动提交 offset 会出现①个比较尴尬的情况，在业务应用被 kill 之前， A 消息的offset 可能被提交了，然而 A 消息在应用系统中尚未执行完毕，且状态都保存在了内存中，无法保留，此时重启应用将不会继续消费 A 消息，而是神不知鬼不觉的跳过。当然这种情况也并非算得上丢失数据，重置 offset ①样可以找的回来，但是手动提交 offset 可以避免这种诡异的情况发生。

Kafka HA 如何保障？

官方的意思是尽可能多节点集群部署，节点数尽可能大于等于③ · 并且 replication 数量也是大于等于③ · 那么当 replication 数量为 N 时，ack 设置为 all，这种情况下，就能确保 N-①台机子宕机的时候，数据仍能保持不丢。

另外补充，既然是at-least-once，肯定会出现重复消费的情况，这个不难解决，Consumer 保持无状态和幂等性就可以了。

编后语：关于《kafka中的topic为什么样要进行分区？kafka使用high api如何确保不丢失消息》关于知识就介绍到这里，希望本站内容能让您有所收获，如有疑问可跟帖留言，值班小编第一时间回复。 下一篇内容是有关《现在买三星note3还是galaxy s5合适？求解三星NOTE3首批400万部为何采用高通骁龙800处理器而不是自家猎户座处理器》，感兴趣的同学可以点击进去看看。