Blink是一个非常优秀的流处理任务开发框架，相对于之前的jstorm开发框架，它最显著的特点是具备非常完备的状态管理体系，解决了流处理任务中让人非常头疼的“保证EXACTLY ONCE的错误断点恢复”问题。下面着重梳理下blink是如何进行状态管理的。
在处理数据流时，定期插入checkpoint barrier，当一个计算节点收到checkpoint barrier时，就会将储存当时所有的运行状态。假设系统在处理barrier n和barrier n+1中间的某一条消息时发生了问题，blink就会将所有节点恢复至barrier n时的状态，并且将消息回调至barrier n重新计算。blink记录系统状态有两种方式：当需要维护的状态量较小时，每个节点自行存储自身的状态即可；当需要维护的状态量较大时，需要一个具备分布式一致性的存储来实现状态的储存。blink原生支持的数据库是RocksDB。
Event Time指的是事件发生时刻，与之对应的是Processing Time（系统处理事件的时刻）。下面介绍下Event Time的重要性。
在批处理任务时，假设我们希望对时间区间[a,b]内的数据进行聚合计算。由于从事件发生到系统接收到时间的过程中有很多不确定因素，若使用Processing Time，我们将无法精确的定义我们的计算，只能使用Event Time当系统发生错误导致状态回滚后，同一个事件将会多次进入到系统中，此时若使用Processing Time，将导致系统无法判定当前处理的事件是“回滚事件”还是“新事件”在批处理任务中，系统需要明确的知道是否已经接收到一个批次中的所有事件。blink使用watermarks来标示这一状态。一个带有时间戳t的watermarks会让计算节点判定不会再收到任何时间戳小于t的事件，若此时t已经满足批处理开始条件，则计算节点会开始运算批运算。在实践中，一般延迟一定时间发送带有时间戳t的watermarks，以此来尽可能保证计算节点开始进行批运算时所有事件都已被接收。
Savepoint可以理解为人为插入的checkpoint，会触发blink进行状态储存，开发人员可以指定恢复到某一个Savepoint来调试系统。
如果感兴趣，欢迎关注微信技术公众号
