本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
KCL 配置
您可以设置配置属性来自定义 Kinesis 客户端库的功能,以满足您的特定要求。下表描述了配置属性和类。
重要
在 KCL 3.x 中,负载平衡算法旨在实现跨工作人员的均匀CPU利用率,而不是每个工作人员的租约数量相等。设置maxLeasesForWorker
得太低,可能会限制KCL有效平衡工作负载的能力。如果您使用该maxLeasesForWorker
配置,请考虑增加其值以实现最佳的负载分布。
配置属性 | 配置类 | 描述 | 默认值 |
---|---|---|---|
applicationName |
ConfigsBuilder | 此 KCL 应用程序的名称。用作 tableName 和 consumerName 的默认名称。 |
不适用 |
tableName |
ConfigsBuilder |
允许覆盖用于 Amazon DynamoDB 租赁表的表名称。 |
不适用 |
streamName |
ConfigsBuilder |
此应用程序从其中处理记录的流的名称。 |
不适用 |
workerIdentifier |
ConfigsBuilder |
表示应用程序处理器的这种实例化的唯一标识符。此值必须唯一。 |
不适用 |
failoverTimeMillis |
LeaseManagementConfig |
在您可以将租赁所有者视为已失败之前必须经过的毫秒数。对于拥有大量分片的应用程序,可以将其设置为更高的数字,以减少跟踪租约所需的 D IOPS ynamoDB 数量。 |
10,000(10 秒) |
shardSyncIntervalMillis |
LeaseManagementConfig |
分片同步调用之间的时间。 |
60,000(60 秒) |
cleanupLeasesUponShardCompletion |
LeaseManagementConfig |
如果设置,只要子租赁已开始处理,即可删除租赁。 |
TRUE |
ignoreUnexpectedChildShards |
LeaseManagementConfig |
如果设置,将忽略具有打开的分片的子分片。这主要适用于 DynamoDB Streams。 |
FALSE |
maxLeasesForWorker |
LeaseManagementConfig |
单个员工应接受的最大租约数量。如果工作人员无法处理所有分片,则将其设置得太低可能会导致数据丢失,并导致工作人员之间的租赁分配不理想。配置分片总数时,请考虑分片总数、工作线程数和工作器处理能力。 |
无限制 |
maxLeaseRenewalThreads |
LeaseManagementConfig |
控制租赁续订线程池的大小。您的应用程序可以容纳的租赁越多,此池应该就越大。 |
20 |
billingMode |
LeaseManagementConfig |
确定在 DynamoDB 中创建的租用表的容量模式。有两个选项:按需模式 (PAY_ PER _REQUEST) 和预配模式。我们建议使用按需模式的默认设置,因为它可以自动扩展以适应您的工作负载,而无需进行容量规划。 |
PAY_ PER _REQUEST(按需模式) |
initialLeaseTableReadCapacity |
LeaseManagementConfig | Kinesis 客户端库需要使用预置容量模式创建新的 DynamoDB 租用表时使用的 DynamoDB 读取容量。如果您在配置中使用默认的按需容量模式,则可以忽略此billingMode 配置。 |
10 |
initialLeaseTableWriteCapacity |
LeaseManagementConfig | Kinesis 客户端库需要创建新的 DynamoDB 租用表时使用的 DynamoDB 读取容量。如果您在配置中使用默认的按需容量模式,则可以忽略此billingMode 配置。 |
10 |
initialPositionInStreamExtended |
LeaseManagementConfig |
应用程序应在流中开始的初始位置。此值仅在创建初始租赁时使用。 |
InitialPositionInStream.TRIM_HORIZON |
reBalanceThresholdPercentage |
LeaseManagementConfig |
一个百分比值,用于确定负载平衡算法何时应考虑在工作人员之间重新分配分片。 这是 KCL 3.x 中引入的新配置。 |
10 |
dampeningPercentage |
LeaseManagementConfig |
一个百分比值,用于抑制将在单次再平衡操作中从超负荷工作器转移的负载量。 这是 KCL 3.x 中引入的新配置。 |
60 |
allowThroughputOvershoot |
LeaseManagementConfig |
确定是否还需要从超负荷的工作器那里获得额外的租约,即使这会导致占用的总租赁吞吐量超过所需的吞吐量。 这是 KCL 3.x 中引入的新配置。 |
TRUE |
disableWorkerMetrics |
LeaseManagementConfig |
确定在重新分配租约和负载平衡时是否KCL应忽略工作人员的资源指标(例如CPU利用率)。TRUE如果要KCL防止根据CPU利用率进行负载平衡,请将其设置为。 这是 KCL 3.x 中引入的新配置。 |
FALSE |
maxThroughputPerHostKBps |
LeaseManagementConfig |
在租赁分配期间分配给工作人员的最大吞吐量。 这是 KCL 3.x 中引入的新配置。 |
无限制 |
isGracefulLeaseHandoffEnabled |
LeaseManagementConfig |
控制员工之间租约移交的行为。设置为 true 时,KCL将尝试通过让分片有 RecordProcessor 足够的时间来完成处理,然后再将租约移交给其他工作人员,从而优雅地转移租约。这可以帮助确保数据完整性和平稳过渡,但可能会增加切换时间。 如果设置为 false,则租约将立即移交,无需等待优雅 RecordProcessor 地关闭。这可以加快移交速度,但可能会导致处理不完整。 注意:检查点必须在的 shutdownRequested () 方法中实现, RecordProcessor 才能从优雅的租赁移交功能中受益。 这是 KCL 3.x 中引入的新配置。 |
TRUE |
gracefulLeaseHandoffTimeoutMillis |
LeaseManagementConfig |
指定在强制将租约转让给下一个所有者之前,等待当前分片正常关闭的最短时间( RecordProcessor 以毫秒为单位)。 如果您的 processRecords 方法的运行时间通常比默认值长,请考虑增加此设置。这样可以确保在租赁转让发生之前 RecordProcessor 有足够的时间完成其处理。 这是 KCL 3.x 中引入的新配置。 |
30,000(30 秒) |
maxRecords |
PollingConfig |
允许设置 Kinesis 返回的最大记录数。 |
10000 |
retryGetRecordsInSeconds |
PollingConfig |
配置 GetRecords 尝试失败之间的延迟。 |
无 |
maxGetRecordsThreadPool |
PollingConfig |
使用的线程池大小 GetRecords。 |
无 |
idleTimeBetweenReadsInMillis |
PollingConfig |
确定从数据流中轮询数据的 GetRecords 呼叫之间KCL等待多长时间。单位为毫秒。 |
1500 |
callProcessRecordsEvenForEmptyRecordList |
ProcessorConfig |
如果设置,即使 Kinesis 中未提供任何记录,也会调用记录处理器。 |
FALSE |
parentShardPollIntervalMillis |
CoordinatorConfig |
记录处理器应轮询多少时间才能查看是否已完成父分片。单位为毫秒。 |
10,000(10 秒) |
skipShardSyncAtWorkerInitializationIfLeaseExist |
CoordinatorConfig |
如果租赁表包含现有租赁,请禁用同步的分片数据。 |
FALSE |
shardPrioritization |
CoordinatorConfig |
要使用的分片优先级。 |
NoOpShardPrioritization |
ClientVersionConfig |
CoordinatorConfig |
确定应用程序将在哪个KCL版本兼容模式下运行。此配置仅适用于从先前KCL版本迁移。迁移到 3.x 时,需要将此配置设置为。 |
CLIENT_ VERSION _ CONFIG _3X |
taskBackoffTimeMillis |
LifecycleConfig |
等待重试失败KCL任务的时间。单位为毫秒。 |
500(0.5 秒) |
logWarningForTaskAfterMillis |
LifecycleConfig |
任务尚未完成的情况下在记录警告之前要等待的时长。 |
无 |
listShardsBackoffTimeInMillis |
RetrievalConfig | 发生故障时在调用 ListShards 之间要等待的时间(以毫秒为单位)。单位为毫秒。 |
1,500(1.5 秒) |
maxListShardsRetryAttempts |
RetrievalConfig | ListShards 在放弃之前重试的最长时间。 |
50 |
metricsBufferTimeMillis |
MetricsConfig |
指定在发布指标之前缓冲指标的最大持续时间(以毫秒为单位)。 CloudWatch |
10,000(10 秒) |
metricsMaxQueueSize |
MetricsConfig |
指定发布到之前要缓冲的最大指标数 CloudWatch。 |
10000 |
metricsLevel |
MetricsConfig |
指定要启用和发布的 CloudWatch 指标的粒度级别。 可能的值:NONE、SUMMARY、DETAILED。 |
MetricsLevel.DETAILED |
metricsEnabledDimensions |
MetricsConfig |
控制 CloudWatch 指标允许的维度。 |
所有维度 |
KCL3.x 中已停产的配置
KCL3.x 中已停止使用以下配置属性:
配置属性 | 配置类 | 描述 |
---|---|---|
maxLeasesToStealAtOneTime |
LeaseManagementConfig |
应用程序一次应尝试窃取的最大租约数量。 KCL3.x 将忽略此配置,并根据工作人员的资源利用率重新分配租约。 |
enablePriorityLeaseAssignment |
LeaseManagementConfig |
控制工作人员是否应优先考虑已过期的租约(未续订的租约为故障转移时间的 3 倍)和新的分片租约,无论目标租约数量如何,但仍要遵守最大租赁限制。 KCL3.x 将忽略此配置,并始终将过期的租约分配给工作人员。 |
重要
在从先前KCL版本迁移到 3.x 的过程中,您仍然必须具有不连续的配置属性。KCL在迁移过程中,KCL工作程序将首先从 KCL 2.x 兼容模式启动,并在检测到应用程序的所有KCL工作程序都准备好运行 KCL KCL 3.x 时切换到 3.x 功能模式。当KCL工作人员运行 KCL 2.x 兼容模式时,需要这些已停产的配置。