共计 2629 个字符，预计需要花费 7 分钟才能阅读完成。
这篇文章主要讲解了“storm 使用要注意哪些点”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“storm 使用要注意哪些点”吧！
个人理解：storm 是一个分布式、实时、流、计算、平台，几个特性从这名字中已经看出来了。
一、实时，简单理解就是数据进入系统要迅速被处理，也就是延迟要小。
二、流，流具有什么特点，想象一下你站在长江岸边，什么感觉，震撼？浩荡？小弟没看过，我理解的流就是①没有阻塞②方向只能从高到低③流之间没有影响④可以灵活改变流的方向（挖个沟，对应 storm 的 grouping 机制）⑤不间断
三、计算，这个概念其实比较广，计算机处理任何东西一般都涉及计算，在这里我理解的还是没有阻塞，也就是更倾向于计算，不要和外部过多资源进行交换，例如网络、磁盘。。。
四、分布式，分布式大家听的耳朵都起茧子了，个人有个人的理解，分布式一个比较重要的衡量指标就是可扩展性（线性、非线性）、资源对服务或用户透明、具有一定的负载均衡能力、充分利用资源？（好像国内好多搞 hadoop 的都用牛逼服务器，貌似 hadoop 出来是为了利用那些过时老旧的机器的）、最好是无序。。。
五、平台，这个好理解，它就是提供了以上四个主要特性的平台，那满足这个平台要求的服务就可以在这个平台上跳舞，一个好的平台可以改变我们的命运哦~
六、可靠性，分布式系统那么多组件，某个出现了问题 storm 可以自动恢复
适应场景
从以上 5 点可以总结出 storm 注重的是实时性、偏重计算、分布式特性、线性可扩展、流的特性。当然有了这些特性最终还是要靠到业务逻辑上，这个我写过一篇基于 storm 做爬虫的可能性，我觉得在爬虫的场景里边，用 storm 是再好不过的了，因为爬虫一般是 7 *24 小时不间断的从网络上获取数据，构成了流，一般还要求实时性，就是尽快将最新的内容搞到自己的口袋里，计算量也不小涉及到各种数据的处理，然后遇到瓶颈后可以平滑的进行线性可扩展，无需停止服务，最主要一点是爬虫种子间处理没什么关联，完全切合分布式的特性，总之等等吧，我觉得如果把爬虫放到 storm 上犹如杨过获得了一把屠龙刀。
注意几点（实践出真知？）
一个 worker 被 kill 情况下，假如这个 worker 和其它 worker 没有关系，貌似其它 worker 不会受影响，被 kill 的 worker 会被 storm 启动，若和其它 worker 有关系，那么其它 worker 也会受影响，task 会被重新启动（类似于 rebalance 的效果，好像和 rebalance 的过程一样）。
acker 貌似是就近原则，一个 spout 的消息优先采用本地 acker 跟踪，经测试效果看，一旦 acker 被 kill，当这个 acker 再次被启动的时候，其之前跟踪的那些消息将迅速失败。
acker 无法被 rebalance。
大家都知道 storm 中 nextTuple 和 ack 或 fail 方法是在一个线程下执行的，经测试观察，storm 会先调用 spout 的 nextTuple() 然后再检查 ack(mid) 或 fail(mid)，再配合 storm 的 pending 机制，这个大家有时需要注意，在特定的需求下可能会有类似于死锁的问题。（这里不详细说明，如有需要可以留言给我，因为只是在我们的特定需求上出现过问题）。
storm 虽然不建议大家在 bolt 或 spout 中 new 新的线程，但有时为了异步处理，也是不可避免的，经测试观察，storm 自己启动的线程优先级比较高，假若你想自己的线程得到充分调用需要设置自己创建的线程优先级到更高（我一般直接到最大了，然后用 lock 机制，然后 windows 和类 UNIX 系统 jvm 线程优先级是有差别的，这个大家可以去深入了解下）。
因为不同的机器可能资源不同，storm 默认调度器机制基本是平均分配机制，这会导致，数据乱序情况比较严重。
storm 先启动你的 spout 然后再依次启动不同机器上的 bolt task，spout 不会等 bolt 都启动完成后才开始发数据，这时假如你有一个 bolt 初始化耗费 1 分钟，然后你的消息超时设置的是 30s，那在这个 bolt 启动完成之前的消息会因为 spout 超时设置的比较短而导致消息超时，从而导致 spout fail（mid）。 好吧，我承认这个我之前理解错了，storm 会执行 spout 的 open 和各个 bolt 的 prepare，依次都初始化好后会激活 spout（Activate spout），这时 spout 工作线程才开始执行 nextTuple。
topology 的 TOPOLOGY_RECEIVER_BUFFER_SIZE 设置成 16 会比较快，至少在我们业务上整体速度在 1w+ 这个速度下，设置成 16 比 8 或 32 要快，当然不同的场景这个值可能会不同（这里要强调一下，storm 中有四个 buffer，理解起来比较别扭，而且四个 buffer 不是收 / 发对称的，还是推荐大家去看官方文档或权威一点的地去学习）
先这么多。。。想起什么了，后期再补充
bolt 处理错误不好往 spout 传，也就是一个 tuple 处理失败了，spout 端只能知道失败的消息的 id，而不知道具体失败的原因，这块儿我觉得不是很灵活，当然要是在一个 worker 下不会有这种问题，只出现在分布式环境下。
bolt emit 一个 tuple 虽然可以 anchor（锚定）到一个 list Tuple，但是 collector 的 ack 或 fail 方法只能接收单个 tuple，不能直接 ack/fail 一个 list Tuple，如下代码：
collector.emit(TopoUtil.StreamId.DEFAULT,
list,
new Values(sonSMessage));
for (Tuple tuple : list) {collector.ack(tuple);
}storm rebalance 经测试看有点问题，就是 - n 参数只能从一开始提交的进程数 rebalance 到更小，不能从 2rebalance 到 3 或 4 或更大，- e 参数没有这个问题，但线程数是不能大于 task 数的，这个弄过 storm 都知道，前面需要注意
感谢各位的阅读，以上就是“storm 使用要注意哪些点”的内容了，经过本文的学习后，相信大家对 storm 使用要注意哪些点这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
