问题描述
我有一个带有20个分片的运动流的设置，该运动由基于KCL的运动消费者使用。使用者部署在具有20个实例的ECS中。（意味着多个KCL实例？）
我相信在这种情况下会发生以下情况：
- 每个实例将为每个分片创建20个工作线程，彼此独立。
- 因此，在任何给定时间，一个分片将有20个独立的线程与其连接
- 相同记录集将由每个实例处理（即：不会在所有实例之间处理重复记录）
- 这还将超出每个分片的使用者费率限制。 （每秒5笔交易）
- 运行我的使用者的一个实例就足够了。换句话说，在多个实例之间扩展使用方根本没有任何好处。
This的答案似乎表明“分片租约”将确保它仅由单个实例处理。但是，second answer在这里说：“一个KCL实例每个分片只会启动一个进程，但是您可以让另一个KCL实例使用相同的流（和分片），前提是第二个KCL实例具有许可。”。 >
进一步的this文档建议“将实例数量增加到最大开放碎片数”是一种可能的放大方法，与上述某些观点相矛盾。
在这种情况下，使用者实例实际上如何工作？
解决方法
在您描述的场景中将发生的情况是，这20个工人中的每个工人最终只会处理1个分片。
在启动时，每个工作人员将通过为这些碎片创建租约来尝试索取尽可能多的碎片。当所有20个工人同时开始工作时，他们都会尝试为20个分片创建租约，但这不会对所有工人都成功。一个工人可能最终拥有例如5个分片，而其他工人则最终拥有2个或3个分片。但是，在经过几次租约出租后，每个工人只能拥有1个分片。这样，就可以遵守AWS速率限制。
虽然发生了这种平衡过程，但是很短的时间，两个工作人员可能会两次处理相同的记录。在一个工人从另一个工人那里窃取租约到那个工人试图更新租约并发现另一个工人已经通过定期刷新或通过检查点获取它的时间之间。
但是，在此最初的租赁划分之后，这将不再发生。重新启动工人后，他们将恢复以前的租约。但是当一个工人长时间停工时，其他工人将接管其租约。
因此，Kinesis具有至少一次的处理模型。最好设计您的应用程序，以使对数据的操作是幂等的。
如果您希望容错（其他工作人员将从故障工作人员那里接管），或者您的数据处理非常耗时以至于一个工作人员无法处理20个分片，那么缩放很有用。扩展分片数量确实仅对容错目的有用。