1、背景
流计算希望达到的目标：
实时性、扩展性
批处理较简单：固定数据规模、对处理时间的容忍度较高
流计算难度较大：数据到达的速率不一样（扩展性）
容错
可以通过清洗先处理一遍（离线的方式）
批处理系统里用的都是重新计算的方法、checkpoint保存当前状态
难点：还希望满足系统实时性、扩展性的要求
编程
希望可以自动处理容错和负载平衡的问题
2、做一个流计算系统
2.1、基础组建：worker（处理）、queue（缓冲和路由）
queue的好处：很多数据源，（软件接口中非常经典的问题）将不同的数据源匹配到数据处理模块上，接口数就变成了mn。分层，变成m+n个接口。
用queue收集数据，所有的数据处理单元都从queue读数据。
queue可以实现一个模型publish-subscribe model，在语义方便加了个中间层。
persistency，数据从传感器收集来之后，会在queue上暂存。
性能优化，聚合数据之后发送
2.2、做一个简单的流计算系统：统计推文里边url出现的次数
后边的queue只对应一个worker，减少写数据的时候的并发问题。（twitter早期的流处理架构）
怎么做url对queue的映射：哈希，根据url的值来决定发给谁。
数据量很大，worker要增加，则需要改映射的函数。
worker的机器坏掉了，要找到另一台机器，修改函数……很复杂。
用worker和queue做一个流计算系统是可做的，但是会很复杂，很困难。
2.3、现有的流计算系统：雅虎 simple …
用了一个模型：actor model，可以创建新的actor，也可以向别人发送消息。
actor类似object，通过发消息来做事情，但是内部过程外边看不到。
PE，新的key会产生一个新的PE。
storm的概念
stream，支持的数据类型，原始的数据类型
spout
bolt，支持filters
topology（程序）
系统的扩展性，一个bolt可以对应于中间一层的worker。
shuffele …，随机的；
……，根据计算值对应发给哪一个。
哈希表是存wordcount的最合适的方式
storm里对容错的支持
at most once，能做就做，不能做就扔掉了。
at least once，怎么知道给定一个消息是否在系统里处理完了？
跟踪机制，给每一个消息一个ID
第一种方式，做一个表，如下：
B1 B2 B3 B4
SID
第二种方式，把SID记录，处理完也记录一次ID。系统里有一个表象，持续记录消息处理及生成的过程。通过亦或的算法，如果结果为0，就代表消息处理完了。
emit一个新的消息，呆了tuple这一项，能找到原始的表，ack告诉我输入的消息已经处理完了，可以去亦或一下进来的消息。ack可以跟踪消息处理的程度。
exactly once，实现非常困难，改掉的状态再改回去非常困难。
支持exactly once的思路和spark的思路是一样的，定义为不可改的。计算是deterministic, stateless tasks。
batch size取得大，对系统的吞吐率是有好处的；但是延迟（有延迟的要求）就完成不了了。
batch太小吞吐率可能上不去。
batch可以达到一个秒级的水平。
比较S4, storm , sparkstream
storm自己去维护结构
sparkstream，已经集成在一起了，没有安装部署的开销
queue有一个很重要的作用是缓冲，数据到达的速率是变化的，但是能力是固定的。
buffer到底放在那里，在哪里做溢出管理。