最近开始要做一些实时计算方面的东西，于是机缘巧合下接触到了腾讯内部的一些计算平台工具，以及flink的使用，因此最近也需要开始着手研究起flink这块的内容了。
什么是flink
flink是apache旗下的一款框架后分布式处理引擎，主要用于做有界和无界的计算功能。
可能看到这里，你还是有点懵逼，到底flink解决了什么问题？别急，下边让我们先做些简单的铺垫。
什么是离线计算
所谓的离线计算，可以理解为是一种对实时性要求不高的计算（可以延迟到几个小时甚至几个月后处理）。在这一方面，比较具有代表性的就是大数据中的MapReduce计算思路，通常会将一个巨大的任务拆解为多个子任务，然后发布到不同的机器上去运行，例如下图所示：
离线计算的好处在于，可以处理海量数据，通过引入机器可以增加并行计算度，采集的数据还可以进行多次修复迭代等处理。
说完了离线计算，我们再来看看实时计算。
什么是实时计算
其实实时计算，你可以理解为"延迟较低的离线计算"，一般不会说延迟太久，可能几分钟就能出来结果，而且计算出来的结果一般不会再有二次过滤处理类的操作。
比较经典的场景，我们在听qq音乐的时候，当你对某首歌点击了收藏，接下来这个动作会被上报到后台，然后进行实时计算，给你推荐更多类似的歌曲。
好了，现在你应该对离线计算和实时计算有了一定的了解了吧。而我们今天要讲的flink，其实就是一种主要用于做实时计算的流处理框架。
flink的应用场景
下边让我们来看个实战案例，你就会理解flink的具体应用了。以下是一个早期的ES同步数据方案，业务背景为：用户点击查看了某样商品之后，就需要发送一个上报请求，然后通过kafka-connector同步到es集群中。
整体的同步流程如下图所示。
但是这里会存在一个问题，就是当在线用户高达上百万乃至上千万的时候，这里的kafka消息发送量是非常庞大的，有时候一秒钟的请求量可以达到1w+，这样的大并发量很容易就将下游的es集群给写挂了。
为了解决这个业务难题，我们需要着手分析进行优化：
-
首先es集群的机器配置需要提升。例如从2core，2gb的4台机器提升至4core，8gb的机器8台机器。
-
需要解决掉kafka-connector直接对下游es集群的巨大写入压力，例如采用批量写入而非单条写入。
-
需要考虑即使es挂了，后续集群恢复后，可以继续从原先的消费位点继续写数据。
于是经过一番技术调研之后，我们决定引入flink进行同步，此时整体架构图变为如下图所示：
引入了flink之后，有个最明显的好处就是：我们的kafka消息会现在flink这部做缓冲，flink在本地可以先将这些数据给缓冲起来，然后批量地提交到es集群中。这里相当于从原先的每条数据来了都写es变成了批量写提交，从而大大降低了对于es集群的访问压力。
另外flink对于数据的一致性和数据恢复都有比较好的支持能力。
flink的内部组成
先来看看flink的内部组成图：
从图中我们大致可以看出，flink需要由客户端去提交任务，然后它会将这批任务分通过JobManager发到TaskManager上去执行。这里很好理解成的是，JobManager相当于是整个任务集群的监视器，主要用于监听各个TaskManager的节点状态。
这些所谓的TaskManager，你可以理解为类似于线程池中的Worker线程对象的作用，专门用于计算任务的。只不过在flink中，每个处理任务的TaskManager都是单独的Java进程。
flink的并行度如何计算
其实作为任务的执行角色，TaskManager内部也是有许多线程资源的，我们一个TaskManager的内部是可以有多个Task Slot组成的，这些Task Slot你可以理解为就是单独的Java线程，专门用于执行单个任务所使用的。
也就是说，假设我们的CPU核心数充足的情况下，整体的计算并行度应该是所有TaskManager的Task Slot个数之和。
每个 task slot 表示 TaskManager 资源的一个固定子集。例如，一个有三个 slots 的 TaskManager 会将其 1/3 的托管内存分配给每个插槽。对资源进行插槽管理意味着子任务不会与来自其他作业的子任务争夺托管内存，而是拥有一定数量的预留托管内存。注意，这里没有发生 CPU 隔离；当前插槽只分隔任务的托管内存。
通过调整任务槽的数量，用户可以定义子任务如何彼此隔离。每个 TaskManager 有一个插槽意味着每个任务组运行在单独的 JVM 中(例如，可以在单独的容器中启动 JVM)。拥有多个插槽意味着更多的子任务共享同一个 JVM。相同 JVM 中的任务共享 TCP 连接(通过多路复用) 和心跳消息。它们还可以共享数据集和数据结构，从而减少每个任务的开销。
小结
本文主要是简单地带大家了解下大数据中的计算任务的概念，以及flink的架构图，和其内部的运作流程和一些应用场景，在后续的文章中将会再去分析关于CheckPoint这块的原理。