簡介
storm有4個排程器(defaultscheduler/isolationscheduler/multitenantscheduler/ras),jstorm只有乙個排程器，但是其擁有4種模式(defaultscheduler/isolationscheduler/user-defined scheduler/the last scheduler)，jstorm的排程模式需要在用configextension進行配置。
預設排程演算法(default scheduler algorithm)
jstorm的default scheduler不僅僅像storm那樣實現了隨機的資源分配，更考慮了穩定性，資源利用以及效能。
1.穩定性
均勻的將每個元件(spout/bolt)的執行緒(並行度)分配到集群中的各個節點。jstorm會盡可能的將同乙個元件的執行緒分配到不同的節點及worker上以減少同質競爭(同乙個元件執行緒做的是一樣的事情，比如可能都是cup密集型，那麼放到不同節點就能提供效率，更好的利用資源)。
舉個例子，乙個集群有三個節點，node-a有3個worker，node-b有2個worker，node-c有乙個worker。當使用者提交乙個topology(該topology需要4個worker，1個spout(x)，乙個bolt(y)，spout/bolt各佔2個程序)。初始時：在storm與jstorm是一樣的。
這時，如果node-c掛掉了，那麼node-c中的worker必須要重寫分配。如果是storm的預設分配記過如下：
如果是jstorm的預設排程來進行分配的化，結果如下:
顯然，jstorm的預設排程演算法比storm的更加優秀。
2.負載均衡
jstorm盡量保證每個worker所分得的執行緒數基本一致，並且worker在各個supervisors之間也盡量分配的均勻。例如，乙個集群有3個節點，node-a有3個worker，noder-b有3個woker，node-c與3個woker。使用者先提交了乙個需要2個woker的topology，然後，又提交了乙個需要4個worker的topology。
如果是storm的預設排程演算法來分配這兩個topology，結果如下：
顯然可以看出，這個分配是不均勻的。。而jstorm的預設分配就能得到乙個均勻的結果：
3.效能
jstorm會試圖將兩個需要通訊的執行緒盡量放在乙個worker中來減少網路的傳輸。例如：乙個集群中有2個節點，node-a有2個worker，node-b有2個worker。當使用者提交乙個topology(需要2個worker，1個spout(x)，2個bolt(y、z)，三個元件各乙個執行緒)。整個topology的資料流為x->y->z。如果storm的預設排程演算法來分配，可能的結果為：
顯然中間需要網路間傳輸，而jstorm的分配就能避免這個問題:
這裡y與z的通訊是程序間通訊。在程序間通訊，訊息不需要序列與反序列化。這樣會極大的提高效率。
想要(穩定性/效能/平衡)都同時滿足是很困難的。jstorm對於重要性排序是：穩定性負債均衡。
高階特性
jstorm具有一些高階特性，我們可以通過配置topology來使用這些功能。
1.isolationscheduler
與storm一樣，jstorm也有isolationscheduler。在storm中使用者可以配置nimbus來隔離特定的topology，決定分配多少機器給這些隔離的topology，配置項為nimbus上的storm.yaml檔案中的isolation.scheduler.machines。在隔離的topology分配好之後，那些沒有被隔離的就使用剩下的機器。由於jstorm將isolationscheduler整合進了defaultscheduler中，所以，在jstorm中，我們需要在topology中進行配置，而不是在storm.yaml中。
2.user-defined assignment scheduler
顧名思義，使用者通過這個可以自己定義分配方式。下面來看看一些需要自己定義分配方式的場景：
a.將spout與bolt放到乙個worker中來達到替代drpc的目的
spouta->bolt1->bolt2->resultbolt
我們可以把spouta與resultbolt放到乙個woker中，這樣resultbolt的結果就能直接返回給spouta。
b.將上下游的元件放在一起，避免網路傳輸。
c.強制將乙個元件執行分配到乙個特定的機器上。
例如，我們可以將乙個運算元據庫的元件強制分配到資料庫所在的機器上，或者，將需要讀kafka資料的元件放到kafka所在的機器上。
d.強制乙個元件的不同執行緒執行在不同的機器中。
當然，使用者也可以選擇只對部分worker與執行緒進行自定義分配，那麼其他還是使用預設的分配方式。
3.the last assignment scheduler
為什麼會有這麼個奇怪的分配方式呢，這個分配就是很簡單的，與上一次用一樣的分布方式。
假設，你上了乙個topology，然後，過了一段時間，你re-submit/restart這個topology，這時，如果與上次的分配方式不一樣，topology上一次執行在各個節點留下的資料就沒用了，而如果採用與上一次一樣的分配方式，那麼這些資料就能夠得到重用。
當然，如果出現乙個節點掛了，那麼這個節點的woker的重新分配就是預設的分配方式了。
JStorm集群的部署
jstorm是乙個類似hadoop mapreduce的系統，不同的是jstorm是一套基於流水線的訊息處理機制，是阿里基於storm優化的版本，和storm一樣是乙個分布式實時計算的系統，從開發角度來說，jstorm所有的概念和storm都相同，所有的程式設計 一行不用改也可以直接放到jstorm...
JStorm集群的部署
jstorm是乙個類似hadoop mapreduce的系統，不同的是jstorm是一套基於流水線的訊息處理機制，是阿里基於storm優化的版本，和storm一樣是乙個分布式實時計算的系統，從開發角度來說，jstorm所有的概念和storm都相同，所有的程式設計 一行不用改也可以直接放到jstorm...
Storm與Hadoop的比較
對於一堆時刻在增長的資料，如果要統計，可以採用什麼方法呢？1.等資料增長到一定程度的時候，跑乙個統計程式進行統計。適用於實時性要求不高的場景。如將資料匯入到hdfs，再執行乙個map reduce job。2.如果實時性要求高的，上面的方法就不行了。因此就帶來第二種方法。在資料每次增長一筆的時候，就...