回本部半天。
跟著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上面一直卡住，今天草草瀏覽了一下百度，還沒解決。
