AmazonKinesisClient getRecord()与IRecordProcessor processRecords()的区别及适用场景

核心差异 #

两者本质是不同层级的接口封装：AmazonKinesisClient.getRecords() 是Kinesis提供的底层原生API封装，IRecordProcessor.processRecords() 是Kinesis Client Library（KCL）框架封装后暴露给业务层的回调入口，核心差异包括：

• 抽象层级不同
  • getRecords() 是最基础的读操作接口，调用前需要开发者自行处理分片迭代器获取、迭代器过期重试、分片分裂/合并后的列表更新、消费进度checkpoint持久化、多实例分片负载均衡、异常兜底等全链路逻辑，Kinesis侧仅返回当前迭代器对应的批量记录，不做任何额外处理。
  • processRecords() 是KCL封装后的高层回调接口，上述分片管理、checkpoint管理、负载均衡、异常重试等通用逻辑已经由KCL全部实现，开发者仅需要在该方法内编写业务处理逻辑即可，无需关心底层Kinesis API的调用细节。
• 调用逻辑不同
  • getRecords() 是主动调用接口，需要开发者自行编写循环拉取逻辑，自主控制拉取频率、批量大小等参数。
  • processRecords() 是被动回调接口，KCL框架内部会自动调用getRecords()拉取记录，拉取完成后主动调用开发者实现的该方法传入记录列表。
• 附加能力不同
  • getRecords() 返回结果仅包含记录列表、下一个分片迭代器、请求延迟等基础元数据，没有额外加工能力。
  • processRecords() 接收的参数除记录列表外，还附带KCL封装好的checkpoint工具、分片上下文信息，开发者可以直接调用方法提交消费进度，无需自行组装checkpoint API请求。

各自适用场景 #

• AmazonKinesisClient.getRecords() 适用场景：
  • 需要完全自定义消费逻辑的场景，比如特殊的批量聚合规则、自定义消费进度存储（比如存储到自有业务库而非KCL默认的DynamoDB）、自定义分片调度策略等标准KCL无法满足的需求。
  • 轻量级一次性消费任务，比如临时拉取某段时间的Kinesis数据做校验，无需长期运行、无需负载均衡的简单场景，可以避免引入KCL的额外依赖。
• IRecordProcessor.processRecords() 适用场景：
  • 生产环境长期运行的高可用消费者服务，不需要自行重复实现分片管理、故障转移、负载均衡等通用逻辑，可大幅降低开发成本。
  • 开发团队对Kinesis底层实现了解较少，不需要深入掌握Kinesis API细节，仅需要聚焦业务处理逻辑的场景。

关于获取经AmazonKinesisClient处理后的记录的说明 #

AmazonKinesisClient本身仅对Kinesis原生API做薄封装，不会对记录做任何业务层面的加工，不存在所谓「经AmazonKinesisClient处理后的记录」。你通过getRecords()拿到的就是Kinesis服务端返回的原始记录，和KCL内部调用getRecords()获取的记录内容完全一致。
如果需要拿到和KCL传给processRecords()结构相同的记录，仅需要自行对getRecords()返回的原始记录做简单的字段映射即可，没有额外的专用API可以直接获取。

内容的提问来源于stack exchange，提问作者Gaurav