手记

storm学习笔记

扬帆起航 继续前进4

热数据的处理(统计分析-->storm、spark)     缓存雪崩的时的系统可用性和稳定性(hystrick)
zookeeper 分布式锁

1.什么是storm
mysql:TB、PB数据,尴尬    数据量太大怎么办? 分布式mysql
hadoop:海量数据,分布式存储、分布式计算,最终计算结果汇总     ---->非实时性,当下性能消耗低
每天将所有的数据收集起来,第二天凌晨统一批量计算
离线处理,批量计算

storm:每一条数据立即计算,实时计算技术
国内技术JStorm  阿里的

特点:实时项目、扩容方便、数据不丢失、重复计算、稳定性和可用性很高、使用便捷

storm集群架构:nimbus(集群架构的主节点)、supervisor、worker、executor、task
任务分割

storm核心概念:Topology:spout+bolt 拓扑    几个wroker
Spout:数据源的代码组件       几个excutor,几个task
bolt:一个业务处理组件,spout会将数据传递给bolt,各种bolt还可以串联成一个计算链条    几个excutor,几个task
tuple:就是一条数据
stream:一个流,源源不断的tuple形成stream

并行度和流分组:
并行度是task,每个bolt,spout副本运行在task下
流分组:task数据与数据之间的流向

流分组策略:shuffle Grouping: 随机发射,负载均衡
Fields  Grouping:根据一个fileds,或者多个

2.实践
实战:纯手工WordCount

storm集群的搭建,以及项目的部署。。。。
建议博客:https://www.cnblogs.com/hd3013779515/p/6961293.html

zookeeper集群:
server.0=172.16.55.131:2888:3888
server.1=172.16.55.132:2888:3888
server.2=172.16.55.133:2888:3888

export PATH=.:$STORM_HOME/bin:$PATH

storm.zookeeper.servers:

  • "eshop-cache01"

  • "eshop-cache02"

  • "eshop-cache03"

3.深入理解storm的可靠性
完全处理:完全处理的意思是该MessageId绑定的源Tuple以及由该源Tuple衍生的所有Tuple都经过了Topology中每一个应该到达的Bolt的处理。
Acker组件的任务就是跟踪从某个task中的Spout流出的每一个messageId所绑定的Tuple树中的所有Tuple的处理情况。
多个源Tuple可以共用同一个MessageId,表示这多个源Tuple对用户来说是同一个消息单元,它们会被放到同一棵tuple树中,

aker 是怎么知道每一个spout tuple交给哪个task处理?
当一个spout发射一个新的tuple, 它会简单的发一个消息给一个合适的acker,并且告诉acker它自己的id(taskid), 这样storm就有了taskid-tupleid的对应关系。 当acker发现一个树完成处理了, 它知道给哪个task发送成功ack的消息,否则fail

aker的高效:
显示更总tuple树太消耗资源
tuplid一直亦或,到0,说明结束了
亦或了解下:
0 ^ first
^ first ^second
^second ^third
......
^last = 0

storm怎么怎么避免数据的丢失:

  1. 由于对应的task挂掉了,一个tuple没有被ack: storm的超时机制在超时之后会把这个tuple标记为失败,从而可以重新处理。

  2. Acker挂掉了: 这种情况下由这个acker所跟踪的所有spout tuple都会超时,也就会被重新处理。

  3. Spout挂掉了: 在这种情况下给spout发送消息的消息源负责重新发送这些消息。比如Kestrel和RabbitMQ在一个客户端断开之后会把所有”处理中“的消息放回队列。

调整可靠性:
去掉可靠性,减少跟踪的损耗:Config.TOPOLOGY_ACKERS 设置成 0;发射tuple的时候不指定messageid来达到不跟踪某个特定的spout tuple的目的
吞吐量不达标,可以增加acker

0人推荐
随时随地看视频
慕课网APP