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

用例描述

Adobe Journey Optimizer允许从业者通过使用自定义操作和数据源向外部系统发送API调用。

这可以通过以下方式完成:

  • 数据源:从外部系统收集信息并在旅程上下文中使用它,例如,获取有关用户档案城市的天气信息,并根据此信息制定专用旅程流。

  • 自定义操作:向外部系统发送信息,例如,通过使用Journey Optimizer的编排功能以及用户档案信息、受众数据和历程上下文,通过外部解决方案发送电子邮件。

如果您使用的是外部数据源或自定义操作,则可能需要通过限制历程吞吐量来保护外部系统:对于单一历程,每秒最多可处理5000个实例;对于区段触发的历程,每秒最多可处理20000个实例。

对于自定义操作,可在产品级别使用限制功能。 请参阅此 页面.

对于外部数据源,您可以在端点级别定义上限限制,以避免通过Journey Optimizer的上限API淹没这些外部系统。 但是,将丢弃达到限制后的所有剩余请求。 在此部分中,您将找到可用于优化吞吐量的解决方法。

有关如何与外部系统集成的更多信息,请参阅此 页面.

实施

对象 区段触发的历程,您可以定义将影响历程吞吐量的读取区段活动的限制速率。 了解详情

您可以将此值从每秒500个实例修改为每秒20 000个实例。 如果您需要低于500/s,您还可以添加包含等待活动的“百分比拆分”条件,以将您的历程拆分为多个分支,并在特定时间执行这些分支。

让我们举一个例子 区段触发的历程 使用人群 10 000个配置文件 并向外部系统发送数据,支持 每秒100个请求.

  1. 您可以定义读取区段来读取配置文件,其吞吐量为每秒500个配置文件,这意味着读取所有配置文件将需要20秒。 在第1行中,您将阅读其中500篇文章,在第2行中,再阅读500篇文章,依此类推。

  2. 然后,您可以添加“百分比拆分”条件活动,拆分20%,以便每秒在每个分支中拥有100个配置文件。

  3. 之后,在每个分支中添加带有特定计时器的等待活动。 这里我们设定了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个请求/秒。

重要

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

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

注意

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

在此页面上