26、Flink实战：Flink中的时间语议

2017-11-02 18:37:15.624 INFO Fail over to rm2

val env = StreamExecutionEnvironment.getExecutionEnvironment
// 从调用时刻开始给env创建的每一个stream追加时间特征
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)

假设，你正在去往地下停车场的路上，并且打算用手机点一份外卖。
选好了外卖后，你就用在线支付功能付款了，这个时候是11点59分。
恰好这时，你走进了地下停车库，而这里并没有手机信号。
因此外卖的在线支付并没有立刻成功，而支付系统一直在Retry重试“支付”这个操作。
当你找到自己的车并且开出地下停车场的时候，已经是12点01分了。
这个时候手机重新有了信号，手机上的支付数据成功发到了外卖在线支付系统，支付完成。

在上面这个场景中你可以看到，
支付数据的事件时间是11点59分，而支付数据的处理时间是12点01分

-------------------------------------------------------------------

问题:
    如果要统计12之前的订单金额,那么这笔交易是否应被统计?
答案:
    应该被统计,因为该数据的真真正正的产生时间为11点59分,即该数据的事件时间为11点59分,
    事件时间能够真正反映/代表事件的本质! 所以一般在实际开发中会以事件时间作为计算标准

一条错误日志的内容为：    
    2020-11:11 22:59:00 error NullPointExcep     --事件时间
    进入Flink的时间为2020-11:11 23:00:00          --摄入时间
    到达Window的时间为2020-11:11 23:00:10         --处理时间

-------------------------------------------------------------------

问题:
    对于业务来说，要统计1h内的故障日志个数，哪个时间是最有意义的？
答案:
    EventTime事件时间，因为bug真真正正产生的时间就是事件时间,只有事件时间才能真正反映/代表事件的本质! 

某 App 会记录用户的所有点击行为，并回传日志（在网络不好的情况下，先保存在本地，延后回传）。
A用户在 11:01:00 对 App 进行操作，B用户在 11:02:00 操作了 App。
但是A用户的网络不太稳定，回传日志延迟了，导致我们在服务端先接受到B用户的消息，然后再接受到A用户的消息，消息乱序了。

-------------------------------------------------------------------

问题:
    如果这个是一个根据用户操作先后顺序,进行抢购的业务,那么是A用户成功还是B用户成功?
答案:
    应该算A成功,因为A确实比B操作的早,但是实际中考虑到实现难度,可能直接按B成功算；
    也就是说，实际开发中希望基于事件时间来处理数据，但因为数据可能因为网络延迟等原因，出现了乱序；
    按照事件时间处理起来有难度！