企业官网建设流程全解析

一. Storm DefaultScheduler

是‌基于“先清理无效资源，再均匀分配”策略的默认调度器‌，核心逻辑为：识别需调度拓扑→回收死节点/多余 Slot→将可用 Slot（含空闲 + 可重分配）按轮询方式均匀打散分配给 Executor，确保多拓扑间资源公平且单拓扑内负载分散 。‌‌

核心工作流程

1. ‌判定调度需求‌：遍历集群所有 Topology，若已分配 Worker 数 < 配置 NumWorkers或存在未分配 Executor，则标记为需调度 。
2. ‌收集资源池‌：获取当前集群‌空闲 Slot‌（Supervisor 未占用端口）及当前拓扑‌已分配但可重用的 Slot‌（节点非黑名单且端口有效）。
3. ‌计算目标容量‌：可用总 Slot = 空闲 Slot + 可重用 Slot，取其与拓扑配置最大 Worker 数的最小值作为本次分配上限 。
4. ‌清理坏 Slot‌：若当前分配不均（如某节点 Executor 过多/过少）或存在死节点残留，计算并释放“坏 Slot"（bad-slots），使其回归可用池 。
5. ‌均匀分配执行‌：调用EvenScheduler算法，将 Executor 按[start-task, end-task]分组，轮询遍历排序后的可用 Slot 列表，依次绑定，实现跨节点负载打散 。‌‌

关键机制详解

• ‌Slot 与 Executor 映射‌：1 个 Slot 对应 1 个 Worker 进程（占用一个端口），1 个 Worker 可运行多个 Executor 线程；调度器决定的是"Executor 组”到"Slot"的映射关系，而非单个 Task 。
• ‌坏 Slot 识别逻辑‌：对比“理想分布”（总 Executor 数÷目标 Worker 数）与“实际分布”，偏离理想配额的 Slot 被视为坏 Slot 予以释放；例如 7 个 Executor 分 3 个 Worker，理想为 [3,2,2]，若出现 [4,2,1] 则多余部分被标记释放 。
• ‌与 EvenScheduler 区别‌：DefaultScheduler 在调用均匀分配前多一步‌资源回收‌（free bad slots），优先清理其他拓扑不再需要或已失效的资源，再执行均匀分配；EvenScheduler 仅做纯均匀分配，不主动回收 。‌‌

局限性与场景

• ‌无感知资源权重‌：不考虑 CPU/内存具体负载，仅基于端口数量平均分配，可能导致高负载拓扑资源不足 。
• ‌无亲和性约束‌：无法指定特定组件（Spout/Bolt）运行在固定节点，需使用IsolationScheduler或自定义调度器实现 。
• ‌连续提交偏差‌：若频繁提交单 Worker 拓扑，可能因 Slot 排序机制导致资源集中在部分节点，需结合ResourceAwareScheduler优化 。‌‌

二. Isolation Scheduler

是 Apache Storm 中基于‌管理员预配置‌实现‌机器级物理隔离‌的调度器，核心机制为‌优先独占分配指定拓扑所需节点数‌，未列出的拓扑共享剩余资源，必要时可‌抢占非隔离拓扑资源‌以保障隔离拓扑运行 。‌‌

核心工作原理

1. ‌配置驱动隔离‌：仅在 Nimbus 端storm.yaml通过isolation.scheduler.machines映射表定义哪些 Topology 需隔离及对应机器数量，普通提交者无法动态修改；未列入列表的 Topology 视为非隔离态 。
2. ‌两阶段调度流程‌：
   • ‌第一阶段（隔离优先）‌：遍历配置列表，按序为每个隔离 Topology 分配‌整台 Supervisor 节点‌（非 Slot），若资源不足则‌强制释放‌非隔离拓扑占用的节点以满足需求；分配后这些节点‌严禁‌被其他任何 Topology 使用 。
   • ‌第二阶段（共享剩余）‌：隔离任务分配完毕后，调用类似DefaultScheduler逻辑，将剩余空闲节点均匀分配给所有非隔离 Topology 。
3. ‌资源抢占机制‌：当新提交的隔离 Topology 需要资源但集群空闲节点不足时，调度器会主动回收已分配给非隔离 Topology 的节点，确保隔离拓扑的 SLA 。
4. ‌故障转移角色‌：未被隔离占用的剩余节点兼具双重职能：既运行非隔离拓扑，也作为隔离拓扑的‌故障转移备用资源‌（当隔离节点宕机时可临时接管）。‌‌

关键配置与限制

• ‌启用方式‌：storm.scheduler: "org.apache.storm.scheduler.IsolationScheduler"
• ‌映射示例‌：

  isolation.scheduler.machines: "prod-topology-a": 8 "prod-topology-b": 3

• ‌权限控制‌：配置仅集群管理员可修改，防止普通用户恶意占用全部资源 。
• ‌粒度限制‌：隔离单位是‌整台机器（Supervisor）‌，而非单个 Worker Slot；同一机器上只能运行被授权的单一隔离 Topology 的 Worker 。‌‌

适用场景与局限

• ‌适用‌：生产环境核心拓扑需与开发/测试拓扑彻底物理隔离，避免资源争抢导致延迟抖动 。
• ‌局限‌：资源利用率可能较低（机器独占）；配置不灵活（需重启 Nimbus 或重载配置生效）；不适合细粒度资源管控场景（此时推荐 ResourceAwareScheduler）。‌‌

三. Storm Multitenant Scheduler

‌1. 隔离性‌：

• ‌资源隔离‌：MTS通过资源隔离来确保不同租户的数据处理不会相互干扰。每个租户都有自己的计算资源和执行环境，包括独立的线程、内存空间和磁盘空间。
• ‌任务隔离‌：在Storm中，每个租户的任务（Topology）被分配到独立的JVM进程中运行，这样可以防止一个租户的任务对其他租户造成影响。

‌2. 资源分配与调度‌：

• ‌动态资源分配‌：MTS可以根据不同租户的需求动态地分配资源。例如，某些租户可能需要更多的CPU或内存资源，而其他租户可能只需要较少的资源。
• ‌公平调度‌：为了确保所有租户都能公平地获得所需的资源，MTS使用公平调度算法来分配资源。这有助于避免某些租户过度使用资源而影响其他租户。

‌3. 安全性与权限管理‌：

• ‌细粒度权限控制‌：MTS提供了细粒度的权限控制机制，允许管理员根据需要为不同的用户或租户设置不同的权限级别。例如，某些用户可能只能查看自己的数据流，而其他用户则可能具有更高的权限来修改或管理其他租户的Topology。
• ‌审计与监控‌：为了确保系统的安全性和合规性，MTS支持审计和监控功能，可以记录所有关键操作和事件，帮助管理员追踪和审查系统活动。

‌4. 弹性与容错‌：

• ‌自动扩展‌：MTS能够根据负载自动扩展租户的资源使用，确保系统在高负载情况下仍能保持稳定和高效。
• ‌故障恢复‌：在发生故障时，MTS能够快速恢复受影响的租户和任务，减少停机时间和数据丢失。

实现方式

• ‌多租户架构‌：每个租户的数据处理都在独立的集群或子集群中运行，这些集群可以是物理隔离的，也可以是逻辑隔离的。
• ‌配置与策略管理‌：通过配置文件或管理界面，管理员可以定义不同租户的资源配额、优先级和策略。
• ‌监控与调优工具‌：提供工具来监控每个租户的性能和资源使用情况，以便进行调优和优化。

总结

Storm Multitenant Scheduler通过资源隔离、动态资源分配、细粒度权限控制、弹性与容错机制等手段，实现了多租户环境下的高效、安全和可扩展的数据处理。这种设计使得Storm能够广泛应用于企业级应用场景，满足不同客户或项目对实时数据处理的需求。通过上述原理和实现方式的详细解析，我们可以更好地理解和应用Storm的多租户调度器。

四. Resource Aware Scheduler

Apache Storm是一个分布式实时计算系统，它允许你处理大规模数据流。在Storm中，资源调度器（Resource Aware Scheduler）是管理Storm集群中资源分配的核心组件。Storm的资源调度器旨在优化资源使用，提高作业执行效率，并确保集群的稳定运行。以下是关于Storm Resource Aware Scheduler（简称RAS）的详细解析：

1. RAS的基本概念

RAS是Storm 1.2.0版本引入的一个新的调度器，旨在解决早期调度器在资源分配方面的不足。传统的调度器，如Backtype调度器（Backtype Scheduler），在资源分配上比较简单，主要是基于任务的并行度（parallelism hint）来分配资源，这可能导致资源分配不均或某些节点过载。

RAS通过更智能的资源分配策略来解决这些问题。它考虑了多种因素，如任务的资源需求、任务的优先级、集群的当前负载等，来动态地分配资源。

2. RAS的关键特性

• ‌动态资源分配‌：RAS根据集群的当前状态和未来需求动态调整资源的分配。例如，它会监控每个节点的负载情况，并在必要时重新分配任务以平衡负载。

• ‌基于优先级的调度‌：RAS允许为不同的任务设置优先级，确保高优先级的任务首先获得足够的资源。

• ‌资源预留‌：RAS可以在高峰时段预留资源，确保在这些时段有足够的资源处理任务，减少因资源不足导致的任务延迟。

• ‌弹性扩展‌：RAS能够根据集群的负载自动扩展或缩减任务的数量，以优化资源使用效率。

3. RAS的工作流程

1. ‌资源请求‌：每个任务向RAS提交其资源需求（如CPU、内存）。

2. ‌资源分配‌：RAS根据任务的资源需求、优先级和集群的当前负载情况，决定将任务分配到哪个节点。

3. ‌监控与调整‌：RAS持续监控集群的状态和任务的执行情况，根据需要调整资源的分配。例如，如果某个节点的负载过高，RAS可能会将一些任务重新分配到其他节点。

4. ‌反馈机制‌：RAS通过收集任务的执行反馈来优化未来的资源分配决策。例如，如果一个高优先级的任务频繁延迟，RAS可能会增加该任务所在节点的资源预留。

4. 如何配置和使用RAS

在Storm 1.2.0及以上版本中，默认启用RAS。你可以通过Storm的配置文件（如storm.yaml）来调整RAS的行为，例如设置默认的并行度、优先级策略等。

# Example configuration in storm.yaml storm.scheduler: "org.apache.storm.scheduler.resource.ResourceAwareScheduler"

5. 优势与挑战

‌优势‌：

• 更好的资源利用率和负载均衡。
• 更高的任务执行效率和更低的延迟。
• 更好的集群稳定性和可扩展性。

‌挑战‌：

• RAS的实现和配置可能需要深入了解Storm的内部机制和集群的特定需求。
• 动态调整可能导致一些初始配置上的不适应，需要一定的调优过程。

Storm Backpressure Scheduler

Storm是一个分布式实时计算系统，它使用Apache Thrift作为其序列化框架。Storm中的Backpressure Scheduler是Storm集群的一个重要组成部分，它用于处理数据流的背压（Backpressure）问题。背压是指在数据流处理过程中，由于下游处理速度跟不上上游产生速度，导致上游产生数据堆积的情况。如果不加以控制，背压可能会导致系统性能下降甚至崩溃。

五. Storm Backpressure Scheduler的工作原理

1. ‌监控数据流状态‌：Storm的Backpressure Scheduler首先监控集群中各个组件（如spouts和bolts）的数据流状态。它会收集每个组件的执行延迟、队列长度、处理速度等信息。

2. ‌评估背压条件‌：根据收集到的数据，Backpressure Scheduler会评估当前是否处于背压状态。通常，如果某个组件的队列长度持续增长或者执行延迟增加到一定阈值，就会被认为是处于背压状态。

3. ‌调整任务分配‌：一旦检测到背压，Backpressure Scheduler会根据当前的背压情况动态调整任务（即spout或bolt实例）的分配。这可能包括减少某些组件的任务数，或者将任务从一个节点迁移到另一个节点以分散负载。

4. ‌通知和恢复‌：在调整任务分配后，Scheduler会通知Nimbus（Storm的集群管理器），由Nimbus负责重新分配任务到新的节点上。一旦背压得到缓解，Scheduler会逐渐恢复原来的任务分配策略。

关键概念和组件

• ‌Spout‌：数据的源头，负责从外部数据源（如Kafka、RabbitMQ等）读取数据流。
• ‌Bolt‌：数据处理单元，负责执行数据的转换、过滤、聚合等操作。
• ‌Nimbus‌：Storm集群的管理者，负责任务的调度和资源管理。
• ‌Zookeeper‌：用于在集群中维护配置信息、提供分布式锁等服务的协调服务。

配置和优化

在使用Storm的Backpressure Scheduler时，可以通过配置一些参数来优化性能，例如：

• ‌队列大小‌：设置适当的队列大小可以减少背压的发生概率。
• ‌执行延迟阈值‌：调整背压检测的延迟阈值可以更早地触发背压响应机制。
• ‌任务分配策略‌：根据实际工作负载调整任务分配策略，以更好地利用集群资源。

结论

Storm的Backpressure Scheduler通过实时监控和动态调整任务分配来缓解数据流中的背压问题，从而保持系统的稳定性和性能。通过合理的配置和优化，可以有效地管理和控制数据流处理过程中的背压问题，确保Storm集群的高效运行。