流

某一个时间点开始，产生数据，并延伸到时间尽头，无法预测下一条数据何时到达。比如鼠标点击事件clickEvent(x，y，timestamp)，就是以时间戳为维度的一个流。理论上，流可以抽象世间万物。高等数学里的级数就是一条完美的流。

stream is everywhere

流包含以下特性

• 有序。银行帐户操作为例，先存钱再取钱才认为是合法操作。
• 不可变。当事件发生了就不可能被改变，一个订单取消了不等于订单完全消失了，而是添加一个取消事件到数据流上，记录对先前订单的取消操作。如果你熟悉数据库的binlog的话，你插入一条数据之后再删除它，在数据库里这条数据消失了，但是做主从备份或者数据回滚时，插入和删除操作都保留在log中。在这次一意义上，binlog其实就是一个数据流。
• 可重复播放（kafka支持）。支持重新处理一个很久以前（几个月或者几年）的流的能力，不管是出于纠错，还是应用新的数据分析方法，还是再次确认分析结果。

三种编程模式

流处理其实是编程模式的一种。

• 请求-响应模式。超低延迟，几毫秒，往往是阻塞的，发出请求并等待返回结果。
• 批处理模式。高延迟，高吞吐量。比如hadoop任务在某个时间点被调度，读入大量数据，处理后输出，最新输出都是在下次任务完成之后。
• 流处理。在前两种模式中取的这种方案。实际应用往往不需要在几毫秒之内返回结果，但也不能容忍隔天的结果反馈周期。

Kafka stream不需要back pressure

流的产生和消费往往是解耦合的（实现上都是异步线程），如果数据消费的速度小于产生的速度，消息在流缓冲区中累积，直到缓冲区溢出。为了解决这个问题就有了back pressure，目的是用来控制流的产生速度。由于Kafka生产者和消费者完全分离，并将消息持久化到磁盘中，相当于一个中间buffer（唯一上限是磁盘空间），当生产者产生消息超过消费者消费时，消息累积到partition末尾，消费者自己维护消费位置的offset，以追赶生产者，Kafka流处理不存在back pressure问题。

streaming

处理流里边的数据和处理其他数据是完全类似的，你首先读数据，然后处理（转换，整合，过滤等等），最后存储到某个地方。然而流处理有它独有的概念来抽象。

时间

比如我们想计算每5分钟的股票平均价格，但是消息的生产者因为网络故障停机了2个小时，当生产者再次重启时，过去两个小时的数据会推送到流中，然而我们的流处理程序已经跑完，结果已经发布。为了避免上述情况，我们应该单独维护流中每一个事件的发生时刻，让分析结果不依赖于流的处理时间，而是由事件产生的时间决定。

三种时间（依次递增）：

• 事件发生时间。最关键的时间，流处理逻辑依赖的时间。比如股票价格变动，发生的时间（时刻），又比如用户提交订单的时间。
• 存储时间。事件以消息的形式存储在持久化设备的时间。往往与流处理无关。
• 处理时间。消息被处理时的时间。