Spring Cloud Stream Kinesis活页夹-并发

Question

我用以下组件构建了一个弹簧启动运动消费者：

• 弹簧靴（版本-2.1.2.RELEASE）
• 春天的云（版本-Greenwich.RELEASE）
• 春季云流运动学粘合剂（版本-1.1.0.RELEASE）

我消耗了具有1个分片的运动流中的事件。 同样，该春季启动用户应用程序也在Pivotal Cloud Foundry Platform中运行。

在发布此问题之前，我在本地（使用Kinesalite）和PCF（使用运动学流）中尝试了该方案。 您能否确认我的理解是否正确？ 我浏览了Spring Cloud Stream文档（ https://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/和https://github.com/spring-cloud/spring-cloud- stream-binder-aws-kinesis / blob / master / spring-cloud-stream-binder-kinesis-docs / src / main / asciidoc / overview.adoc ）。 尽管文档详尽无遗，但并未详细解释并发性和高可用性。

假设我有3个消费者实例部署到PCF（通过在cf push期间使用的manifest.yml文件中将instances属性设置为3）。

所有3个实例均具有以下属性 ：

spring.cloud.stream.bindings..consumer.concurrency = 5

spring.cloud.stream.bindings..group =我的消费者组

spring.cloud.stream.kinesis.binder.checkpoint.table =我的元数据动态模型表

spring.cloud.stream.kinesis.binder.locks.table = my-locks-dynamodb-table

假设事件是由生产者按此顺序发送给运动机

event5（流中的最新事件）-event4-event3-event2-event1（流中的第一个事件）

对于这种配置，我在下面解释了我的理解。 您可以确认这是否正确吗？

1. 在给定的时间点，只有使用者的一个实例处于活动状态，并且它将处理发送到运动学流的所有事件（因为该流只有一个分片）。 仅当主实例关闭时，其他2个实例中的一个才会控制。 此配置是为了确保高可用性并保留消息的顺序。
2. 由于实例数是在PCF的manifest.yml中设置的，因此我不必担心设置spring.cloud.stream.instanceCount或spring.cloud.stream.bindings..consumer.instanceCount属性。
3. 启动/启动spring boot使用者时，有5个使用者线程处于活动状态（因为并发设置为5）。 现在，事件以上述顺序消费。 线程1提取事件1。 当线程1仍在积极地处理event1时，另一个线程只是从流中选择并开始处理下一个事件（线程2处理event2等等）。 尽管在这种情况下事件的顺序得以保留（事件1总是在事件2之前拾取，依此类推……），但不能保证线程1将在线程2之前完成对事件1的处理。
4. 当所有5个线程都忙于处理流中的5个事件时，如果新事件说有event6和event7进入，则使用者必须等待线程变为可用。 假设线程3完成了对事件3的处理，而其他线程仍在忙于处理事件，线程3将拾取事件6并开始处理，但由于没有可用线程，事件7仍未拾取。
5. 默认情况下，并发性设置为1。如果您的业务需求要求您在处理下一个事件之前先完成处理第一个事件，那么并发性应该为1。在这种情况下，您要牺牲吞吐量。 您一次只能消费一个事件。 但是，如果吞吐量很重要，并且您想在给定的时间点处理多个事件，则应将并发设置为所需的值。 增加分片数量也是一种选择，但是作为消费者，如果您不能要求增加数量，那么这是实现并行性/吞吐量的最佳选择。

Answer 1

请在KinesisMessageDrivenChannelAdapter查看concurrency选项JavaDocs：

/**
 * The maximum number of concurrent {@link ConsumerInvoker}s running.
 * The {@link ShardConsumer}s are evenly distributed between {@link ConsumerInvoker}s.
 * Messages from within the same shard will be processed sequentially.
 * In other words each shard is tied with the particular thread.
 * By default the concurrency is unlimited and shard
 * is processed in the {@link #consumerExecutor} directly.
 * @param concurrency the concurrency maximum number
 */
public void setConcurrency(int concurrency) {

因此，由于在一个流中只有一个分片，所以将只有一个活动线程在该单个分片上的ShardIterator上进行迭代。

关键是我们总是必须在单个线程中处理单个碎片中的记录。 这样，我们保证顺序正确，并为最高的序列号加上了检查点。

请进一步研究什么是AWS Kinesis及其工作方式。