共计 1180 个字符，预计需要花费 3 分钟才能阅读完成。
流式计算的世界观：工夫不停万物不停
- 在批量的时代，咱们只记录要害的信息，只在乎以后，不在乎状态是如何一步步变动至当状态的，所以说批时代咱们计算所面向的数据是动态的。在分布式环境中批量计算是将计算挪动到相应的数据上进行运行。
- 在流世界里，咱们在乎的是变动，咱们计算所面临的将是时时刻刻更新流动的数据。流式计算是将定义好的计算部署到分布式节点上，让数据在下面流动。
不再把数据定性为“解决某天的数据，解决某个季度的数据”，而是随着工夫的推移，零碎要捕捉到用户每分每秒产生的数据，进行计算解决后让业务报告保障最新。
流式解决中的工夫
- 事件工夫（Eventtime）：事件实在产生的工夫，因为 … 起因，事件产生的工夫和达到服务端的工夫可能是相差极大的
- 达到工夫：服务端接管到事件的工夫
- 解决工夫：零碎开始前途达到事件的工夫
// 创立环境上下文
val env = StreamExecutionEnvironment.getExecutionEnvironment
// 设置在以后程序中应用 ProcessingTime
env.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime);窗口
- 滚动窗口：依照固定的工夫片断划分数据流，将数据流宰割成固定大小的片段。
- 滑动窗口：由固定窗口长度 windows-size= 1 和窗口滑动步长 windows-slide=0.5，示意窗口长度为 1，每 0.5 个单位就向前滑动一个新窗口。滑动窗口常常被用来统计诸如“每 5 分钟统计过来 10 分钟的访问量”，windows-size=10 和 windows-slide=5
- 会话窗口：会话的窗口的大小由用户流动的事件频率决定，没有固定的窗口大小。
流式解决的设计模式
流和表的连贯 : 有时候，咱们须要在内部数据中保留一些规定后，须要时将信息完完整整的拉进流中。然而，流式解决零碎每秒能够解决 10-50W 个事件，而数据库每秒的只能解决 1W 个事件。所以，内部查找不仅会带来重大的提早性，如果数据刷新的太频繁会对数据库造成很大的压力，如果刷新不及时，那么流式解决中所用的数据就会过期。所以，咱们采纳通过 Canal 来捕捉 Mysql 数据库的变动，造成事件流，Flink 就能够监听事件流，并及时更新。
State
在 Flink 中，状态用于缓存用户数据，窗口数据，程序运行状态，数据源偏移量
Checkpoint
定期对 State 中的数据进行备份并复原的机制，正是有了 State 和 Checkpoint，Flink 能力做到：
- 备份与复原，7*24 的运行是容错
- 数据不失落不反复，Exactly one
- 低提早
- 数据间有关联，通过状态满足业务逻辑
Watermark 和 Trigger
Flink 中放弃正确性的工具是 State 和 Checkpoint，提供工夫推理能力的是 Watermark 和 Trigger。
正文完
