qq_44477308的博客

实际运行后发现，发送的数据先有几条很快的被消费到，后面的数据大概66秒左右也被消费到，和我设置的延迟时间差别很大。后来发现，生产者不能使用list批量发送，该情况下会使得延迟效果异常。记录RocketMQ使用延迟消息时候的异常以及方案。修改为单条发送后延迟效果正常。

maxTransferCountOnMessageInMemory是从内存中的获取的，而我的场景是数据都是延迟数据，很可能以及落盘了，所以该参数并没有效果，应该从磁盘相关的参数入手。从查阅相关资料可知，一般都推荐修改maxTransferCountOnMessageInMemory参数，该参数指的是单词pull消息从内存中传输的最大数据条数。我希望的是80个线程，每个线程每批次消费1024条数据。记录在日常开发中遇到的RocketMQ消费每批次获取数据过少的问题。很可能是配置不对导致限制了消费数据条数。

kafka集群点击每一个broker的配置，找到kafka.properties的kafka Broker高级配置代码段（安全阀）集群通信使用192网段通信，并且使用主机名（node*），/etc/hosts里面的主机名映射也是配置的192网段。由于部署环境要求，kafka的节点都配置了双网口，不同的网段（假设为192网段和191网段）配置每个kafka的broker的主机名映射，让producer至少能连上kafka。注意是每一个broker的配置，不要在kafka集群的配置中修改。

首先排查namenode服务是否正常，在查看了hdfs的webui中的信息确认了namenode是正常的后，测试namenode的8020端口的连接情况。有一个日常消费kafka数据并将数据文件写入hdfs的程序，突然报错Premature EOF: no length prefix available，过段时间后消费者超时导致整个消费组重均衡，导致较为严重的积压。hdfs的8020端口和50010端口都需要开发，一个是连接namenode的端口，一个是datanode之间数据传输的端口。