关于java:入门Flink很简单

我是 3y，一年 CRUD 教训用十年的 markdown 程序员👨🏻‍💻长年被誉为职业八股文选手

最近如果拉过 austin 我的项目代码的同学，可能就会发现多了一个 austin-stream 模块。其实并不会意外，因为这一切都在打算当中进行。

这个模块次要是接入 流式解决平台（flink），用于实时计算荡涤数据给到业务以及零碎维护者更不便去应用音讯推送平台austin。

这篇文章次要来聊聊接入的背景以及我肤浅的教训吧

我在老东家有过解决数据相干的教训，也看到过站内广告「成果数据」的倒退历程。

所谓成果数据，说白了则是商家在平台上投放了广告，咱们须要给商家看到广告带来的成果，最外围的是「曝光」「点击」「订单」，基于这几项数据再聚合些类 roi 的指标。

上面来聊聊这个「倒退历程」，看完这个过程或者能够更好地理解 为什么 须要流式解决平台

1、PHP 阶段：在最后时业务以及系统结构都比较简单，把「点击」和「订单」都存入数据库表，一把梭通过定时工作全量聚合，失去最终的成果数据，而「曝光」数据则是次日再写入成果数据表中。

在这个阶段里，因为数据量不大，通过定时工作全量来聚合数据也不是不能够，那时候商家都能承受该业务的提早性

2、Java 阶段：随着业务的倒退，逐步摒弃 PHP 化并且广告三层构造成型、数据量日益晋升、站内中间件服务平台也倒退起来。通过中间件团队提供的生产 binlog 框架，从架构上扭转聚合模式，并这个阶段能够更快地给商家展现成果数据，大略 1min 出成果数据

3、流式解决平台阶段：流式解决平台是对「计算」或者说解决数据时的形象，在这形象根底上它更能充分利用零碎的资源（一个大的工作被拆分多个小工作，而后散发到不同的机器上执行）

4、广告成果数据是先用的 Storm 作为流式解决平台，数据跑了几年都挺稳固的，性能吞吐量上也是满足业务应用的。起初 Flink 衰亡，反对 SQL、Exactly-Once、流批一体化 等，随着公司内推广，我将广告成果数据从 Strom 改至 Flink 体系上，大略秒级出成果数据。（其实还能够压缩，但须要兼顾 DB 的性能老本，只有业务上能承受即可。Traff-off！）

在第三点我提出了「数据处理时的形象」，我是这样了解的。在 Storm 里，定义 spout 为输出，bolt为两头解决或输入，而两头的数据流转为 tuple，用shuffle 机制来控制数据的流向

在 Flink 里，就有更加明确的语义来阐明输出和输入了（程序的 API 也更有语义性）

这些流解决平台都会数据处理进行了形象，让咱们更加不便且高效去解决数据，比方个别会以下的性能：

在后面 austin 零碎曾经设计了一部分的埋点信息了，在日志上都曾经打印了下来。

但针对这一部分数据，迟迟没有做解决（不过之前有一起跟着学 austin 的小伙伴给我截了日志，我一眼就晓得是哪里出了问题）

而接入流式解决平台就能对这一部分数据进行荡涤（依据下发者维度、依据模板音讯维度等等），失去荡涤后的数据再给到接口去展现或者排查问题应用，能大大提高排查或者业务方的应用效率

Flink从 2018 年开始风行，当初曾经有很多的公司都在用 Flink 作为实时大数据处理的流式平台。至于我为什么会抉择 Flink 的话，起因有以下：

1、我懂点儿 Flink（次要是懒得学其余的了，目前还够用）

2、Flink 倒退了几年，成熟且被很多大公司用，社区沉闷

3、Flink 的官网文档挺不错的，适宜学习和排查问题

首先咱们装置下 Flink，docker-compose.yml 文件内容：

version: "2.2"
services:
  jobmanager:
    image: flink:latest
    ports:
      - "8081:8081"
    command: jobmanager
    environment:
      - |
        FLINK_PROPERTIES=
        jobmanager.rpc.address: jobmanager
      - SET_CONTAINER_TIMEZONE=true
      - CONTAINER_TIMEZONE=Asia/Shanghai
      - TZ=Asia/Shanghai
  taskmanager:
    image: flink:latest
    depends_on:
      - jobmanager
    command: taskmanager
    scale: 1
    environment:
      - |
        FLINK_PROPERTIES=
        jobmanager.rpc.address: jobmanager
        taskmanager.numberOfTaskSlots: 2
      - SET_CONTAINER_TIMEZONE=true
      - CONTAINER_TIMEZONE=Asia/Shanghai
      - TZ=Asia/Shanghai

完了之后间接 docker-compose up -d 就能够启动 flink 了，咱们拜访在浏览器输出 ip:8081 端口就能看到 flink 的后盾了

简略看了下后盾，就能晓得咱们在本地开发完打包成 jar 就能够在 Submit New Job 提交 jar 包给 Flink 去跑了

而在写代码的时候，能够参考官网文档给出的 mvn 命令去构建 Flink 的根底环境

当然啦，当初我曾经搭好了，你们能够间接拉代码下来看 austin-stream 模块就完事了。如果你们是本人 从零搭 的话可能还要留神的是，pom里的 plugin 须要改变（不然打包会失败的），可参考我的 pom 文件

从目前的代码构造和逻辑上看，还是非常简单的，没有学过 Flink 的同学应该都能看懂：

目前次要实现了将 数据实时聚合 到 Redis，分了两个维度：用户和音讯模板（对应的 Redis 构造都曾经写在了代码的正文上了）

跟着做 austin 我的项目的小伙伴，只有在 kafka 创立对应的 topic(我这里定义的 topicName 是austinLog)，并且在AustinFlinkConstant 中填写 Kafka 的 Broker 信息以及 Redis 信息后，编译打包就完了。

提交到 Flink 平台之后就能够跑了：

通过 Flink 的解决曾经把数据写入到 Redis 里边了，最近我曾经在写 Controller 层开发接口在页面上将荡涤后的数据在页面上做展现了。

从后面的页面实现上如果有理解过的同学可能就晓得我用的是 低代码 平台 amis，而amis 我看了下图表的文档用的是 echarts 进行渲染的。

应该问题不大，过两天预计就开发完了，次要就是适配参数的问题了，到时候看起来应该就算比拟残缺了。

最近曾经有小伙伴提了 pull request 写了微信服务号的接入了，我曾经 merge 了代码，但还没调试。次要比拟麻烦的是，我没有营业执照，就不好开服务号进行调试，我前面再想想方法。

明天就聊到这吧，对 Flink 感兴趣的同学能够看看我以往的几篇文章和官网入门下，我倡议先能够把 austin 的代码先拉下来，部署一把本人体验体验，而后再看实践的常识。

1、Flink 入门

2、Flink 背压机制

3、Flink CheckPoint 机制

都看到这里了，点个赞一点都不过分吧？我是 3y，下期见。

关注我的微信公众号【Java3y】除了技术我还会聊点日常，有些话只能轻轻说~ 【对线面试官 + 从零编写 Java 我的项目】继续高强度更新中！求 star！！原创不易！！求三连！！

austin 我的项目源码 Gitee 链接：gitee.com/austin

austin 我的项目源码 GitHub 链接：github.com/austin

关于java:入门Flink很简单

01、为什么流式解决平台

02、austin 哪里用到了流式解决平台

03、Flink 入门

04、austin 代码

05、后续