基于Flink+State开发的实时订单

实时订单开发，说实话，最近开发，掉了一半的头发，复杂度，我就点到为止，还是希望大家多看看flink，这个可是开发利器。写这篇文章的目的，就是给大家分享一下实时订单的开发思路和遇到问题如何去解决。我就写的比较简单点，很多花里胡哨的业务逻辑我就隐藏了，以及给下游提供数据，给策略提供数据这些我就不追溯了。

难点

•订单日志信息单一，结构固定，且几年不会变动，如果想要olap分析，需要给订单日志扩容纬度，这就需要实时关联纬度数据。•纬度数据一般都是k-v，接口，kafka，需要开发人员具备一定的工程能力•如何优雅的解决时间问题，如果订单流来了，纬度数据还没有更新怎么办•如何解决任务异常挂掉，数据不丢失问题。•如何解决脏数据问题，异常监控问题等等•计算逻辑复杂，业务逻辑复杂

问题分析

问题1. 如何优雅的解决时间问题，如果订单流来了，纬度数据还没有更新怎么办？

解决方案：一般实时流关联纬度数据，会天然存在长延迟问题，和传统的曝光关联点击，点击关联唤起不同，用户订单去关联广告点击会出现长时间的上报延迟，针对这个问题最好的办法就是通过flink的state去对齐数据，数据对齐再输出结果，你也可以通过hbase对齐再输出也可以。为啥用union，原因就是你通过state做join，避免时间窗口做join，因为用户凌晨唤起，有可能晚上23点才下单，跨度时间长，跟（曝光，点击关联）（点击，唤起关联）这种跨度时间短的场景不同。

override def open(parameters: Configuration): Unit ={}
在open函数中，初始化你们的接口查询客户端，mysql的l链接客户端

坑点！:

坑1，flink在open函数中创建mysql的客户端，会出现序列化问题，大家一定要记得加一个 @transient，不然你的程序会报错。

 @transient private var conn: Connection = _
 告诉flink，这个不需要序列化了

坑2，由于整个程序需要设计到很多关联纬度的接口（thrift分布式的服务，需要又代理ip），es，kafka，又要关联mysql，整合起来会出现jar冲突问题，httpclient的版本不一致，所以这块对工程能力要求比较强，如果是遇到jar包冲突，大家不要放弃，调整一下mvn的pom顺序，mvn会优先使用第一个pom的包，这样可以避免版本不一致带来的问题。

问题2. 如何解决任务异常挂掉，数据不丢失问题？

解决方案：可以使用增量checkpoint，切接不要checkpoint大的数据，避免造成checkpoint超时，同时不要把checkpoint的时间设置的太小，你也可以通过redis记录state，kafka维护自己的offset。我目前建议使用flink的state，因为一套技术站好维护，不会出现网络请求延迟问题，看你们领导让你们用啥吧，我是喜欢尝试新鲜的。

坑点！:

代码异常，会造成checkpoint时报，大家记得做好try catch，checkpoint不要设置间隔太短，容易背压。

问题3. 如何解决脏数据问题，异常监控问题等等？

解决方案：实时数据难点的就是你需要实时的去发现数据是否异常，这个就需要你去设计一下指标的监控，userid空的比较多的时候，记得报警，然后去快速排查问题。

问题4. 计算逻辑复杂，业务逻辑复杂，如何去轻松cover住？

解决方案：好好的去学习flink的state这个可是利器，不仅在实时去重复，窗口去重复，窗口排序，宽表实现上都是利器，同时还有ttl功能，这个非常好用，咱们常见的业务口径无非就是：

1. 当日下单（用户当日首次唤起，当天所有session带来的订单都要计算）

2. 立即下单（用户当日首次唤起，第一个session内的订单才算）

这些订单又会在营销中产生一些营销价值，稍微举几个例子

1. 比如业务线新客，业务线老客（bu下面会又各自的业务线）

2. bu新客，bu老客（存bu）

3. 安装未激活（用户安装了，没有激活，设备力度）

4. 纯新（用户激活了，没有下过单，user粒度）

5. 转新（用户在其他bu下过单，没有在这个bu下过单）

6. 流失（用户历史下过单，最近一段时间没有下单）

不同的营销价值，就意味着你的计算逻辑不同，所以这个计算逻辑非常绕，并且难度系数比较高，排查问题难度高，敏感数据比较多推动起来耗时，容易掉头发。

扫码关注我们

我知道你“在看”哟～