kafka如何合理规划分区数量

背景: 如同其他分布式系统一样,在kafka集群中,单Topic的partition也并不是越多越好,但通常对于业务方来说,可能会简单的根据生产者或消费者的处理能力来提出扩partition的需求,此时就需要根据具体的场景进行分析以确定partition的数量。

对于Kafka集群承载的业务Topic来说,分区的数量,可以体现出整个业务的量级同时能够尽可能的提供更高的吞吐,但并不是越多的分区就意味着越高的吞吐和处理能力,通常情况下需要业务方和基础服务方一起来进行分析。

以下为多分区Topic的优缺点,可以适当根据需求和场景进行规划分区数量。

kafka常用运维操作

前言: 在kafka的集群运维操作过程中,我们需要通过一些工具来实现集群的高可用以及负载的平均操作,而对于kafka集群的SRE来说,需要掌握好如下几点,才能更好的维护和保证kafka集群服务的稳定性,可靠性和整体性能。

kafka生产规划和运维

前言: 通常对于初创企业或者初创业务团队来说,对于开源组件的使用都会显的比较随意,而这种情况会随着业务量级的增长或时间的推移导致开源服务的滥用,进而造成的结果就是服务整体的稳定性和可靠性相对较差,且是边际效应递减的,如果此时不对整体业务以及开源服务进行规划和改造,那么风险和成本将是同比增长的。在我过去的工作经历中,经历过类似服务的有Redis集群ElasticSearch集群,虽然整体改造后并不一定将成本降到最低,但是可以将服务的可用性和可靠性提高很多,而且根据业务场景以及使用方式来规划集群后会使得整体的边际成本呈递减状态。

笔者目前所处的团队所管理的kafka集群也处于该种状态,集群当前规模大约为20+ECS,总数据量大约400T,其中承接的Topic服务主要分为日志收集数据管道流式计算业务事件存储几种大场景,我们需要知道,以上几种使用场景对于kafka集群的的可用性可靠性数据一致性要求其实是不同的,如果将所有场景耦合到同一个集群,在数据量较大的情况下,任何的小异常点都可能造成整体服务受到影响,并且整个集群的恢复周期会很长,如果业务没有及时的降级策略很可能影响核心业务的处理。

鉴于以前对开源分布式服务的规划和改造经验,本篇文章将根据官方文档以及经验来分享一些关于Kafka生产集群规划和运维管理相关的知识.