JAVA面试——Storm

简介: JAVA面试——Storm

27.1.1. 概念

Storm 是一个免费并开源的分布式实时计算系统。利用 Storm 可以很容易做到可靠地处理无限的

数据流,像 Hadoop 批量处理大数据一样,Storm 可以实时处理数据。

27.1.1. 集群架构

image.png

27.1.1.1. Nimbusmaster-代码分发给 Supervisor

Storm 集群的 Master 节点,负责分发用户代码,指派给具体的 Supervisor 节点上的 Worker 节

点,去运行 Topology 对应的组件(Spout/Bolt)的 Task。

27.1.1.2. Supervisorslave-管理 Worker 进程的启动和终止

Storm 集群的从节点,负责管理运行在 Supervisor 节点上的每一个 Worker 进程的启动和终止。

通过 Storm 的配置文件中的 supervisor.slots.ports 配置项,可以指定在一个 Supervisor 上最大

允许多少个 Slot,每个 Slot 通过端口号来唯一标识,一个端口号对应一个 Worker 进程(如果该

Worker 进程被启动)。

27.1.1.3. Worker具体处理组件逻辑的进程

运行具体处理组件逻辑的进程。Worker 运行的任务类型只有两种,一种是 Spout 任务,一种是

Bolt 任务。13/01/2022

Page 270 of 283

27.1.1.4. Task

worker中每一个spout/bolt的线程称为一个task. 在storm0.8 之后,task不再与物理线程对应,

不同 spout/bolt 的 task 可能会共享一个物理线程,该线程称为 executor。

27.1.1.5. ZooKeeper

用来协调 Nimbus 和 Supervisor,如果 Supervisor 因故障出现问题而无法运行 Topology,

Nimbus 会第一时间感知到,并重新分配 Topology 到其它可用的 Supervisor 上运行

27.1.2. 编程模型(spout->tuple->bolt

strom 在运行中可分为 spout 与 bolt 两个组件,其中,数据源从 spout 开始,数据以 tuple 的方

式发送到 bolt,多个 bolt 可以串连起来,一个 bolt 也可以接入多个 spot/bolt.运行时原理如下图:

image.png

27.1.2.1. Topology

Storm 中运行的一个实时应用程序的名称。将 Spout、 Bolt 整合起来的拓扑图。定义了 Spout 和

Bolt 的结合关系、并发数量、配置等等。

27.1.2.2. Spout

在一个 topology 中获取源数据流的组件。通常情况下 spout 会从外部数据源中读取数据,然后转

换为 topology 内部的源数据。

27.1.2.3. Bolt

接受数据然后执行处理的组件,用户可以在其中执行自己想要的操作。

27.1.2.4. Tuple

一次消息传递的基本单元,理解为一组消息就是一个 Tuple。13/01/2022

Page 271 of 283

27.1.2.5. Stream

Tuple 的集合。表示数据的流向。

27.1.3. Topology 运行

在 Storm 中,一个实时应用的计算任务被打包作为 Topology 发布,这同 Hadoop MapReduce

任务相似。但是有一点不同的是:在 Hadoop 中,MapReduce 任务最终会执行完成后结束;而在

Storm 中,Topology 任务一旦提交后永远不会结束,除非你显示去停止任务。计算任务

Topology 是由不同的 Spouts 和 Bolts,通过数据流(Stream)连接起来的图。一个 Storm 在集

群上运行一个 Topology 时,主要通过以下 3 个实体来完成 Topology 的执行工作:

(1). Worker(进程)

(2). Executor(线程)

(3). Task

image.png

27.1.3.1. Worker(1 个 worker 进程执行的是 1 个 topology 的子集)

1 个 worker 进程执行的是 1 个 topology 的子集(注:不会出现 1 个 worker 为多个 topology

服务)。1 个 worker 进程会启动 1 个或多个 executor 线程来执行 1 个 topology 的

component(spout 或 bolt)。因此,1 个运行中的 topology 就是由集群中多台物理机上的多个

worker 进程组成的。

27.1.3.2. Executor(executor 是 1 个被 worker 进程启动的单独线程)

executor 是 1 个被 worker 进程启动的单独线程。每个 executor 只会运行 1 个 topology 的 1 个

component(spout 或 bolt)的 task(注:task 可以是 1 个或多个,storm 默认是 1 个

component 只生成 1 个 task,executor 线程里会在每次循环里顺序调用所有 task 实例)。13/01/2022

Page 272 of 283

27.1.3.3. Task(最终运行 spout 或 bolt 中代码的单元)

是最终运行 spout 或 bolt 中代码的单元(注:1 个 task 即为 spout 或 bolt 的 1 个实例,

executor 线程在执行期间会调用该 task 的 nextTuple 或 execute 方法)。topology 启动后,1

个 component(spout 或 bolt)的 task 数目是固定不变的,但该 component 使用的 executor 线

程数可以动态调整(例如:1 个 executor 线程可以执行该 component 的 1 个或多个 task 实

例)。这意味着,对于 1 个 component 存在这样的条件:#threads<=#tasks(即:线程数小于

等于 task 数目)。默认情况下 task 的数目等于 executor 线程数目,即 1 个 executor 线程只运

行 1 个 task


image.png

27.1.4. Storm Streaming Grouping

Storm 中最重要的抽象,应该就是 Stream grouping 了,它能够控制 Spot/Bolt 对应的 Task 以

什么样的方式来分发 Tuple,将 Tuple 发射到目的 Spot/Bolt 对应的 Task.

image.png

目前,Storm Streaming Grouping 支持如下几种类型:

27.1.4.1. huffle Grouping

随机分组,尽量均匀分布到下游 Bolt 中将流分组定义为混排。这种混排分组意味着来自 Spout 的

输入将混排,或随机分发给此 Bolt 中的任务。shuffle grouping 对各个 task 的 tuple 分配的比

较均匀。

27.1.4.2. Fields Grouping

按字段分组,按数据中 field 值进行分组;相同 field 值的 Tuple 被发送到相同的 Task 这种

grouping 机制保证相同 field 值的 tuple 会去同一个 task。

27.1.4.3. All grouping :广播

广播发送, 对于每一个 tuple 将会复制到每一个 bolt 中处理。13/01/2022

Page 274 of 283

27.1.4.4. Global grouping

全局分组,Tuple 被分配到一个 Bolt 中的一个 Task,实现事务性的 Topology。Stream 中的所

有的 tuple 都会发送给同一个 bolt 任务处理,所有的 tuple 将会发送给拥有最小 task_id 的 bolt

任务处理。

27.1.4.5. None grouping :不分组

不关注并行处理负载均衡策略时使用该方式,目前等同于 shuffle grouping,另外 storm 将会把

bolt 任务和他的上游提供数据的任务安排在同一个线程下。

27.1.4.6. Direct grouping :直接分组 指定分组

由 tuple 的发射单元直接决定 tuple 将发射给那个 bolt,一般情况下是由接收 tuple 的 bolt 决定

接收哪个 bolt 发射的 Tuple。这是一种比较特别的分组方法,用这种分组意味着消息的发送者指

定由消息接收者的哪个 task 处理这个消息。 只有被声明为 Direct Stream 的消息流可以声明这种

分组方法。而且这种消息 tuple 必须使用 emitDirect 方法来发射。消息处理者可以通过

TopologyContext 来获取处理它的消息的 taskid (OutputCollector.emit 方法也会返回

taskid)。

目录
相关文章
|
8天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
31 2
|
13天前
|
存储 算法 Java
大厂面试高频:什么是自旋锁?Java 实现自旋锁的原理?
本文详解自旋锁的概念、优缺点、使用场景及Java实现。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:什么是自旋锁?Java 实现自旋锁的原理?
|
18天前
|
存储 缓存 Oracle
Java I/O流面试之道
NIO的出现在于提高IO的速度,它相比传统的输入/输出流速度更快。NIO通过管道Channel和缓冲器Buffer来处理数据,可以把管道当成一个矿藏,缓冲器就是矿藏里的卡车。程序通过管道里的缓冲器进行数据交互,而不直接处理数据。程序要么从缓冲器获取数据,要么输入数据到缓冲器。
Java I/O流面试之道
|
15天前
|
存储 缓存 Java
大厂面试必看!Java基本数据类型和包装类的那些坑
本文介绍了Java中的基本数据类型和包装类,包括整数类型、浮点数类型、字符类型和布尔类型。详细讲解了每种类型的特性和应用场景,并探讨了包装类的引入原因、装箱与拆箱机制以及缓存机制。最后总结了面试中常见的相关考点,帮助读者更好地理解和应对面试中的问题。
39 4
|
15天前
|
存储 Java 程序员
Java基础的灵魂——Object类方法详解(社招面试不踩坑)
本文介绍了Java中`Object`类的几个重要方法,包括`toString`、`equals`、`hashCode`、`finalize`、`clone`、`getClass`、`notify`和`wait`。这些方法是面试中的常考点,掌握它们有助于理解Java对象的行为和实现多线程编程。作者通过具体示例和应用场景,详细解析了每个方法的作用和重写技巧,帮助读者更好地应对面试和技术开发。
55 4
|
1月前
|
存储 安全 算法
Java面试题之Java集合面试题 50道(带答案)
这篇文章提供了50道Java集合框架的面试题及其答案,涵盖了集合的基础知识、底层数据结构、不同集合类的特点和用法,以及一些高级主题如并发集合的使用。
92 1
Java面试题之Java集合面试题 50道(带答案)
|
28天前
|
存储 Java 程序员
Java面试加分点!一文读懂HashMap底层实现与扩容机制
本文详细解析了Java中经典的HashMap数据结构,包括其底层实现、扩容机制、put和查找过程、哈希函数以及JDK 1.7与1.8的差异。通过数组、链表和红黑树的组合,HashMap实现了高效的键值对存储与检索。文章还介绍了HashMap在不同版本中的优化,帮助读者更好地理解和应用这一重要工具。
54 5
|
27天前
|
存储 Java
[Java]面试官:你对异常处理了解多少,例如,finally中可以有return吗?
本文介绍了Java中`try...catch...finally`语句的使用细节及返回值问题,并探讨了JDK1.7引入的`try...with...resources`新特性,强调了异常处理机制及资源自动关闭的优势。
20 1
|
1月前
|
Java 程序员
Java 面试高频考点:static 和 final 深度剖析
本文介绍了 Java 中的 `static` 和 `final` 关键字。`static` 修饰的属性和方法属于类而非对象,所有实例共享;`final` 用于变量、方法和类,确保其不可修改或继承。两者结合可用于定义常量。文章通过具体示例详细解析了它们的用法和应用场景。
28 3
|
1月前
|
Java
Java面试题之cpu占用率100%,进行定位和解决
这篇文章介绍了如何定位和解决Java服务中CPU占用率过高的问题,包括使用top命令找到高CPU占用的进程和线程,以及使用jstack工具获取堆栈信息来确定问题代码位置的步骤。
104 0
Java面试题之cpu占用率100%,进行定位和解决

热门文章

最新文章