图源：Unsplash
观察这些在Apache NiFi（版本1.8.0 ^）中执行负载平衡的最新方法，，你会发现，这些方法现在使远程进程组已过时。
如今在Apache NiFi中，有一种经过改进的新方法，用于平衡集群节点之间的数据负载。随着NiFi1.8.0的引入，连接负载平衡添加在所有连接中的处理器。现在有易于设置的选项，可以在节点之间自动进行负载平衡。
使用emoteProcess Groups在ApacheNiFi节点之间分配负载已经过时了。想要获得最高的灵活性、简便性和最好的性能，请确保升级现有流，使用内置的“连接负载平衡”。
如果运行的是Apache NiFi或Cloudera Flow Management (CFM)的较新版本，可以采用更好的方法在处理器和服务器之间分配处理。这适用于ApacheNiFi1.8.0和更高版本，包括最新版本1.10.0。
请注意:负载平衡不再需要Remote Process Groups！使用实际的负载平衡连接！RemoteProcess Groups只用于分发到其他集群。
Apache NiFi中的负载平衡
首先，我们简单了解一下Apache NiFi。
Apache NiFi是基于流程编程概念的数据流系统。它支持强大且可扩展的数据路由，转换和系统中介逻辑的有向图。
NiFi具有基于Web的用户界面，用于设计，控制，反馈和监控数据流。它在服务质量的几个方面具有高度可配置性，例如容错与保证交付，低延迟与高吞吐量以及基于优先级的排队。NiFi为所有接收，分叉，加入克隆，修改，发送和最终在达到其配置的最终状态时丢弃的数据提供细粒度数据来源。
自2018年以来，Apache NiFi已经成为很棒的功能。
配置连接
有一些负载平衡的选项，比如说“Round Robin”，它允许在出现故障时将数据重新平衡到另一个节点。它根据流文件的大小，每秒重新平衡数千个流文件。这样做使得节点有机会重新连接，并继续处理。
负载平衡循环
另一种选择是“按属性划分”和“单节点”，它们将对数据进行排队，直到单个节点或分区节点返回为止。但为了便于移植，无法选择集群中的哪个节点执行此处理。
因为需要动态性和弹性，所以它只需要是一个节点。允许将“相似数据”发送到集群中的同一个节点，这对于某些用例可能是必要的。
对于表加载用例中的合并，使用自定义属性名称路由很奏效。还可以选择根本不进行负载均衡。
图源：Unsplash
NiFi新增了一个重要的新特性，允许节点停用并断开与集群的连接，并卸载所有数据。这对于Kubernetes和弹性的动态缩放很重要。
对于一天或一年里不同的工作负载，比如每小时一次的负载或每周的工作，弹性扩展非常重要——扩展以满足SLA和最后期限，但是尽可能缩小规模以节省云支出！现在，NiFi不仅解决了数据问题，还节省了资金。
RemoteProcess Groups不支持节点关联。节点关联受按属性划分策略支持，并且有许多用途。
使用RemoteProcess Groups替换以前的大用例。针对第一个连接，有更好的解决方案，比如在一个节点上运行的ListSFTP，然后连接就可以是“Round Robin”。
图源：Unsplash
Apache NiFi的这个负载平衡特性展示了在边缘，或其他数据中心分布大型数据集，或非结构化数据捕获、拆分和传输的能力，然后使用节点的属性关联性按照特定的顺序重组数据。
因此，有时候会从一个系统导出大量的大容量数据，比如在一个大TB的文件中导出一个关系数据库转储。这需要一个NiFi节点来加载这个文件，然后将其拆分为块，进行传输，并将其发送给节点进行处理。有时，排序记录将要求使用一个属性将一个节点上的相关块(比如说同一个表)保持在一起。
它还应用于包含许多类型的文件的zip文件中。通常，会有数百个具有多种类型的文件，需要根据文件名根（root）路由到同一个节点。这样，一个NiFi节点将处理所有相同的文件类型或表。
这就是为什么任何NiFi用户，都可以轻松地实现和检查ETL过程中发生了什么
