kafka常用命令
目录
一、Topic
1. 列出所有 Topic
|
|
2. 删除一个 Topic
|
|
3. 创建一个 Topic
|
|
参数说明
Partition 数目与Replication Factor是在创建一个topic时非常重要的两个参数,这两个参数的取值会直接影响到系统的性能与稳定性。
尽量在第一次创建一个topic时就指定这两个参数,因为
- 如果Partition 数目在之后再次做调整,则会打乱key的顺序保证(同样的key会分布到不同的partition上)
- 如果Replication Factor在之后再次增加,则会给集群带来更大的压力,可能会导致性能下降
Partition
一般来说,每个partition 能处理的吞吐量为几MB/s(仍需要基于根据本地环境测试后获取准确指标),增加更多的partitions意味着:
- 更高的并行度与吞吐
- 可以扩展更多的(同一个consumer group中的)consumers
- 若是集群中有较多的brokers,则可更大程度上利用闲置的brokers
- 但是会造成Zookeeper的更多选举
- 同时也会在Kafka中打开更多的文件
调整准则:
- 一般来说,若是集群较小(小于6个brokers),则配置
2 x broker
的partition数。在这里主要考虑的是之后的扩展。若是集群扩展了一倍(例如12个),则不用担心会有partition不足的现象发生 - 一般来说,若是集群较大(大于12个),则配置
1 x broker
的partition数。因为这里不需要再考虑集群的扩展情况,与broker数相同的partition数已经足够应付常规场景。若有必要,则再手动调整 - 考虑最高峰吞吐需要的并行consumer数,调整partition的数目。若是应用场景需要有20个(同一个consumer group中的)consumer并行消费,则据此设置为20个partition
- 考虑producer所需的吞吐,调整partition数目(如果producer的吞吐非常高,或是在接下来两年内都比较高,则增加partition的数目)
以上仅是几个基本准则,最重要的是:在本地集群做测试,以获取一个更合适的partition数目,不同的集群会有不同的性能。
Replication
此参数决定的是records复制的数目,建议至少 设置为2,一般是3,最高设置为4。更高的replication factor(假设数目为N)意味着:
- 系统更稳定(允许N-1个broker宕机)
- 更多的副本(如果acks=all,则会造成较高的延时)
- 系统磁盘的使用率会更高(一般若是RF为3,则相对于RF为2时,会占据更多50% 的磁盘空间)
调整准则:
- 以3为起始(当然至少需要有3个brokers,同时也不建议一个Kafka 集群中节点数少于3个节点)
- 如果replication 性能成为了瓶颈或是一个issue,则建议使用一个性能更好的broker,而不是降低RF的数目
- 永远不要在生产环境中设置RF为1
集群调整建议
业界准则
一个broker不应该承载超过2000 到 4000 个partitions
- 考虑此broker上所有来自不同topics的partitions
同时,一个Kafka集群上brokers中所有的partitions总数最多不应超过20,000个。
此准则基于的原理是:在有broker宕机后,zookeeper需要重新做选举。若是partitions数目过多,则需要执行大量的leader elections。
常规准则
- 如果集群中需要更多的partitions,则优先考虑增加brokers
- 如果集群中需要20,000 个以上的partitions,则可以参考Netflix的模型,创建更多的Kafka 集群
最后需要注意的是: 不要为一个topic创建超过1000个的partitions。我们也并不需要1000个partitions才能达到很高的吞吐。在开始的时候,选择一个更合理的partition数目,然后测试性能,根据测试结果再调整partitions 数目。
二、生产
|
|
三、消费
1. 查看消费组
|
|
2. 消费消息
|
|