Storm可靠性的设计与它的Acker有很大关系,先让我用比较拙劣的语句简单描述下。
Storm的tuple,被OutputCollector emit的时候——这个称为archoring(生成新的tuples),需要指定和它相关的之前的tuple,并且要指定executor完之后ack之类的api,这样就能建立一颗可追踪的tuple树。如:
- public class SplitSentence extends BaseRichBolt {
- OutputCollector _collector;
- public void prepare(Map conf, TopologyContext context, OutputCollector collector) {
- _collector = collector;
- }
- public void execute(Tuple tuple) {
- String sentence = tuple.getString(0);
- for(String word: sentence.split(" ")) {
- _collector.emit(tuple, new Values(word));
- }
- _collector.ack(tuple);
- }
- public void declareOutputFields(OutputFieldsDeclarer declarer) {
- declarer.declare(new Fields("word"));
- }
- }
一个topology里面的acker数量是可以设置的,然后tuple比较多的话可以多设置几个acker,提高效率。每个tuple有一个64位的id,acker利用这个id来追踪tuple,且会知道这个tuple他的祖宗们,也就是只要继续跟踪新的tuple就可以了,因为祖宗的id会被传递下去。
storm用一致性哈希来把spout-tuple-id对应给acker,因为tuple知道自己的祖宗,所以他可以算出通知哪个acker来ack(所有的根tuple是知道的,hash好了之后,以后的子tuple去对应的地方ack)。acker会维护tuple树上的各个tuple,当他知道这个树完成处理了,就会通知某个对应的task。
acker task不显示跟踪整个tuple树,不然会占据很多内存,acker使用一个恒定的20 bytes来针对每个spout tuple。一个acker存一个spout-tuple-id的时候,存两个值:一个是task id,用于关联task;第二个是 ack val,一个64位的数。ack val是整个树状态的一个表示,把所有的tuple id异或起来,当ack val=0,就知道整棵tuple树成功完成了,否则失败,然后就可以通知task了。
在以上的可靠性之下,如果:
- task fail了,tuple没有被ack。超时机制保证这个tuple以后再被重新处理
- Acker挂 。这个acker跟踪的tuple都超时,都会重新处理
- Spout挂了。消息源重新发送消息。
以上内容可以具体参考wiki:Guaranteeing-message-processing
Acker更多设计可以参考: twitter-storm-code-analysis-acker-merchanism
Storm事务性相关
State in Trident
Trident在读写有状态的数据源方面是有着一流的抽象封装的。状态即可以保留在topology的内部,比如说内存和HDFS,也可以放到外部存储当中,比如说Memcached或者Cassandra。这些都是使用同一套Trident API。
Trident以一种容错的方式来管理状态以至于当你在更新状态的时候你不需要去考虑错误以及重试的情况。这种保证每个消息被处理有且只有一次的原理会让你更放心的使用Trident的topology。
在进行状态更新时,会有不同的容错级别。在外面一起来讨论这点之前,让我们先通过一个例子来说明一下如果想要坐到有且只有一次处理的必要的技巧。假定你在做一个关于某stream的计数聚合器,你想要把运行中的计数存放到一个数据库中。如果你在数据库中存了一个值表示这个计数,每次你处理一个tuple之后,就将数据库存储的计数加一。
当错误发生,truple会被重播。这就带来了一个问题:当状态更新的时候,你完全不知道你是不是在之前已经成功处理过这个tuple。也许你之前从来没处理过这个tuple,这样的话你就应该把count加一。另外一种可能就是你之前是成功处理过这个tuple的,但是这个在其他的步骤处理这个tuple的时候失败了,在这种情况下,我们就不应该将count加一。再或者,你接受到过这个tuple,但是上次处理这个tuple的时候在更新数据库的时候失败了,这种情况你就应该去更新数据库。
如果只是简单的存计数到数据库的话,你是完全不知道这个tuple之前是否已经被处理过了的。所以你需要更多的信息来做正确的决定。Trident提供了下面的语义来实现有且只有一次被处理的目标。
- Tuples 是被分成小的集合被批量处理的 (see the tutorial)
- 每一批tuples被给定一个唯一ID作为事务ID (txid). 当这一批tuple被重播时, txid不变.
- 批与批之间的状态更新时严格顺序的。比如说第三批tuple的状态的更新必须要等到第二批tuple的状态更新成功之后才可以进行.
Transactional spouts
- 有着同样txid的batch一定是一样的。当重播一个txid对应的batch时,一定会重播和之前对应txid的batch中同样的tuples。
- 各个batch之间是没有交集的。每个tuple只能属于一个batch
- 每一个tuple都属于一个batch,无一例外
你也许会问:为什么我们不总是使用transactional spout?这很容易理解。一个原因是并不是所有的地方都需要容错的。举例来说,TransactionalTridentKafkaSpout 工作的方式是给定一个txid的batch所包含的一个属于一个topic的来自于所有Kafka partition的tuple序列。一旦这个batch被发出,在任何时候如果这个batch被重新发出时,它必须包含原来所有的tuple以满足 transactional spout的语义。现在我们假定一个batch被TransactionalTridentKafkaSpout所发出,这个batch没有被成功处理,并且同时kafka的一个节点也down掉了。你就无法像之前一样重播一个完全一样的batch(因为kakfa的节点down掉,该topic的一部分partition可能会无法使用),整个处理会被中断。
这也就是"opaque transactional" spouts(不透明事务spout)存在的原因- 他们对于丢失源节点这种情况是容错的,仍然能够帮你达到有且只有一次处理的语义。后面会对这种spout有所介绍。
(当然,在Kafka开启replication功能时,transactional spout也是可以做到容错的)
在外面来讨论"opaque transactional" spout之前,我们先来看看你应该怎样设计一个State来实现transactional spout的有且只有一次执行的语义。这个State的类型是"transactional state" 并且它利用了任何一个txid总是对应同样的tuple序列这个语义。
假如说你有一个用来计算单词出现次数的topology,你想要将单词的出现次数以key/value对的形式存储到数据库中。key就是单词,value就是这个这个单词出现的次数。你已经看到只是存储一个数量是不足以知道你是否已经处理过一个batch的。你可以通过将value和txid一起存储到数据库中。这样的话,当更新这个count之前,你可以先去比较数据库中存储的txid和现在要存储的txid。如果一样,就跳过什么都不做,因为这个value之前已经被处理过了。如果不一样,就执行存储。这个逻辑可以工作的前提就是txid永不改变,并且Trident保证状态的更新是在batch之间严格顺序进行的。
考虑下面这个例子的运行逻辑, 假定你在处理一个txid为3的包含下面tuple的batch:
- ["man"]
- ["man"]
- ["dog"]
- man => [count=3, txid=1]
- dog => [count=4, txid=3]
- apple => [count=10, txid=2]
- man => [count=5, txid=3]
- dog => [count=4, txid=3]
- apple => [count=10, txid=2]
Opaque transactional spouts
- 每个tuple只在一个batch中被成功处理。然而,一个tuple在一个batch中被处理失败后,有可能会在另外的一个batch中被成功处理
- {
- value = 4,
- prevValue = 1,
- txid = 2
- }
- {
- value = 6,
- prevValue = 4,
- txid = 3
- }
- {
- value = 3,
- prevValue = 1,
- txid = 2
- }
Non-transactional spouts
Non-transactional spout(非事务spout)不确保每个batch中的tuple的规则。所以他可能是最多被处理一次的,如果tuple被处理失败就不重发的话。同时他也可能会是至少处理一次的,如果tuple在不同的batch中被多次成功处理的时候。无论怎样,这种spout是不可能实现有且只有一次被成功处理的语义的。Summary of spout and state types
State和Spout类型的选择其实是一种在容错性和存储消耗之间的权衡,你的应用的需要会决定那种组合更适合你。
State APIs
- TridentTopology topology = new TridentTopology();
- TridentState wordCounts =
- topology.newStream("spout1", spout)
- .each(new Fields("sentence"), new Split(), new Fields("word"))
- .groupBy(new Fields("word"))
- .persistentAggregate(MemcachedState.opaque(serverLocations), new Count(), new Fields("count"))
- .parallelismHint(6);
- public interface State {
- void beginCommit(Long txid); // can be null for things like partitionPersist occurring off a DRPC stream
- void commit(Long txid);
- }
- public class LocationDB implements State {
- public void beginCommit(Long txid) {
- }
- public void commit(Long txid) {
- }
- public void setLocation(long userId, String location) {
- // code to access database and set location
- }
- public String getLocation(long userId) {
- // code to get location from database
- }
- }
- public class LocationDBFactory implements StateFactory {
- public State makeState(Map conf, int partitionIndex, int numPartitions) {
- return new LocationDB();
- }
- }
- TridentTopology topology = new TridentTopology();
- TridentState locations = topology.newStaticState(new LocationDBFactory());
- topology.newStream("myspout", spout)
- .stateQuery(locations, new Fields("userid"), new QueryLocation(), new Fields("location"))
- public class QueryLocation extends BaseQueryFunction<LocationDB, String> {
- public List<String> batchRetrieve(LocationDB state, List<TridentTuple> inputs) {
- List<String> ret = new ArrayList();
- for(TridentTuple input: inputs) {
- ret.add(state.getLocation(input.getLong(0)));
- }
- return ret;
- }
- public void execute(TridentTuple tuple, String location, TridentCollector collector) {
- collector.emit(new Values(location));
- }
- }
你可以看到,这段代码并没有想Trident那样很好的利用batch的优势,而是为每个输入tuple去查询了一次LocationDB。所以一种更好的操作LocationDB方式应该是这样的:
- public class LocationDB implements State {
- public void beginCommit(Long txid) {
- }
- public void commit(Long txid) {
- }
- public void setLocationsBulk(List<Long> userIds, List<String> locations) {
- // set locations in bulk
- }
- public List<String> bulkGetLocations(List<Long> userIds) {
- // get locations in bulk
- }
- }
- public class QueryLocation extends BaseQueryFunction<LocationDB, String> {
- public List<String> batchRetrieve(LocationDB state, List<TridentTuple> inputs) {
- List<Long> userIds = new ArrayList<Long>();
- for(TridentTuple input: inputs) {
- userIds.add(input.getLong(0));
- }
- return state.bulkGetLocations(userIds);
- }
- public void execute(TridentTuple tuple, String location, TridentCollector collector) {
- collector.emit(new Values(location));
- }
- }
- public class LocationUpdater extends BaseStateUpdater<LocationDB> {
- public void updateState(LocationDB state, List<TridentTuple> tuples, TridentCollector collector) {
- List<Long> ids = new ArrayList<Long>();
- List<String> locations = new ArrayList<String>();
- for(TridentTuple t: tuples) {
- ids.add(t.getLong(0));
- locations.add(t.getString(1));
- }
- state.setLocationsBulk(ids, locations);
- }
- }
- TridentTopology topology = new TridentTopology();
- TridentState locations =
- topology.newStream("locations", locationsSpout)
- .partitionPersist(new LocationDBFactory(), new Fields("userid", "location"), new LocationUpdater())
persistentAggregate
- TridentTopology topology = new TridentTopology();
- TridentState wordCounts =
- topology.newStream("spout1", spout)
- .each(new Fields("sentence"), new Split(), new Fields("word"))
- .groupBy(new Fields("word"))
- .persistentAggregate(new MemoryMapState.Factory(), new Count(), new Fields("count"))
- public interface MapState<T> extends State {
- List<T> multiGet(List<List<Object>> keys);
- List<T> multiUpdate(List<List<Object>> keys, List<ValueUpdater> updaters);
- void multiPut(List<List<Object>> keys, List<T> vals);
- }
当你在一个未经过group的stream上面进行聚合的话,Trident会期待你的state实现Snapshottable接口:
- public interface Snapshottable<T> extends State {
- T get();
- T update(ValueUpdater updater);
- void set(T o);
- }
MemoryMapState 和 MemcachedState 都实现了上面的2个接口。
Implementing Map States
- public interface IBackingMap<T> {
- List<T> multiGet(List<List<Object>> keys);
- void multiPut(List<List<Object>> keys, List<T> vals);
- }
OpaqueMap's会用OpaqueValue的value来调用multiPut方法,TransactionalMap's会提供TransactionalValue中的value,而NonTransactionalMaps只是简单的把从Topology获取的object传递给multiPut。
Trident还提供了一种CachedMap类来进行自动的LRU cache。