【20170108&9】

回本部半天。

跟着storm官方文档看storm的内容，了解了Scheduler、Configuration、Guaranteeing message processing三个部分。

Scheduler类似于要做的资源管理器，是storm自带的。主要有四种调度器DefaultScheduler,IsolationScheduler,MultitenantScheduler,ResourceAwareScheduler.负责为不同的任务分配资源。

Configuration是用来配置storm，配置文件可以覆盖，其优先级：defaults.yaml < storm.yaml < topology specific configuration < internal component specific configuration < external component specific configuration（越全局的配置文件优先级越低）

Guaranteeing Message Processing，信息处理保障机制，似乎是storm可靠性和容错性的主要依据。这篇博客讲解细致。storm spout下面的多级tuple主要通过ack和fail通信，如果次级的tuple完成了，则调用上一级tuple的ack，上一级的tuple的子tuple全都返回ack，则该tuple完成（占用的内存也清零）；如果出错了，则调用上一级的fail，重新为该tuple分配资源重新计算，这样保证了所有的tuple被完全正确的执行。这种上下级tuple间的联系是通过传递id实现的。tuple产生一个子tuple叫做anchoring。另外也可以为了提高计算效率牺牲可靠性，只需要配置时让每个topology的acker为零即可，就不会有ack返回，同时也失去了前后级tuple的联系，前级tuple 不管后级的是否出错。

Daemon Fault Tolerance ，守护线程容错机制，分别介绍了当worker出错、Nimbus出错、supervisor Daemon出错、以及node出错的时候如何处理。其中node出错的机制（似乎）与前面信息处理保障机制acker数量为0的时候一致，也就是等到timeout之后重新执行；worker出错supervisor会重新启动它，如果总是失败不能给Nimbus发送心跳，则Nimbus会重新启动worker；Nimbus和supervisor Daemon出错，不会有进程被打断，Nimbus和SD就会重启；如果只有Nimbus出错，则worker不会被打断，SD也正常运行，但是worker不会被重分配。

三叶草的项目，今天写了一个初步的简陋的界面，只有一个开始键和输入用户姓名密码的文本框。

之前debug的时候的闪退的问题，在一个FreshMessage的里面有一个nullPointerException的error，加了一个try-cache之后问题居然就没出现了。。。据szx大神说是从服务器拿新的单词包的时候网速跟不上导致后面执行的时候还没有，是线程冲突问题，之后没再管，后面可以试试加个延时啥的。

另外主界面的设计有待解决。。。

后面打算先看看opengl的基础知识，再熟悉一下这部分的原有代码，逐渐改起来。先解决单词长度有限的问题。

goodnight~

忘记还有Eclispe加载Maven项目的时候还是在update上面一直卡住，今天草草浏览了一下百度，还没解决。