Storm介绍(二)

by admin on 2018年12月26日

作者:Jack47

1.高冒出响应性能特别好,官方Nginx处理静态文件出现5w/s

转载请保留作者和原文出处

2.反向代码性能特别强(可用以负载均衡)

欢迎关注我的微信公众账号程序员杰克,两边的篇章会联合,也足以添加我的RSS订阅源

3.内存和cpu占比率低(为Apache的1/5-1/10);

本文是Storm系列之一,首要介绍Storm的架构设计,推荐读者在读书Storm介绍(一)的底蕴之上,阅读这一篇。本文只是作者的读书笔记,偏重于浅层次的架构介绍,假使想实在通晓里面设计时候的权衡,还索要更多的去阅读Storm源码。

4.对后端服务有健康检查效率

通晓Storm的架构,有助于帮衬我们了然大型分布式系统设计中需要缓解的问题,以及缓解问题的思路,帮忙大家更好的开展Storm性能调优化。

5.支持 PHP cgi方式和fastcgi方式

架构

先上一张Storm的架构图,假如熟谙GFS和Hadoop的架构,会发现那些系统的架构图都很类似。
图片 1

Storm架构图

6.部署代码简介且容易上手

各节点的效益

若是您了解Hadoop的话,可以这么做一下类比:

Hadoop Storm
JobTracker Nimbus(只有一个)
TaskTracker Supervisor(有很多个)
MapReduce任务 Topology

可以观察Nimbus是调度器,WorkerTask的容器,Task是任务的确实实施者。

起初拓扑

为了在集群上启动一个拓扑,需要首先把代码打包成一个“胖jar包”–必须带有所有的看重代码,除了Storm它本身,因为Storm集群会提供。然后在一台设置了storm命令行的机器上通过storm jar一声令下来交给拓扑:

storm jar my-topology-version-with-dependency.jar com.corp.MyTopology arg1 arg2

以此命令会连到Nimbus,上传jar包。接下来Nimbus会把拓扑的代码运送到多台不同的机器或者JVM上。只有当拓扑在机械上布置成功了同时在JVM中开头化了后头,才能确实起头拍卖音信。

Master结点(Master node)

在分布式系统中,调度服务特别重大,它的规划,会一向关乎到系统的周转效用,错误恢复生机(fail
over),故障检测(error detection)和品位扩大(scale)的力量。

集群上职责(task)的调度由一个Master节点来负责。这台机器上运行的Nimbus经过负责任务的调度。另外一个进程是Storm
UI,可以界面上查看集群和富有的拓扑的周转状态。

从节点(Slave node)

Storm集群上有两个从节点,他们从Nimbus上下载拓扑的代码,然后去真正执行。Slave上的Supervisor经过是用来监督和管制实际运行工作代码的进程。在Storm
0.9过后,又多了一个历程Logviewer,可以用Storm
UI来查看Slave节点上的log文件。
在配备文件storm.yaml中,决定了一台机器上运行多少个worker:

supervisor.slots.ports:
- 6700
- 6701
- 6702

ZooKeeper的作用

ZooKeeper在Storm上不是用来做信息传输用的,而是用来提供协调服务(coordination
service),同时储存拓扑的情况和总计数据。

  • ZooKeeper相当于一块黑板,SupervisorNimbus和worker都在下边留下约定好的音信。例如Supervisor启动时,会在ZooKeeper上注册,Nimbus就足以窥见SupervisorSupervisor在ZooKeeper上预留心跳音信,Nimbus透过这么些心跳音信来对Supervisor展开常规检测,检测出坏节点
  • 出于Storm组件(component)的情况新闻存储在ZooKeeper上,所以Storm组件就可以无状态,可以kill -9来杀死
    • 譬如说:Supervisors/Nimbus的重启不影响正在运转中的拓扑,因为状态都在ZooKeeper上,从ZooKeeper上重新加载一下就好了
  • 用来做心跳
    • Worker通过ZooKeeper把孩子executor的意况以心跳的形式反映给Nimbus
    • Supervisor进程经过ZK把温馨的事态也以心跳的款型反映给Nimbua
  • 仓储近期任务的错误意况(拓扑截至时会删除)

Storm的容错(Fault Tolerance)机制

正如“搭建一个Storm集群”一文介绍的一样,必须用工具如daemontools或者monit来监督Nimbus和Supervisor的后台进程。这样倘诺Nimbus或者Supervisor经过挂掉,会被daemontools检测到,并开展重启。

NimbusSupervisor过程被规划成很快失利(fail
fast)的(当境遇特此外情景,进程就会挂掉)并且是无状态的(状态都保存在Zookeeper或者在磁盘上)。

最关键的是,worker进程不会因为Nimbus或者Supervisor挂掉而受影响。这跟Hadoop是不雷同的,当JobTracker挂掉,所有的天职都会没了。

  1. 当Nimbus挂掉会如何?

    只要Nimbus是以引进的点子处于进程监管(例如通过supervisord)之下,这它会被重启,不会有其余影响

    否则当Nimbus挂掉后:

    • 早就存在的拓扑可以持续健康运作,可是不可以交付新拓扑
    • 正在运行的worker进程依旧可以继承做事。而且当worker挂掉,supervisor会一贯重启worker。
    • 挫折的任务不会被分配到任何机器(是Nimbus的天职)上了
  2. 当一个Supervisor(slave节点)挂掉会怎么着?

    要是Supervisor是以引进的形式处于进程监管(例如通过(supervisord)[supervisord.org/])之下,这它会被重启,不会有其他影响

    不然当Supervisor挂掉:
    分配到这台机械的具有任务(task)会晚点,Nimbus会把这多少个职责(task)重新分配给另外机器。

  3. 当一个worker挂掉会怎么?

    当一个worker挂掉,supervisor会重启它。假如开行一直退步那么此时worker也就不可能和Nimbus保持心跳了,Nimbus会重新分配worker到其他机器

  4. Nimbus算是一个单点故障吗?
    虽然Nimbus节点挂掉,worker进程仍能持续工作。而且当worker挂掉,supervisor会平素重启worker。可是,没有了Nimbus,当需要的时候(倘使worker机器挂掉了)worker就不可能被重新分配到其他机器了。
    从而答案是,Nimbus在“某种程度”上属于单点故障的。在实际中,这种气象没什么大不断的,因为当Nimbus进程挂掉,不会有悲凉的政工时有暴发

硬件要求

ZooKeeper

  1. 推介精心设计过的机器,因为ZooKeeper是Storm的瓶颈
    • 各类机器使用一个ZK的实例
    • 留神因为同样台机械上的任何进程或者虚拟机他们是共享这台机械的,所以可能会影响ZK的性质(来源)
  2. I/O是ZooKeeper的瓶颈
  • 把ZooKeeper的存储放到自己的磁盘上
  • 动用SSD会分明升级性能
  • 常规意况下,Zookeeper的每一遍写操作都会共同到磁盘,那就导致了五遍磁盘寻址操作(一回是数额,五回是多少的日志)。当有着的worker都发心跳给ZooKeeper时,可能会肯定影响属性(来源)。
    • 内需监控ZooKeeper节点的I/O负载
  1. 推荐在生育条件上运行的ZooKooper集群有起码3个节点,这样即使有一个ZooKeeper服务器挂掉了(例如举办维护),也是可以的。

Storm安全性

固有设计Storm时,完全没有把安全性考虑在内
当今安全性能相关的效应在一步步加进去
Storm 0.9.x版本上的平安问题:

  1. 从来不表达机制(authentication),没有授权机制(authorization)
  2. 传输的数量(例如worker之间)没有加密
  3. ZooKeeper上囤积的多少没有访问限制
  4. 假如Nimbus的Thrift端口没有锁住,任意的用户代码都足以在节点上实施

更多Storm安全性方面的提出见这里

题外话:
在触发Storm之后,有个问题在自我的脑际里升起,国内的大商店,比如Baidu,Ali,腾讯,都是有出生Storm这类实时总计框架的泥土的,然则怎么一贯不做出来吧?

Apache Storm Basic
Training

Fault
tolerance

Storm in pictures

Storm 0.9 Basic
Training


倘若您看了本篇博客,觉得对您抱有收获,请点击右下角的“推荐”,让更四个人看到!

帮衬Jack47写作,打赏一个鸡蛋灌饼钱呢

图片 2

微信打赏

图片 3

支付宝打赏

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图