nifi主节点切换导致任务堆积无法处理
nifi的分布式方案，实际只是多节点的同类Processor并行执行，分布式比较简陋
Processor可以是producder,可以是consumer,也可以同时有producder/consumer 两种身份
官方建议的根producder，最好只是由master执行，consumer则全node都可执行
如果指定只有master可以consumer的话，会有以下问题
通俗点说
指定某些工作只有master能做，A是当前master
给A安排了些工作，A在处理中
然后集群故障重新选举，B成了master，A不再是master
那因为没有master身份，不能执行之前当master时堆积的任务
这个问题不好解决，但可以结合监控及时发现并作处理
nifi的一致性保证，以类似预写日志机制（WAL）的方式实现，提前写入目标节点的本地存储
上流的所有flowfile，分布式环境会写入下流node的wal内
在以下条件下，导致会一个处理延迟的问题
-
1 分布式环境，分布式环境会选择出一个master执行
-
2 部分场景会设置processor只能在master节点执行
-
3 processor会消费上流flowfile
由于上游的flowfile是预写到处理节点的，如果processor只能在master上执行，则会将flowfile写入到master的file system。
正常情况没有问题，但是如果因为某些原因，如oom,网络问题导致，master(此节点为node1 )失联，重新选举，而新的master是另外一个node2
那么由于porcessor只能在master执行，则新的flowfile会写入node2并在node2上执行，但是，node1上虽然有待处理的flowfile，但是因为node1已经不是master
则processor不会处理WAL里的flowfile,直到node1重新又成为master
其实这类似分布式事务的一个问题点，使用etcd,zk的分布式事务方案，可以保证下一个leader一定会选择出来，但时间要素无法保证，当然，这个问题在通常的分布式环境不用考虑
这个问题暂时没有好办法，倒也不算nifi的bug，而是为了一致性保证而做的的权衡
避免的办法，是从业务角度，避免同时满足以上3个条件。或者业务层面添加报警机制，及时发现，支持处理