好程序员分享大数据学习笔记： Storm 架构 ， Storm 架构 :master/slave

　　主节点 :Nimbus

　　负责在集群上进行任务 (Topology) 的分发与资源的调度以及监控

　　工作节点 :Supervisor

　　接收到任务请求后，启动一个或多个 Worker 进程来处理任务 ; 默认情况下，一个 Supervisor 最多启动 4 个 Worker

　　工作进程 :Worker

　　在 Supervisor 中的子进程，存在着若干个 Spout 和 Bolt 线程，来负责 Spout 和 Bolt 组件处理任务 ( 实际是开启的 executor 线程 )

　　作业 :Topologies( 死循环，不会结束 )

　　Spout: 获取数据的组件

　　Bolt: 处理数据的组件

　　Stream:Spout 和 Bolt 之间数据流动的通道

　　Tuple:

　　1)Stream 的最小组成单位， Spout 向 Bolt 发送一次数据叫一个 Tuple

　　2) 同一个 Stream 中 Tuple 的类型相同，不同的 Stream 中可能相同 / 不同

　　3) 一个 key-value 形式的 Map

　　数据流分发策略 (Stream groupings):

　　解决 Spout 和 Bolt 之间数据传输 ( 发送 Tuple 元组 ) 的问题

　　1)shuffleGrouping:

　　随机派发 Stream 中的 Tuple 到 Bolt 中

　　2)fieldsGrouping:

　　根据字段的哈希值与 Bolt 个数进行取模操作然后进行分组发送，一个节点是一个 Worker ， 一个 Bolt 是一个 task ， 全部节点的 Spout 或 Bolt 的个数叫并发度。

　　Storm 并发度设置 :

　　1.Worker 并发度 :

　　首先按照集群规模和集群的物理位置来设定

　　一般会把 Worker 均分到每一个节点里， 一个 supervisor 默认设置一个 Worker

　　2.Spout 数量设定 :

　　Spout 总数默认等于 Kafka( 消息中间件 ) 对应 Topic 的分区数，提高吞吐速度

　　一般一个 Worker 设置一个 Spout

　　3.Bolt1 数量设定 :

　　首先根据数据量和处理数据的时间来设定

　　一般情况下， Bolt1 的数量是 Spout 数量的 2 倍 ( 根据项目进行修改 )

　　4.Bolt2 数量设定 :

　　首先根据数据量和处理数据的时间来设定，因为 Bolt1 传过来的中间结果数据已经减少很多， Bolt2 的数量可以酌情减少。

　　容错机制 : 异或方式 < 相同为 ，不同为 1>

　　tupleId - 产生新数据，会产生一个 tupleId;

　　整个过程中的 tupleId 按顺序两两异或到最后

　　若结果为 ，则数据正确，否则错误

　　messageId - 代表整条信息， API 中指定提供给程序员， long 型

　　rootId - 代表某条信息，提供给 storm 框架

　　出现数据运算失败的两种情况 :

　　execute(){

　　1. 异常 ( 数据异常 )

　　2. 任务运行超时 -- 认为处理失败

　　}

　　因为数据发送时导致的数据重复发送问题， 如何解决 ?

　　Ⅰ .

　　1. 比如对订单信息做处理， 处理成功后， 把订单信息 ID 存储到 Redis(set)

　　2. 信息发送时， 判断是否处理过此信息

　　execute(){

　　if()

　　else()

　　}

　　Ⅱ .

　　不作处理 : 点击流日日志分析 : pv ， uv

　　指标分析 : 订单人数， 订单金额

　　消息的可靠性保障和 acker 机制 : open / nextTuple / ack / fail/ close

　　Ⅰ .Spout 类 :

　　在发送 tuple 时， Spout 会提供一个 msgId ，用于在后续识别 tuple;Storm 会根据 msgId 跟踪创建的 tuple 树，直到某个 tuple 被完整处理，根据 msgId 调用最初发送 tuple 的 Spout 中 ack() 方法，检测到超时就调用 fail() 方法 -- 这两个方法的调用必须由最初创建这个 tuple 的 Spout 执行 ; 当 Spout 从消息队列 (Kafka/RocketMQ) 中取出一条数据时，实际上没有被取出，而是保持一个挂起状态，等待消息完成的信号，挂起状态的信息不会被发送到其它的消费者 ; 当该消息被 " 取出 " 时，队列会将消息体数据和一个唯一的 msgId 提供给客户端，当 Spout 的 ack()/fail() 方法被调用时， Spout 根据发送的 id 向队列请求将消息从队列中移除 / 重新放入队列。

　　Ⅱ .acker 任务 :

　　高效的实现可靠性 -- 必须显式的在 Bolt 中调用定义在 Spout 中的 ack() 和 fail() 方法， Storm 拓扑有一些特殊的称为 "acker" 的任务，负责跟踪 Spout 发送的 tuple 的 DAG ，当一个 acker 发现 DAG 结束后，它就会给创建 Spout tuple 的 Spout 任务发送一条消息，让这个任务来应答这个消息。 acker 并不会直接的跟踪 tuple 树，在 acker 树中存储了一个表，用于将 Spout tuple 的 id 与一对值相映射， id 为创建这个 tuple 的任务 id ，第二个值为一个 64bit 的数字 (ack val) ，这个值是这棵树中所有被创建的或者被应答的 tuple 的 tuple id 进行异或运算的结果值。

　　Ⅲ . 移除可靠性 :

　　1. 将 Config.TOPOLOGY_ACKERS 设置为

　　2. 在 SpoutOutputCollector.emit 方法中省略消息 id 来关闭 spout tuple 的跟踪功能

　　3. 在发送 tuple 的时候选择发送“非锚定”的 (unanchored)tuple

　　各位大数据爱好者，虽然现在学习之路很辛苦，前方的道路还有很多攻坚战要打，希望大家这段时间沉下心来，不管有多累，都要向着前方，不断的奔跑 !