扬帆起航 继续前进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怎么怎么避免数据的丢失：
由于对应的task挂掉了，一个tuple没有被ack： storm的超时机制在超时之后会把这个tuple标记为失败，从而可以重新处理。
Acker挂掉了： 这种情况下由这个acker所跟踪的所有spout tuple都会超时，也就会被重新处理。
Spout挂掉了： 在这种情况下给spout发送消息的消息源负责重新发送这些消息。比如Kestrel和RabbitMQ在一个客户端断开之后会把所有”处理中“的消息放回队列。
调整可靠性：
去掉可靠性，减少跟踪的损耗：Config.TOPOLOGY_ACKERS 设置成 0；发射tuple的时候不指定messageid来达到不跟踪某个特定的spout tuple的目的
吞吐量不达标，可以增加acker