ACAL Lynxus 用户指南

添加组件时，可以按版本号排序或按来源筛选。

按版本排序时，点击版本列以按升序或降序显示。

按来源组筛选时，点击添加组件对话框左上角的来源下拉菜单，选择要查看的组。

要更改组件版本，请执行以下步骤。

配置组件时，还可以查看版本依赖关系的信息。

在以下示例中，MyProcessor 1.0 版本与控制器服务 StandardMyService 1.0 版本正确配置：

如果将 MyProcessor 的版本更改为不兼容的版本（MyProcessor 2.0），处理器上将显示验证错误：

并且由于服务不再有效，处理器的控制器服务配置中将显示错误消息：

处理器配置对话框中的第一个选项卡是“设置”选项卡：

此选项卡包含多个不同的配置项。首先，它允许数据流管理员更改处理器的名称。处理器的名称默认与处理器类型相同。处理器名称旁边有一个复选框，指示处理器是否已启用。将处理器添加到画布时，它处于启用状态。如果处理器被禁用，则无法启动。禁用状态用于指示当一组处理器启动时，例如当数据流管理员启动整个流程组时，应排除此（已禁用的）处理器。

在名称配置下方，显示处理器的唯一标识符以及处理器的类型和 NAR 包。这些值无法修改。

接下来是两个用于配置“惩罚时长”和“让出时长”的对话框。在正常处理数据（FlowFile）的过程中，可能会发生某个事件表明此时无法处理该数据，但该数据可能在稍后可以处理。当这种情况发生时，处理器可以选择惩罚 FlowFile。这将阻止 FlowFile 在一段时间内被处理。例如，如果处理器要将数据推送到远程服务，但远程服务已经存在与处理器指定的文件名同名的文件，处理器可以惩罚 FlowFile。“惩罚时长”允许数据流管理员指定FlowFile 应被惩罚多长时间。默认值为 30 秒。

类似地，处理器可能会确定存在某种情况，使得处理器无法继续取得任何进展，无论它正在处理什么数据。例如，如果处理器要将数据推送到远程服务，而该服务没有响应，处理器就无法取得任何进展。因此，处理器应该“让出”，这将阻止处理器在一段时间内被调度运行。该时间段通过设置“让出时长”来指定。默认值为 1 秒。

设置选项卡左侧最后一个可配置选项是公告级别。每当处理器写入日志时，处理器还会生成一个公告。此设置指示应在用户界面中显示的最低公告级别。默认情况下，公告级别设置为 WARN，这意味着它将显示所有警告和错误级别的公告。

处理器配置对话框中的第二个选项卡是“调度”选项卡：

属性选项卡提供了一种配置处理器特定行为的机制。没有默认属性。每种类型的处理器必须定义哪些属性适用于其用例。下面，我们看到 RouteOnAttribute 处理器的属性选项卡：

此处理器默认只有一个属性：“路由策略”。默认值为“路由到属性名”。此属性名称旁边有一个小问号符号（）。此帮助符号在用户界面的其他位置也可以看到，它表示有更多信息可用。将鼠标悬停在此符号上将提供有关该属性和默认值的更多详细信息，以及已为该属性设置的历史值。

单击属性的值将允许数据流管理员更改该值。根据属性允许的值，用户将获得一个下拉列表以从中选择值，或者获得一个文本区域以输入值：

选项卡的右上角有一个用于添加新属性的按钮。单击此按钮将向数据流管理员提供一个对话框，用于输入新属性的名称和值。并非所有处理器都允许用户自定义属性。在不允许用户自定义属性的处理器中，应用用户自定义属性时处理器将变为无效。

选定的处理器支持用户自定义属性的可配置敏感值状态。处理器必须指示支持可配置敏感值状态，否则“添加属性”对话框中的敏感值选择将被禁用。

为敏感值设置选择 Yes 将指示 Lynxus 将属性值作为敏感值处理，用于配置持久化和框架操作。Lynxus 在存储流程配置时加密敏感值，并且不在导出的流程定义中包含敏感值。

RouteOnAttribute 允许用户自定义属性，在用户添加属性之前将处于无效状态。

请注意，添加用户自定义属性后，该行右侧将出现一个图标（）。单击它将删除处理器中的用户自定义属性。

某些处理器还内置了高级用户界面（UI）。例如，UpdateAttribute 处理器具有高级 UI。要访问高级 UI，请单击“配置处理器”窗口底部显示的“高级”按钮。只有具有高级 UI 的处理器才会有此按钮。

某些处理器具有引用其他组件的属性，例如控制器服务，这些组件也需要配置。例如，GetHTTP 处理器具有一个 SSLContextService 属性，该属性引用 StandardSSLContextService 控制器服务。当数据流管理员想要配置此属性但尚未创建和配置控制器服务时，他们可以选择立即创建该服务，如下图所示。有关配置控制器服务的更多信息，请参阅 控制器服务 部分。

关系选项卡包含一个“自动终止/重试关系”部分。此处列出了处理器定义的每个关系及其描述。

处理器配置对话框中的最后一个选项卡是“注释”选项卡。此选项卡仅为用户提供一个区域，用于输入适合此组件的任何注释。使用“注释”选项卡是可选的：

您可以通过右键点击处理器并从上下文菜单中选择“用法”来访问有关每个处理器用法的其他文档。或者，从 UI 右上角的全局菜单中选择帮助，以显示包含所有文档的帮助页面，包括所有可用处理器的用法文档。单击所需的处理器以查看用法文档。

此选项卡包含多个不同的配置项。首先是流程组名称。这是显示在画布上流程组顶部以及 UI 底部面包屑中的名称。对于根流程组（即最高级别的组），这也是显示为浏览器选项卡标题的名称。请注意，此信息对远程连接到此实例的任何其他 Lynxus 实例（使用远程流程组，即 站点到站点）可见。

下一个配置元素是流程组参数上下文，用于为流程组件提供参数。从此下拉列表中，用户可以选择应将哪个参数上下文绑定到此流程组，并可以选择创建一个新参数上下文绑定到流程组。有关更多信息，请参阅 参数 和 参数上下文。

下一部分提供用于确定流程组应如何调度运行的配置元素。Lynxus支持两种不同的执行引擎：传统执行引擎和无状态执行引擎。此外，执行引擎可以从父流程组继承，这是默认行为。有关更多信息，请参阅 执行引擎。

接下来两个元素——流程组 FlowFile 并发和流程组出站策略——将在以下部分中介绍。

流程组配置对话框中的控制器服务选项卡在 为数据流添加控制器服务 中介绍。

参数在参数上下文中创建。参数上下文是对 Lynxus 实例全局定义/可访问的。可以将访问策略应用于参数上下文，以确定哪些用户可以创建它们。创建后，还可以应用读取和写入特定参数上下文的策略（有关更多信息，请参阅 访问参数）。

可以在参数上下文创建期间添加参数，也可以添加到现有参数上下文。

在参数上下文创建期间，选择“参数”选项卡。单击 + 按钮打开添加参数窗口。

要向现有参数上下文添加参数，请打开参数上下文窗口并单击所需参数上下文行中的编辑按钮（）。

在“参数”选项卡上，单击 + 按钮打开添加参数窗口。

添加参数窗口具有以下设置：

配置这些设置后，选择“应用”。“引用组件”列出当前选定参数引用的组件。添加其他参数或编辑任何现有参数。

要完成该过程，请从参数上下文窗口中选择“应用”。将执行以下操作来验证引用已添加或修改参数的所有组件：停止/重新启动受影响的处理器、禁用/重新启用受影响的控制器服务、更新参数上下文。

“引用组件”部分现在列出了按流程组组织的已添加/编辑/删除的参数集引用的所有组件的汇总。

添加使用表达式语言的参数时，了解表达式语言将在哪个上下文中进行计算非常重要。表达式始终在引用参数的处理器或控制器服务的上下文中进行计算。例如，考虑一个场景，添加一个名为 Time 的参数，其值为 ${now()}。表达式语言会在计算时调用以确定系统时间。当作为参数添加时，系统时间不会在添加参数时计算，而是在处理器或控制器服务计算表达式时计算。也就是说，如果处理器有一个属性值设置为 #{Time}，它的功能将与属性的值设置为 ${now()} 完全相同。每次引用该属性时，都会产生不同的时间戳。

此外，某些属性不允许使用表达式语言，而其他属性允许使用表达式语言但不对 FlowFile 属性进行表达式计算。为了帮助理解其工作原理，考虑一个名为 File 的参数，其值为 ${filename}。然后考虑三个不同的属性，每个属性具有不同的表达式语言范围和一个文件名为`test.txt` 的 FlowFile。如果每个属性都设置为 #{File}，则下表说明了结果值。

要使组件引用参数，必须首先为其流程组分配一个参数上下文。分配后，该流程组内的处理器和控制器服务只能引用该参数上下文中的参数。

一个流程组只能分配一个参数上下文，而一个参数上下文可以分配给多个流程组。

要将参数上下文分配给流程组，请从操作面板或流程组上下文菜单中单击“配置”。

在流程配置窗口中，选择“常规”选项卡。从流程组参数上下文下拉菜单中，选择现有的参数上下文或创建一个新的。

选择“应用”保存配置更改。流程组上下文菜单现在包含“参数”选项，允许快速访问已分配参数上下文的更新参数上下文窗口。

如果流程组的参数上下文发生更改，所有引用该流程组中任何参数的组件将被停止、验证并重新启动，前提是这些组件之前正在运行且仍然有效。

参数提供程序允许将参数存储在 Lynxus 外部的来源中（例如 HashiCorp Vault）。可以获取参数提供程序的参数并将其应用于所有引用的参数上下文。

要添加参数提供程序，请从全局菜单中选择控制器设置。

这将显示 Lynxus 设置窗口。选择参数提供程序选项卡并点击右上角的 + 按钮以创建新的参数提供程序。

将打开添加参数提供程序窗口。此窗口类似于添加处理器窗口。它在右侧提供可用参数提供程序的列表，在左侧显示标签云，显示用于参数提供程序的最常见类别标签。数据流管理员可以单击标签云中的任何标签，以将参数提供程序列表缩小到符合所需类别的那些。数据流管理员还可以使用窗口右上角的筛选字段搜索所需的参数提供程序，或使用左上角的来源下拉列表按创建者组筛选列表。从列表中选择参数提供程序后，数据流管理员可以在下方看到该提供程序的描述。选择所需的参数提供程序并单击添加，或简单地双击提供程序名称以添加它。

添加参数提供程序后，数据流管理员可以通过单击最右列中的“编辑”按钮来配置它。此列中的其他按钮包括“获取参数”、“删除”和“访问策略”。

您可以通过单击左列中的“查看详细信息”、“用法”和“警报”按钮来获取有关参数提供程序的信息。

当数据流管理员单击“编辑”按钮时，将打开配置参数提供程序窗口。它有三个选项卡：设置、属性和注释。此窗口类似于配置处理器窗口。“设置”选项卡为数据流管理员提供了一个为参数提供程序指定唯一名称的位置（如果需要）。它还列出了提供程序的 UUID、类型和包信息，并显示引用该参数提供程序的其他组件（例如参数上下文）的列表。数据流管理员可以将鼠标悬停在问号图标上以查看有关每个设置的更多信息。

“属性”选项卡列出了可以为参数提供程序配置的各种属性。数据流管理员可以将鼠标悬停在问号图标上以查看有关每个属性的更多信息。

“注释”选项卡只是一个开放文本字段，数据流管理员可以在其中包含有关提供程序的注释。配置参数提供程序后，单击“应用”保存配置并关闭窗口，或单击“取消”放弃更改并关闭窗口。

当要从参数提供程序获取参数时，单击“获取”按钮（）。

用户对参数的权限通过以下级别的访问策略进行管理：

要添加管理控制器服务，请从全局菜单中选择控制器设置。

这将显示 Lynxus 设置窗口。该窗口有六个选项卡：常规、管理控制器服务、报告任务、流程分析规则、注册表客户端和参数提供程序。“常规”选项卡提供实例整体最大线程数的设置。

“常规”选项卡右侧是“管理控制器服务”选项卡。从此选项卡中，数据流管理员可以点击右上角的 + 按钮来创建新的控制器服务。

将打开添加控制器服务窗口。此窗口类似于添加处理器窗口。它在右侧提供可用控制器服务的列表，在左侧显示标签云，显示用于控制器服务的最常见类别标签。数据流管理员可以单击标签云中的任何标签，以将控制器服务列表缩小到符合所需类别的那些。数据流管理员还可以使用窗口右上角的筛选字段搜索所需的控制器服务，或使用左上角的来源下拉列表按创建者组筛选列表。从列表中选择控制器服务后，数据流管理员可以在下方看到该服务的描述。选择所需的控制器服务并单击添加，或简单地双击服务名称以添加它。

添加控制器服务后，可以通过单击最右列中的“配置”按钮来配置它。此列中的其他按钮包括“启用”、“删除”和“访问策略”。

您可以通过单击左列中的“用法”、“注释”和“警报”按钮来获取有关控制器服务的信息。

当数据流管理员单击“配置”按钮时，将打开配置控制器服务窗口。它有三个选项卡：设置、属性和注释。此窗口类似于配置处理器窗口。

“设置”选项卡为数据流管理员提供了一个为控制器服务指定唯一名称的位置（如果需要）。它还列出了服务的 UUID、类型、包和支持信息，并提供了引用该服务的其他组件（报告任务或其他控制器服务）的列表。

最后，可以修改公告级别。每当控制器服务写入其日志时，控制器服务还会生成一个公告。此设置指示应在用户界面中显示的最低公告级别。默认情况下，公告级别设置为 WARN，这意味着它将显示所有警告和错误级别的公告。

“属性”选项卡列出了适用于特定控制器服务的各种属性。与配置处理器一样，数据流管理员可以将鼠标悬停在问号图标上以查看有关每个属性的更多信息。

“注释”选项卡只是一个开放文本字段，数据流管理员可以在其中包含有关服务的注释。配置控制器服务后，单击“应用”保存配置并关闭窗口，或单击“取消”放弃更改并关闭窗口。

要为数据流添加控制器服务，您可以右键点击流程组并选择配置，或从操作面板中单击配置。

当您在画布上未选择任何内容时从操作面板中单击配置时，您将为根流程组添加控制器服务。然后，该控制器服务可用于数据流中所有嵌套的流程组。当您在画布上选择一个流程组，然后从操作面板或流程组上下文菜单中单击配置时，该服务将可用于该流程组及其以下定义的所有处理器和控制器服务。

使用以下步骤添加控制器服务：

配置控制器服务后，必须启用它才能运行。使用控制器服务选项卡最右列中的“启用”按钮（）执行此操作。要修改现有/正在运行的控制器服务，数据流管理员需要停止/禁用它（以及所有引用的报告任务和控制器服务）。使用“禁用”按钮（）执行此操作。数据流管理员不必逐个查找该控制器服务引用的每个组件，而是在禁用相关控制器服务时可以停止/禁用它们。启用控制器服务时，数据流管理员可以选择启动/启用控制器服务及所有引用组件，或者仅启动/启用控制器服务本身。

“创建连接”对话框的“详细信息”选项卡提供有关源组件和目标组件的信息，包括组件名称、组件类型以及组件所在的流程组：

此外，此选项卡提供了选择此连接中应包含哪些关系的能力。必须选择至少一个关系。如果只有一个关系可用，则会自动选择它。

“设置”选项卡提供了配置连接名称、FlowFile 过期、反压阈值、负载均衡策略和优先化的能力：

连接名称是可选的。如果未指定，连接显示的名称将是对连接活动的关系的名称。

在两个组件之间绘制连接后，可以更改连接的配置，也可以将连接移动到新目标；但是，在进行配置或目标更改之前，必须停止连接两侧的处理器。

要更改连接的配置或以其他方式与连接交互，请右键点击连接以打开连接上下文菜单。

以下选项可用：

要向现有连接添加弯曲点（或弯头），只需在希望弯曲点所在的位置双击连接。然后，您可以使用鼠标抓住弯曲点并拖动它，使连接以所需方式弯曲。您可以添加任意数量的弯曲点。您还可以使用鼠标将连接上的标签拖动并移动到任何现有弯曲点。要删除弯曲点，只需再次双击它。

远程流程组：要通过站点到站点与远程 Lynxus 实例通信，只需将 远程流程组 拖动到画布上并输入远程 Lynxus 实例的 URL（有关远程流程组组件的更多信息，请参见本指南的 远程流程组传输 部分。）该 URL 与您用于访问该实例用户界面的 URL 相同，对于集群，则为集群节点的 URL。此时，您可以以与拖动处理器或本地进程组连接相同的方式拖动到远程流程组或从其拖动连接。拖动连接时，您将有机会选择要连接的端口。请注意，远程流程组可能需要最多一分钟来确定哪些端口可用。

如果从远程流程组开始拖动连接，显示的端口将是远程组的输出端口，因为这表示您将从远程实例拉取数据。如果连接改为在远程流程组结束，显示的端口将是远程组的输入端口，因为这表示您将向远程实例推送数据。

传输协议：在远程流程组创建或配置对话框中，您可以选择用于站点到站点通信的传输协议，如以下图所示：

默认情况下，它设置为 RAW，使用专用端口的原始套接字通信。如果远程Lynxus 实例在仅允许通过 HTTP(S) 协议访问或只能从特定 HTTP 代理服务器访问的受限网络中，HTTP 传输协议特别有用。对于通过 HTTP 代理服务器访问，支持 BASIC 和 DIGEST 身份验证。

本地网络接口：在某些情况下，可能希望优先使用某个网络接口而不是另一个。例如，如果有线接口和无线 接口同时存在，可能希望优先使用有线接口。这可以通过在此框中指定要使用的网络接口名称来配置。如果输入的值无效，远程流程组将无效，并且在解决此问题之前不会与其他 Lynxus 实例通信。

检索站点到站点详情：如果您的 Lynxus 安全运行，为了允许另一个 Lynxus 实例从您的实例检索信息，需要将其添加到全局访问的“检索站点到站点详情”策略中。这将允许另一个实例查询您的实例以获取名称、描述、可用对等方（集群中的节点）、统计信息、操作系统端口信息以及可用的输入和输出端口等详情。在安全实例中使用输入和输出端口需要额外的策略配置，如下所述。

输入端口：为了允许另一个 Lynxus 实例向您的本地实例推送数据，您可以简单地将 输入端口 拖动到画布的根进程组上。输入端口名称后，它将被添加到您的流程中。现在，您可以右键点击输入端口并选择“配置”以调整名称和用于该端口的并发任务数。

要在子流程组中为站点到站点创建输入端口，请输入端口名称并从接收自下拉菜单中选择“远程连接（站点到站点）”。

如果站点到站点配置为安全运行，您将需要管理输入端口的“通过站点到站点接收数据”组件访问策略。只有已添加到策略中的用户才能与该端口通信。

输出端口：与输入端口类似，数据流管理员可以选择将 输出端口 添加到根进程组。输出端口允许经过授权的 Lynxus 实例远程连接到您的实例并从输出端口拉取数据。将输出端口拖动到画布后，右键点击并选择“配置”以调整名称和允许的并发任务数。管理输出端口的“通过站点到站点接收数据”组件访问策略以控制哪些用户有权从正在配置的实例拉取数据。

要在子进程组中创建用于站点到站点的输出端口，请输入端口名称并从“发送到”下拉菜单中选择“远程连接（站点到站点）”。

除了其他 Lynxus 实例之外，某些其他应用程序也可以使用站点到站点客户端来向 Lynxus 实例推送数据或从其接收数据。

传统引擎单独调度每个处理器。一个处理器可以配置为每五分钟运行一次，而另一个处理器被调度为尽可能快地运行，使用八个并发任务。处理器之间队列的主要工作是允许处理器以不同的速率运行。如果源运行速度比目标快，它将排队数据直到达到配置的反压阈值。然后，源将停止生成数据，以便目标有机会赶上。如果排队了太多 FlowFile，FlowFile（即属性等）将被交换到磁盘，以避免耗尽 Java 堆。这种方法使流程开发人员能够非常精细地控制在整个管道中为每个处理步骤分配多少资源。

相比之下，无状态引擎使用单个线程从头到尾运行整个流程。首先触发源组件以将数据引入流程。如果 FlowFile 被引入流程，则触发数据所在队列的目标，直到它处理完所有数据。大多数时候，这是处理器的单次调用。然后触发流程中的下一个处理器运行，依此类推。为队列配置的任何反压都将被忽略。FlowFile 永远不会交换到磁盘。但是，这通常不是问题，因为流程中通常一次只处理一个 FlowFile。

但是，在配置用于流程组的执行引擎时，流程开发人员能够指定用于无状态引擎的最大并发任务数。如果值设置为 N（大于 1），将有 N 个无状态流程副本并发运行。对于每个流程副本，将触发源组件，然后触发下一个处理器，依此类推。需要注意的是，如果 N 大于 1，则流程中的每个处理器将有 N 个副本用于处理数据。因此，如果处理器需要在内部存储对象，例如 MergeContent，则每个流程副本都有该内部状态的单独副本。因此，如果 MergeContent 配置为需要至少 1,000 个 FlowFile 才能合并，并且流程以 8 个并发任务运行，则 8 个流程中的每一个可能有多达 999 个 FlowFile，总计 7,992 个 FlowFile，而不会合并任何数据。因此，流程设计人员在使用无状态引擎与必须等待某些条件才能继续的处理器时应谨慎。

无状态流程还可能包含不需要持续运行的源处理器。例如，GetFile 处理器可能是流程中的第一个处理器。可能希望每 5 分钟只运行一次处理器。这可能会使事情复杂化，因为处理器不是单独调度的。为此，会检查所有源处理器以确定它们应多久被调度一次。具有最小运行计划（即调度最快）的组件将决定无状态流程应多久调度一次。例如，如果有一个配置为每小时运行一次的 ListFile 处理器和一个配置为每分钟运行一次的 ListS3 处理器，两个源处理器都将被触发每分钟运行一次。

使用无状态引擎时，始终使用定时器驱动调度器。目前无状态流程不支持 CRON 调度。如果需要 CRON 调度，通常足以对 CRON 驱动的处理器使用传统引擎，然后将其连接到无状态流程组。

传统引擎允许为每个处理器配置运行时长。这通常极大地提高了性能。使用无状态流程时不可用此功能。对于无状态流程，这会根据流程中使用的处理器自动为您管理。如果流程中的任何处理器需要串行触发，无状态流程将不会使用大于单次调用的运行时长。否则，它将运行最多 100 毫秒。如果任何调用产生失败，运行时长将被缩短。

事务性可能是传统引擎和无状态引擎之间最显著的区别。对于传统引擎，处理器是事务边界。也就是说，处理器对 FlowFile 执行某些操作，然后事务完成。FlowFile 被传输到流程中的下一个处理器，而第一个处理器执行任何类型的清理。

例如，考虑一个从 JMS 队列消费的处理器。使用传统引擎，处理器将从 JMS 消费消息。然后，它将基于JMS 消息创建一个 FlowFile，并将 FlowFile 传输到 success 关系并提交会话。此时，框架将确保数据已持久化到底层存储库并将 FlowFile 添加到出站队列。最后，JMS 消费者将获得确认收到消息的机会。

此时，FlowFile 可能发生各种情况。它可能被丢弃。它可能被转换。它可能被推送到两个不同的目标。或者它可能留在流程中，因为某个下游系统（如数据库）已关闭。但是，消息已被确认，不会被重新传递。因此，Lynxus 持久化该数据很重要，这样在重新启动时它可以完成数据的处理。

这种范式的一个强大优势是源不需要是持久化或事务性的。例如，客户端可以向 Lynxus 发送 HTTP POST 请求以提供数据。只要Lynxus 以“200 OK”或“201 Created”或类似消息响应，就可以假设消息将按照流程处理。

另一方面，如果数据源实际上是事务性的，例如 JMS 队列，这可能不太理想。如果 Lynxus 被关闭，可能是由于硬件故障，已确认的数据将不会被重新传递。Lynxus 实例拥有该数据，必须重新启动才能完成数据的处理。

但是，当使用无状态引擎时，语义会发生变化。事务边界不再是处理器，而是整个流程组。当使用无状态引擎运行相同的流程时，JMS 消费者仍然接收 JMS 消息并从中创建 FlowFile。它仍然将 FlowFile 传输到 `success`关系并提交会话。但是，使用无状态引擎时，不是将数据持久化到底层存储库并给予 JMS 消费者确认收到消息的机会，而是将 FlowFile 传递给下一个处理器。然后该处理器处理 FlowFile 并传递它。在 FlowFile 成功运行完整个流程之前，JMS 消费者不会获得确认消息的机会。

现在，这提供了一种关于如何构建流程的完全不同的思维方式。它还提供了一些重要的新功能。例如，我们现在可以让后续处理器指示数据处理失败。为此，可以将输出端口配置为“失败端口”。

现在，如果任何 FlowFile 被路由到此端口，整个事务将被回滚。流程中的任何 FlowFile 将被丢弃。JMS 消费者不会确认消息，而是发送回“否定确认”，即 NAK。因此，JMS 代理将在稍后重新传递消息。这种方法的主要好处是，如果 Lynxus 实例被关闭（例如，由于硬件故障或将 Lynxus 实例重新调度到云环境中的其他位置运行），另一个 Lynxus 实例（或完全不同的其他软件）可以消费 JMS 消息并处理它。无需确保 Lynxus 实例能够重新启动。

此外，与失败概念相关的是使用无状态引擎时的超时概念。流程组的配置选项之一是“无状态流程超时”。这允许我们确保数据在预期的时间内被处理，如果没有则回滚整个事务。默认情况下，超时设置为 1 分钟。任何被引入无状态流程的数据必须在 1 分钟内完成处理，否则将发生超时，整个事务将被回滚。传统引擎没有数据流超时的概念。

我们还必须考虑无状态流程以输入端口启动时使用的事务性。例如，我们可能使用使用传统引擎的流程组从任意数量的来源消费数据。然后，我们可能使用无状态流程处理数据。在这种情况下，如果任何数据被路由到失败端口，整个事务将被回滚，并且原始输入 FlowFile 将被传输到失败端口——而不是触发失败的 FlowFile。如果发生超时，原始 FlowFile 将被惩罚并传输回其原始队列，以便可以再次处理。

Lynxus 的一个关键优势是其数据持久性。虽然许多 ETL 产品和数据移动工具提供内存处理，但 Lynxus 提供的是数据持久性。所有数据都持久化到底层存储库。重新启动后，Lynxus 从上次中断的地方继续处理数据。这意味着它几乎可以可靠地处理任何协议，即使是接收方不发送回应用程序级别确认的协议（如直接 TCP 连接）。

但是，虽然这对传统引擎成立，但对无状态引擎不成立。相反，无状态引擎在设计上会在重新启动时丢弃数据。这意味着如果必须由 Lynxus 持久化数据，无状态引擎不是安全的选择。但是，对于提供应用程序级别确认的协议（如 JMS、Apache Kafka、Amazon Kinesis 等），它是一个很好的选择。此外，对于 HTTP 等协议，Lynxus 提供了能够接收数据、执行一些处理然后发送确认的处理器。因此，即使 Lynxus 负责接受传入连接也是安全的。这里的关键是从 Lynxus 发送的应用程序级别确认消息。

Lynxus 提供了通过使用 FlowFile 优先化器对每个队列中的数据进行排序的能力。这允许数据流开发人员确定特定数据最为重要并确保其首先被处理和/或发送到目的地。这在通信介质不太可靠的场所被证明特别强大，在这些场所通信通道可能间歇性中断，当通道恢复时需要尽快利用以发送最重要的数据。

然而，无状态引擎旨在以更高程度的事务性处理数据，通常不会在目标不可达时缓冲大量数据。因此，它会忽略配置的优先化器，始终使用先进先出（FIFO）队列处理数据。

在正常情况下，使用无状态引擎的流程产生的数据溯源会持久化到与传统引擎相同的底层溯源存储库中，因此溯源数据的显示方式相同。但是，由于无状态引擎可能会在失败时回滚事务，我们需要考虑这对数据溯源的影响。否则，我们可能会显示内容已被修改，然后属性被修改，数据被克隆——但重新启动后数据仍然会排队在无状态引擎外部，这会让我们误以为 FlowFile 的内容与实际不同。

因此，在无状态流程的事务完成之前，溯源事件不会存储到溯源存储库中。如果 FlowFile 被路由到故障端口，或者调用超时，溯源事件将被丢弃。但是，此规则有两个例外：SEND 和 REMOTE_INVOCATION 事件。即使事务被回滚，数据已发送或某个远程调用已发生的事实也无法回滚。因此，溯源存储库仍会被更新以记录这些事件的发生。

Lynxus 的站点到站点机制提供了一种以高效、可靠和安全的方式发送 FlowFile（包括其属性）从一个 Lynxus 实例到另一个的方法。这需要一个 Lynxus 实例使用远程流程组，该流程组充当客户端并建立到另一个 Lynxus 实例的套接字连接。使用传统引擎时，两个 Lynxus 实例都可以充当客户端或服务器。也就是说，它既可以使用远程流程组，也可以使用允许远程连接的输入端口。使用无状态引擎时，Lynxus 实例可以使用远程流程组并充当客户端来推送或拉取数据。但是，它不能使用允许远程连接的输入端口，因此不能充当服务器。

当使用无状态引擎且并发任务数设置为大于 1 的值时，每个并发任务都使用每个处理器的不同副本运行。因此，需要保持内部状态的处理器不会在流程副本之间共享该状态。例如，如果流程有一个 MergeContent 处理器必须在合并数据之前累积 1,000 个 FlowFile，并且并发任务数设置为 3，则每个并发任务可能有多达 999 个 FlowFile，总计2,997 个 FlowFile 而数据未被合并。在设计需要处理器内部状态的流程时，请记住这一点。

此外，因此，任何包含调度为仅在主节点上运行的处理器的流程都仅限于使用单个并发任务。将值设置为大于 1 将在启动时记录警告，并且无论配置值如何，都将使用值 1。

无状态引擎允许将输出端口配置为"故障端口"，这意味着如果任何 FlowFile 到达该输出端口，整个事务将失败。此输出端口可以位于流程组层次结构的任何级别。如果发生这种情况，整个事务将被回滚。也就是说，当前在该事务中处理的任何 FlowFile 将被丢弃。如果事务的源是输入端口，则通过该输入端口引入的 FlowFile 将被传输到给定的故障输出端口。如果事务的源是处理器，则该处理器将有机会发送否定确认（"NAK"）或根据需要清理任何资源。

如果无状态流程未在配置的超时时间内完成，事务也将被回滚，方式与 FlowFile 被路由到故障端口时非常相似。但是，有一个非常显著的区别。故障端口指示将传入的 FlowFile 路由到哪里，而超时没有指定这样的输出。相反，输入 FlowFile（如果存在）将被惩罚并添加回其输入队列，以便在延迟一段时间后可以重试。

由于无状态事务可能会被回滚，通常最佳实践是让流程由单个源和单个目标组成。考虑从单个源接收 FlowFile 的情况。然后将其发送到三个不同的目标。在成功发送到三个目标中的两个后，由于第三个目标因定期维护而关闭，发送到第三个目标失败。结果，事务被回滚。然后数据被第二次拉取。它再次成功发送到前两个目标，并再次无法推送到第三个目标。它再次被回滚。这可能会发生多次，每次数据都被发送到前两个目标。或者有时它只被发送到第一个目标而第二个失败。

在这种情况下，当前两个目标是幂等的时，流程充其量效率很低。最坏的情况下，第一个和第二个目标不是幂等的，并且存在非常大量的、不受控制的数据重复。

如果流程由多个目标组成，这个问题会更加复杂。例如，考虑一个流程，它有两个处理器，每个负责从不同的源消费数据。然后将这些数据合并到一个 FlowFile 中，再推送到三个目标。现在，如果数据被回滚，源处理器可能会从每个源拉取不同的数据。因此，发布的数据不可能是幂等的，因为每次都由不同的数据组成，而且来自每个源的数据配对每次都不同。

因此，建议将无状态流程保持为单个源和单个目标。至少，除最后一个之外的目标应该是幂等的。

由于每个并发任务运行无状态流程的单独副本，重要的是要记住合并所需的最小传入 FlowFile 数量（通过 MergeContent或 MergeRecord）可能会随着并发任务数量的倍数而增加。因此，可能需要大量时间才能积累这么多数据。此外，无状态流程有超时限制其运行时间。因此，在配置这些类型处理器的限制时需要谨慎。

始终建议将最大 Bin 时长设置为小于无状态流程的超时时间，以确保数据流不会不断超时。虽然不断导致回滚事务的超时不应阻止正确的数据传递，但如果事务不断被回滚，它可能会导致不必要的延迟并使用大量计算资源。

因此，建议如果使用将多个 FlowFile 合并在一起的处理器，应将最小限制保持得足够小，使事务不会不断超时，或者为此类处理器配置最大 Bin 时长或等效设置，以便即使没有大量数据也能成功继续。还值得注意的是，如果需要更大的输出 FlowFile，使用较少的并发任务更有可能产生更大的输出，因为传入数据将分布在较少的流程副本上。

有时数据流管理员可能希望仅启用或禁用远程流程组中特定端口的传输。这可以通过右键点击远程流程组并选择"管理远程端口"菜单项来实现。这将提供一个配置对话框，从中可以配置端口：

左侧列出了远程 Lynxus 实例允许向其发送数据的所有输入端口。右侧列出了此实例能够从中拉取数据的所有输出端口。如果远程实例使用安全通信（Lynxus 实例的 URL 以 https:// 开头，而不是 http://），则远程实例未向此实例开放的任何端口都不会显示。

每个端口都显示其名称、描述、配置的并发任务数以及发送到此端口的数据是否将被压缩。此外，还显示端口配置的批处理设置（计数、大小和时长）。此信息左侧是一个用于打开或关闭端口的切换开关。没有连接的端口显示为灰色：

开/关切换开关提供了一种独立启用和禁用远程流程组中每个端口传输的机制。那些已连接但当前未传输的端口可以通过点击开/关切换开关下方的铅笔图标（）来配置。点击此图标将允许数据流管理员更改并发任务数、在向此端口发送或从该端口接收数据时是否应使用压缩，以及批处理设置。

对于输入端口，批处理设置控制 Lynxus 如何在事务中向远程输入端口发送数据。Lynxus 将传输 FlowFile，当它们在传入关系中排队时，直到达到任何限制（计数、大小、时长）。如果未配置任何设置，则默认使用 500 毫秒的批处理时长。

对于输出端口，批处理设置告诉远程 Lynxus，Lynxus 希望在事务中如何从远程输出端口接收数据。远程 Lynxus 将使用指定的设置（计数、大小、时长）来控制 FlowFile 的传输。如果未配置任何设置，则默认使用 5 秒的批处理时长。

以下是在画布上垂直对齐组件的示例。选中/高亮显示所有组件后，右键点击：

然后选择"垂直对齐"以达到以下效果：

以下是在画布上水平对齐组件的示例。选中/高亮显示所有组件后，右键点击：

然后选择"水平对齐"以达到以下效果：

可以通过从上下文菜单中选择"版本→显示本地更改"在"显示本地更改"对话框中查看对版本化流程组所做的本地更改。

您可以通过选择行中的"转到"图标（）导航到组件。

通过从上下文菜单中选择"版本→还原本地更改"来还原对版本化流程组所做的本地更改。"还原本地更改"对话框显示本地更改列表，供数据流管理员在启动还原之前审查和考虑。选择"还原"以移除所有更改。

您可以通过选择行中的"转到"图标（）导航到组件。

要提交并保存流程版本，请从上下文菜单中选择"版本→提交本地更改"。在"保存流程版本"对话框中，如果需要，添加备注并选择"保存"。

如果已修改的版本不是最新版本，则无法提交本地更改。在这种情况下，版本状态为"本地已修改且过时"（）。

在第一个示例中，sys_admin 在根流程组级别创建了一个 KeytabCredentialsService 控制器服务。

KeytabCredentialService 控制器服务是一个需要"access keytab"权限的受限组件：

Sys_admin 创建了一个包含 GetFile 和 PutHDFS 处理器的流程的进程组 ABC：

GetFile 处理器是一个需要"write filesystem"和"read filesystem"权限的受限组件：

PutHDFS 是一个需要"write filesystem"权限的受限组件：

PutHDFS 处理器配置为使用根流程组级别的 KeytabCredentialsService 控制器服务：

Sys_admin 将流程组保存为版本化流程：

Test_user 通过移除 KeytabCredentialsService 控制器服务来更改流程：

如果 test_user 选择还原此更改：

还原本成功：

此外，如果 test_user 选择导入 ABC 版本化流程：

导入成功：

现在，考虑第二种场景，其中控制器服务在流程组级别创建。

Sys_admin 创建了一个进程组 XYZ：

Sys_admin 在流程组级别创建了一个 KeytabCredentialsService 控制器服务：

在流程组中创建了相同的 GetFile 和 PutHDFS 流程：

但是，PutHDFS 现在引用流程组级别的控制器服务：

Sys_admin 将流程组保存为版本化流程。

Test_user 通过移除 KeytabCredentialsService 控制器服务来更改流程。但是，使用此配置，如果 test_user 尝试还原此更改：

还原不成功，因为 test_user 没有 KeytabCredentialService 控制器服务所需的"access keytab"权限：

类似地，如果 test_user 尝试导入 XYZ 版本化流程：

导入失败：

有时，用户可能需要追踪另一个 FlowFile 从中产生的原始 FlowFile。例如，当发生 FORK 或 CLONE 事件时，Lynxus 会跟踪产生其他 FlowFile 的父 FlowFile，并且可以在血缘中找到该父 FlowFile。右键点击血缘图中的事件并从上下文菜单中选择"查找父事件"。

选择"查找父事件"后，图表将重新绘制以显示父 FlowFile 及其血缘以及子 FlowFile 及其血缘。

与查找父 FlowFile 类似，用户可能还想确定从给定 FlowFile 产生了哪些子 FlowFile。为此，右键点击血缘图中的事件并从上下文菜单中选择"展开"。

选择"展开"后，图表将重新绘制以显示子 FlowFile 及其血缘。

默认值是为持久化溯源配置选择的。使用预写配置时应注意以下例外和建议：

完成这些属性更改后，重新启动 Lynxus。

注意： 有关这些属性的详细描述可在 系统属性 中找到。