Blink 有何特别之处？菜鸟供应链场景最佳实践(4)

下面是相关参数，用户可以直接在 Blink 的作业参数中进行配置。

[转载出处：www.11jj.com]

上架是仓储业务的重要组成部分。上架，顾名思义，就是要把到仓的货品，上到仓库的存储货架上。上架一般分为采购上架、销退上架、调拨上架等。及时上架是对仓库的重要考核项之一，无论哪一种类型的上架，我们经常需要针对到货后超过 x 小时未上架的订单进行预警。

但是，Blink 的计算是消息机制，需要上游发送消息才能触发下游计算，而上述的场景中，未上架就说明不会有上架的消息流入 Blink，进而无法完成下游的计算。

对于这种实时超时统计的问题，应该如何来解呢？我们尝试了几种方案，供参考：

方案1：针对部分 Source Connector，Blink 提供了"延时下发"的功能，用户可以通过指定 DataDeliveryDelayMs 参数，实现消息延迟下发。正常的消息正常流入，正常消息也可以通过配置该参数，使其按照自己的需求延时流入。这样，通过正常流入的消息关联延时流入的消息，可以触发 Blink 在消息正常流入时计算一次，在延时消息流入时再触发计算一次。这种方案，可以实现我们的业务需求，但是这种方案会把所有消息重新发送一遍，而不仅仅是到货后超过x小时未上架的消息，这样会造成计算资源的浪费，我们不建议在数据量很大的场景下使用该方案。

方案2：如果有第三方的消息中间件，而这个消息中间件又能支持配置超时下发的规则，这将是一个比较好的方案。据了解，Kafka 的最新版本已经能够根据业务需求，配置消息超时下发的规则。我们只需要在 Blink 中，通过正常流入的消息流关联关键Kafka 超时下发的消息流，就可以触发 Blink 进行超时消息的统计。这样，除了Blink，我们需要同时保障 Kafka 的稳定性。Kafka的超时消息订阅，可以参见：[1]。

方案3：我们能够很自然的想到 CEP，而 Blink 也已经提供了 CEP 的功能，且已经SQL化。用户可以通过 Blink CEP 完成上述业务需求的统计。在实操过程中，我们发现，通过 Blink CEP 统计的结果，往往与真实结果(明细汇总统计)有一定的出入。什么原因呢？原来到货时间，被回传了多次，有可能开始回传的是9点，但是后面发现回传错了，改成了8点，而 CEP 的 Watermark 是全局地向前走的，对于这种场景，无法很好的适配。