云服务器内容精选

  • Topic和Partition的划分关系说明 假设集群中部署了K个Kafka节点,每个节点上配置的磁盘个数为N,每块磁盘大小为M,集群共有n个Topic(T1,T2…Tn),并且其中第m个Topic的每秒输入数据总流量为X(Tm) MB/s,配置的副本数为R(Tm),配置数据保存时间为Y(Tm)小时,那么整体必须满足: 假设单个磁盘大小为M,该磁盘上有n个Partition(P0,P1……Pn),并且其中第m个Partition的每秒写入数据流量为Q(Pm) MB/s(计算方法:所属Topic的数据流量除以Partition数)、数据保存时间为T(Pm)小时,那么单个磁盘必须满足: 根据吞吐量粗略计算,假设生产者可以达到的吞吐量为P,消费者可以达到的吞吐量为C,预期Kafka吞吐量为T,那么建议该Topic的Partition数目设置为Max(T/P , T/C)。 在Kafka集群中,分区越多吞吐量越高,但是分区过多也存在潜在影响,例如文件句柄增加、不可用性增加(如:某个节点故障后,部分Partition重选Leader后时间窗口会比较大)及端到端时延增加等。 建议:单个Partition的磁盘占用最大不超过100GB;单节点上Partition数目不超过3000;整个集群的分区总数不超过10000。
  • 回答 可能原因一:配置项“delete.topic.enable”未配置为“true”,只有配置为“true”才能执行真正删除。 可能原因二:“auto.create.topics.enable”配置为“true”,其他应用程序有使用该Topic,并且一直在后台运行。 解决方法: 针对原因一:登录Manager,在Kafka配置页面上将“delete.topic.enable”设置为“true”。 针对原因二:先停掉后台使用该Topic的应用程序,或者“auto.create.topics.enable”配置为“false”(需要重启Kafka服务),然后再做删除操作。
  • Topic和Partition的划分关系说明 假设集群中部署了K个Kafka节点,每个节点上配置的磁盘个数为N,每块磁盘大小为M,集群共有n个Topic(T1,T2…Tn),并且其中第m个Topic的每秒输入数据总流量为X(Tm) MB/s,配置的副本数为R(Tm),配置数据保存时间为Y(Tm)小时,那么整体必须满足: 假设单个磁盘大小为M,该磁盘上有n个Partition(P0,P1……Pn),并且其中第m个Partition的每秒写入数据流量为Q(Pm) MB/s(计算方法:所属Topic的数据流量除以Partition数) 、数据保存时间为T(Pm)小时,那么单个磁盘必须满足: 根据吞吐量粗略计算,假设生产者可以达到的吞吐量为P,消费者可以达到的吞吐量为C,预期Kafka吞吐量为T,那么建议该Topic的Partition数目设置为Max(T/P , T/C)。 在Kafka集群中,分区越多吞吐量越高,但是分区过多也存在潜在影响,例如文件句柄增加、不可用性增加(如:某个节点故障后,部分Partition重选Leader后时间窗口会比较大)及端到端时延增加等。 建议:单个Partition的磁盘占用最大不超过100GB;单节点上Partition数目不超过3000;整个集群的分区总数不超过10000。