3.6.4 发送拉取请求并消费消息

3.6.4 发送拉取请求井消费消息

消费者使用高级API拉取消息,再平衡后第一次拉取时,从ZK或消费组的协调节点读取一次偏移£10扣,取消息后会更新本地内存partitionMap的拉取状态,后续拉取线程以最新的分区拉取状态构建拉取请求,并不需要再从ZK或协调节点读取偏移量。因为拉取状态每次都会更新,所以新创建的拉取请求也是最新的。

低级API也使用类似的方式,第一次读取偏移量通过getlastOffset()从服务端读取,拉取到消息后要更新读取偏移量,下一次拉取时以最近更新的读取偏移量构建拉取请求。低级APC因为只拉取一个分区,所以直接用读取偏移量保存拉取状态,而高级API的消费者拉取钱程可能分配多个分区,所以用partitionMap保存多个分区的拉取状态。

涉及和远程节点的跨网络交互,不管是ZK还是协调节点,都是比较昂贵的操作。对于用来构建拉取请求的偏移量,能够保存在当前客户端的内存中,要比从服务端节点读取来得快。下面的两段伪代码中第一种就比第二种的性能要好,因为前者只需要一次远程访问,后者每次都需要远程访问:
在这里插入图片描述
低级API每读取一条消息就更新一次读取偏移量,而高级API是收到一批完整的消息后,只在最后做一次更新。这里如果把更新读取偏移量放在循环之后也可以,只要在循环里做一个计数器,计算本次有多少条消息即可。还有一点不同,即高级API在拉取消息之后放到了分区信息的队列里,并通过消息流和消费者迭代器来消费,低级API的手段就比较“低级”,获取消息后直接循环处理消息集。相关代码如下:
在这里插入图片描述
读取消息时,还要保证消息的偏移量比拉取请求的读取偏移量大,这是因为消息可能会被压缩(压缩可以减小数据的大小和数据跨网络的传输带宽,但代价是需要消耗一定的1/0来做压缩和解,压缩)。如果Kafka将消息、集进行压缩,拉取请求会返回一个完整的压缩块(压缩块必须是完整的才有效),即使拉取请求的偏移£}:并不是压缩块的开始位置。比如读取偏移量为10,但压缩块的偏移盘范罔是5~20,压缩块的开始偏移盘5比读取偏移盘10要小,那么5~10。这部分消息不需要读取。

相关推荐
©️2020 CSDN 皮肤主题: 酷酷鲨 设计师:CSDN官方博客 返回首页