241_Redis_集群_主从架构(redis主从与集群)
812
2022-05-28
集群后续需要搬迁,割接期同一个业务对接两套集群,发现旧的CDH Kafka集群和新的Mrs kafka集群节点上存储的文件大小相差了几十倍。
问题处理过程:
一、创建新的消费组分别从头部和尾部进行消费,并查询offset,计算当前存储的消息总数量,对比是否数据量差异导致
1.执行如下语句创建新的consumerGroup,并消费数据【这里不能使用现网使用的consumerGroup】
kafka-verifiable-consumer.sh --broker-list xxx.xx.xx.xx:21007 --topic topicName --group-id consumerGroupName --max-messages 5 --verbose --consumer.config ../config/consumer.properties
2.执行下面语句获取最大的offset
kafka-consumer-groups.sh --reset-offsets --bootstrap-server xxx.xx.xx.xx:21007 --group consumerGroupName --command-config ../config/consumer.properties --topic topicName --to-latest
3.执行下面语句获取最小的offset
kafka-consumer-groups.sh --reset-offsets --bootstrap-server xxx.xx.xx.xx:21007 --group consumerGroupName --command-config ../config/consumer.properties --topic topicName --to-earliest
4.两个NEW-OFFSET相减,得到的就是各分区的消息总条数。两个集群存储的总数据量差异不大也就相差几倍而已
二、怀疑是否因为是数据压缩导致的差异
1.在broker节点,执行如下语句解析日志数据文件,确认两个集群上的数据是否压缩以及压缩格式。
kafka-run-class.sh kafka.tools.DumpLogSegments --files /xxx/xxxxx/kafka-logs/TopicName-1/00000000000000000000.log
如下截图只是个示例
2.查询后发现旧的CDH集群的消息使用gzip进行了压缩,MRS集群的消息没有压缩,故问题原因就在于此。【应该先排查压缩因素】
问题总结:
1.消息压缩可以提高kafka的吞吐量,压缩即空间换时间,通过空间的压缩带来速度的提升,即通过少量的cpu消耗来减少磁盘和网络传输的io。
2.消息何时压缩
在生产者端进行压缩:1)压缩使用的是生产者端的CPU,对生产效率有一定影响;2)对Kafka性能无影响;3)可以减小生产者到Kafka的网络IO。一般使用场景都是此模式。
在Kafka Broker侧压缩:1)Broker需要对消息进行压缩,导致broker所在的节点CPU使用率高;2)Broker侧压缩会导致kafka丧失“零拷贝”(当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝,从而实现快速的数据传输),影响Kafka的IO性能;3)生产者到Kafka的网络IO没有减少。一般不建议在Broker侧进行压缩,kafka只负责把数据原封不动的保存;
3.消费者负责消息的解压:消息体中有封装加密算法,消费者接收到消息后可以判断出消息是否压缩,以及使用的什么压缩算法。
Kafka MapReduce
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。