Storm分布式实时计算模式部分读书笔记第二章

1. Puppet工具可进行自动化安装Storm，有利于部署多节点的集群；
2. Storm集群包括一个主节点：nimbus和多个工作节点：supervisor，除此之外，Storm还需要一个Zookeeper实例；
   
   nimbus和supervisor是Storm提供的后台守护进程，可以共同存在同一台机器上；
3. nimbus：协调和监控集群上运行的topology，包括topology的发布、任务指派、事件失败时重新指派任务；将topology发布到Storm集群，将预先打包成jar的文件的topology和配置信息提交到nimbus服务器上，nimbus介绍到压缩包后，会将jar包分发到足够数量的supervisor节点上，supervisor节点接收到了压缩包后，nimbus会指派task到每个supervisor并发送信号指示supervisor生成足够的worker来执行task，nimbus记录所有的supervisor节点的状态和分配给他们的task，如果nimbus发现某个supervisor没有上报心跳或者已经不可达赖，它会将故障supervisor分配的task重新分配到集群的其他supervisor节点；由此看来，nimbus如果挂掉，我们无法再提交topology，某个supervisor如果挂掉，也无法重新分配task到其他节点，但如果已提交的topology节点运行正常，则功能依然不受影响；
4. 如果shuffleGrouping的bolt的某一个或几个（不是全部）task所在的节点崩溃，很好奇topology是会依然随机的给这几个task派发任务导致原始tuple无法被处理，而丧失功能，还是会自动屏蔽掉这些task，只是并行度下降；
5. supervisor收到nimbus分配的任务后生成worker（JVM进程）执行任务，当打开了可靠传输的选项，传输到故障节点上的tuples不会受到应答确认，spout会因为超时而重新发送原始tuple，这样的过程会一直重复，直到topology从故障中恢复；
6. Zookeeper：分布式环境下提供集中的信息维护管理服务，允许客户端应用程序监控或者订阅数据集中的部分数据，当更新或者修改时，客户端都会收到通知，可实现很多机制，比如Leader选举，分布式锁和队列等；
7. Storm主要使用Zookeeper协调一个集群中的状态信息，任务的分配情况，worker的状态，supervisor之间的nimbus的拓扑度量；nimbus和supervisor节点之间的通信主要是结合ZooKeepere的状态变更通知和监控通知来处理的；
8. Storm对Zookeeper的使用相对比较轻量化，不会造成很重的资源负担，对于重量级的数据传输操作，比如发布topology时候传输jar包，Storm依赖Thirft进行通信，topology组件之间的数据传输是最影响效率的地方；
9. Storm可支持RPC调用，会有额外的DRPC服务节点加入，将DRPC、spout和bolt整合在一起工作，提供可扩展的分布式RPC能力；
10. Storm UI基于Web GUI监控Storm集群，对正在运行的topology有一定的管理功能，Storm UI只能报告由nimbus的 Trhift API获取的信息，不影响topology上其他的功能，可随时开关不影响任何topology的运行，可进行一些简单的管理功能：开启、停止、暂停以及重新均衡负载topology；
11. Strom的守护进程无论在什么时候异常终止，都需要立即重启，supervisor（非Storm中的）服务可实现这个目标；supervisor服务会自动包含所有的/etc/supervisor/conf.d/目录下的*.conf文件；我们需要编写nimbus.conf、Storm-supervisor.conf和Storm ui.conf来让他们异常时候重启；
12. end page 53（未完）