我有一个带有20个碎片的驱魔流的设置，由基于KCL的驱魔消费者消耗。消费者部署在ECS中，有20个实例。(意味着多个KCL实例？(
我认为在这种情况下会发生的是：
- 每个实例将为每个碎片创建20个工作线程，彼此独立
- 因此，在任何给定的时间，一个碎片都会有20个独立的线程连接到它
- 同一组记录将由每个实例处理(即：不会跨实例处理重复记录处理(
- 这也将超过每个碎片的消费者费率限制。(每秒5笔交易(
- 运行我的消费者的单个实例就足够了。换句话说，跨多个实例扩展消费者根本没有任何好处
这个答案似乎表明；shard的租约；将确保它只由单个实例处理。然而，这里的第二个答案说；一个KCL实例在每个分片中只启动一个进程，但您可以让另一个KCL实例使用相同的流(和分片(，假设第二个实例具有权限&"；。
此外，该文献建议"；将实例的数量增加到打开的碎片的最大数量"；作为一种可能的放大方法，这与上面的一些观点相矛盾。
在这种情况下，消费者实例的实际功能是什么？
在您描述的场景中会发生的情况是，20个工人中的每个人最终只处理1个碎片。
在启动时，每个工作人员都会尝试通过为这些碎片创建租约来声明尽可能多的碎片。当所有20个工人同时开始时，他们都会尝试为20个碎片创建租约，但这不会对所有人都成功。一个工人可能会得到5个碎片，而另一个工人则会得到2或3个碎片。不过，经过几次租赁迭代后，每个工作人员应该只有一个碎片。这样就可以遵守AWS的费率限制。
当这种平衡过程发生时，两个工人可能会在短时间内两次处理相同的记录。这种情况发生在一个工作者从另一个工作者那里窃取租约，以及该工作者试图更新租约并通过定期刷新或检查点检查发现另一个工作人员已经占用租约之间。
不过，在最初的租赁分割之后，这种情况就不会再发生了。当工人重新启动时，他们会恢复以前的租约。但当一名工人长期停工时，其他工人会接管其租约。
因此Kinesis有一个至少一次的处理模型。最好设计应用程序，使数据上的操作是幂等的。
如果你想容错(其他工作人员将接替一个失败的工作人员(，或者你的数据处理非常耗时，以至于一个工作人员无法处理20个碎片，那么扩展是很有用的。扩展到碎片数量之外确实只对容错有用。