用例：使用外部数据源和自定义操作限制吞吐量

用例描述

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个请求/秒。

重要

与任何解决方法一样，请在进入生产环境之前彻底测试该解决方案，以确保它符合您的要求。

作为附加护栏，您还可以使用上限功能。

注意

与通过对沙盒的所有历程全局保护端点的上限功能不同，此解决方法仅在历程级别起作用。这意味着，如果多个历程并行运行并定位同一端点，则需要在设计历程时考虑这一点。因此，此解决方法不适用于每个用例。