用例：使用外部数据源和自定义操作限制吞吐量 limit-throughput
用例描述
Adobe Journey Optimizer允许从业人员通过使用自定义操作和数据源向外部系统发送API调用。
这可以通过以下方式完成：
-
数据源：从外部系统收集信息并在旅程上下文中使用它，例如，获取有关个人资料城市的天气信息，并根据该信息制定专用旅程流。
-
自定义操作：向外部系统发送信息，例如，使用Journey Optimizer的编排功能以及用户档案信息、受众数据和历程上下文通过外部解决方案发送电子邮件。
如果您使用的是外部数据源或自定义操作，则可能需要通过限制历程吞吐量来保护外部系统：单一历程每秒最多5000个实例，受众触发的历程每秒最多20000个实例。
对于自定义操作，可在产品级别使用限制功能。 请参阅此 页面.
对于外部数据源，您可以在端点级别定义上限限制，以避免通过Journey Optimizer的上限API淹没这些外部系统。 但是，将丢弃达到限制后剩余的所有请求。 在此部分中，您将找到可用于优化吞吐量的解决方法。
有关如何与外部系统集成的更多信息，请参阅此 页面.
实施
对象 受众触发的历程，您可以定义将影响历程吞吐量的读取受众活动的读取率。 了解详情
您可以将此值从每秒500个实例修改为每秒20 000个实例。 如果您需要低于500/s，您还可以添加包含等待活动的“百分比拆分”条件，将您的历程拆分为多个分支，并在特定时间执行这些分支。
让我们举一个例子 受众触发的历程 使用人群 10 000个配置文件 并将数据发送到外部系统，支持 100个请求/秒.
-
您可以定义读取受众以读取吞吐量为500个配置文件/秒的配置文件，这意味着读取所有配置文件将需要20秒。 在第二个1，您将阅读其中500篇内容，在第二个2,500多篇内容中，依此类推。
-
然后，您可以添加“百分比拆分”条件活动，按20%进行拆分，以使每个分支中每秒有100个用户档案。
-
之后，在每个分支中添加具有特定计时器的等待活动。 这里我们设定了30秒的等待时间。 每秒有100个配置文件流入每个分支。
-
在分支1上，它们将等待30秒，这意味着：
- 在第1秒，100个配置文件将等待第31秒
- 在第二个2上，100个配置文件将等待第二个32等。
-
在分支2上，它们将等待60秒，这意味着：
- 在第二个1,100个配置文件将等待第二个61 (1'01")
- 在第二个2,100个配置文件将等待第二个62 (1'02")等。
-
鉴于我们预计读取所有用户档案的最大时间为20秒，因此每个分支之间不会重叠，第20个分支是最后一个将用户档案流入条件的分支。 在第二个31和第二个51之间，将处理分支1中的所有配置文件。 在第61秒(1'01")和第81秒(1'21")之间，将处理分支2中的所有用户档案等。
-
作为护栏，您还可以添加第六个分支，使每个分支具有少于100个配置文件，尤其是如果外部系统仅支持100个请求/秒时。
-
作为额外的护栏，您还可以使用上限功能。