Apache SeaTunnel Zeta 引擎分离集群部署指南Master / Worker 角色拆分、HA 配置与任务提交实战【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel导读本文基于 Apache SeaTunnel Zeta 引擎的官方部署文档系统讲解分离集群Separated Cluster模式的完整落地流程Master 与 Worker 以独立进程运行、职责分离、通过 Hazelcast 组成高可用集群。读完本文你将掌握分离集群的最小部署规模与 HA 节点规划、seatunnel.yaml与hazelcast-master/worker.yaml的核心参数配置、IMap 数据持久化到 HDFS/OSS/S3 的方法以及使用命令行客户端和 REST API 提交与管理任务的全套操作。本文以 docs/en/engines/zeta/separated-cluster-deployment.md 为主体并结合仓库中的真实配置文件如 config/seatunnel.yaml、config/hazelcast-master.yaml与启动脚本源码 seatunnel-cluster.sh 进行深化佐证。一、分离集群模式的核心思想在 SeaTunnel Engine 的分离集群模式下Master 服务与 Worker 服务被拆分为两个独立的进程各自承担不同的职责Master 节点只负责作业调度、RESTful API、任务提交等控制面工作IMap 数据作业运行状态、资源状态等集群元数据只存储在 Master 节点上。Worker 节点只负责任务的执行不参与 Master 选举也不存储 IMap 数据。在所有 Master 节点中同一时刻只有一个 Master 处于 Active工作状态其余 Master 处于 Standby备用状态。当当前 Active Master 发生故障或心跳超时时系统会从其他 Master 节点中选举出一个新的 Active Master。这是官方最推荐的部署方式。在这种模式下Master 的负载非常低可以将更多资源用于作业调度、任务容错指标监控以及 RESTful API 服务稳定性更高Worker 节点不存储 IMap 数据所有 IMap 数据都存放在 Master 节点上。即使某个 Worker 节点负载很高甚至宕机也不会触发 IMap 数据重分布从而避免故障扩散。二、最小部署配置与 HA 节点规划分离集群中每个角色都有最小数量和 HA 推荐数量见下表角色最小数量推荐数量HA职责说明Master12负责作业调度与 IMap 数据存储Worker12负责任务执行重要提示单个 Master 节点可以正常启动运行但不提供高可用保障。若要启用 HA必须部署至少 2 个 Master 节点。这是因为默认配置backup-count: 1要求至少 2 个 Master 节点才能放置 IMap 备份副本如果只有一个 Master该节点故障后集群将无法恢复。三、安装包下载与 SEATUNNEL_HOME 配置3.1 下载并制作安装包参照 下载并制作 SeaTunnel 安装包 完成安装包的下载与解压。核心步骤包括export version3.0.0 wget https://archive.apache.org/dist/seatunnel/${version}/apache-seatunnel-${version}-bin.tar.gz tar -xzvf apache-seatunnel-${version}-bin.tar.gz注意从 2.2.0-beta 版本起二进制包默认不再附带连接器依赖首次使用前需要执行sh bin/install-plugin.sh安装连接器并可通过修改config/plugin_config只安装所需插件详见 download-seatunnel.md。3.2 配置 SEATUNNEL_HOME 环境变量建议通过新建/etc/profile.d/seatunnel.sh文件来配置环境变量文件内容如下export SEATUNNEL_HOME${seatunnel install path} export PATH$PATH:$SEATUNNEL_HOME/bin从仓库中 seatunnel-cluster.sh 的源码可以看到脚本启动时会优先加载config/seatunnel-env.sh若环境变量SEATUNNEL_HOME未设置则自动以安装目录APP_DIR作为默认值见脚本中if [ -z ${SEATUNNEL_HOME:-} ]; then SEATUNNEL_HOME${APP_DIR}; fi并会将-Dseatunnel.home与-DSEATUNNEL_HOME写入 JVM 系统属性。四、Master 与 Worker 的 JVM 参数配置Master 节点的 JVM 参数在$SEATUNNEL_HOME/config/jvm_master_options文件中配置仓库中的对应文件为 config/jvm_master_options参考配置如下# JVM Heap -Xms16g -Xmx16g # JVM Dump -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmp/seatunnel/dump/zeta-server # Metaspace -XX:MaxMetaspaceSize2g # G1GC -XX:UseG1GCWorker 节点的 JVM 参数在$SEATUNNEL_HOME/config/jvm_worker_options文件中配置仓库中的对应文件为 config/jvm_worker_options参数项与 Master 一致# JVM Heap -Xms16g -Xmx16g # JVM Dump -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmp/seatunnel/dump/zeta-server # Metaspace -XX:MaxMetaspaceSize2g # G1GC -XX:UseG1GC以上示例使用 16 GB JVM 堆。对于大规模数据处理场景官方建议使用 32 GB JVM 堆。从启动脚本源码 seatunnel-cluster.sh 可以印证角色与配置文件的对应关系当NODE_ROLEmaster时脚本读取config/jvm_master_options并将日志文件命名为seatunnel-engine-master同时默认使用hazelcast-master.yaml当NODE_ROLEworker时读取config/jvm_worker_options日志文件命名为seatunnel-engine-worker默认使用hazelcast-worker.yaml。五、seatunnel.yaml 核心配置详解SeaTunnel Engine 的众多功能都在seatunnel.yaml中配置仓库对应文件为 config/seatunnel.yaml。在分离集群模式下不同配置项对 Master 与 Worker 的生效范围不同以下逐项说明。5.1 backup-countIMap 数据备份数Worker 节点不生效SeaTunnel Engine 基于 Hazelcast IMDG 实现集群管理。集群的状态数据作业运行状态、资源状态存储在 Hazelcast IMap 中。IMap 数据会分布式地存储在所有集群节点上Hazelcast 对 IMap 中的数据进行分区Partition每个分区都可以指定备份数量。因此SeaTunnel Engine不依赖 Zookeeper 等外部服务即可实现集群 HA。backup-count定义了同步备份的数量。例如设置为 1则分区的备份会放在另一个成员上设置为 2则备份放在另外两个成员上。官方推荐取值公式为max(1, min(5, N/2))其中N是 Master 节点的数量。seatunnel: engine: backup-count: 1 # other configurations分离集群注意事项由于 Worker 节点不存储 IMap 数据Worker 节点上的backup-count配置不生效。如果 Master 与 Worker 进程启动在同一台机器上它们会共享seatunnel.yaml配置文件此时 Worker 节点服务会忽略backup-count配置。5.2 slot-serviceSlot 数量配置Master 节点不生效Slot 数量决定了集群节点上可以并行运行的任务组数量。一个任务所需的 Slot 数公式为N 2 PP为任务配置的并行度。默认情况下 SeaTunnel Engine 的 Slot 数量是动态的即数量没有上限。动态 Slot 配置默认如下seatunnel: engine: slot-service: dynamic-slot: true # other configurations静态 Slot 配置如下seatunnel: engine: slot-service: dynamic-slot: false slot-num: 20官方建议将 Slot 数设置为节点 CPU 核数的两倍当dynamic-slot为false且未设置slot-num时该值是默认值。分离集群注意事项由于 Master 节点不运行任务Master 服务不会启动 Slot 服务Master 节点上的slot-service配置不生效。同机部署时Master 节点服务会忽略slot-service配置。5.3 checkpoint检查点管理器Worker 节点不生效与 Flink 类似SeaTunnel Engine 支持 Chandy–Lamport 算法可以实现无丢失、无重复的数据同步。interval两次检查点之间的间隔单位毫秒。如果作业配置文件的env中配置了checkpoint.interval参数则以作业配置文件中的设置为准。timeout检查点的超时时间。如果在超时时间内未能完成检查点将触发检查点失败并导致作业失败。同理若作业配置文件env中配置了checkpoint.timeout以作业配置为准。min-pause连续两个检查点之间的最小间隔毫秒用于避免检查点触发过于频繁。完整示例seatunnel: engine: backup-count: 1 print-execution-info-interval: 10 slot-service: dynamic-slot: true checkpoint: interval: 300000 timeout: 10000 min-pause: 5000checkpoint storage检查点存储检查点是一种容错恢复机制保证程序运行中即使突然遇到异常也能自行恢复。检查点被定时触发每次执行检查点时每个 Task 需要将自身状态信息例如读取 Kafka 时已读到的 offset上报给检查点线程由它写入分布式存储或共享存储。当任务失败自动容错恢复或通过seatunnel.sh -r指令恢复之前暂停的任务时会从检查点存储中加载对应作业的状态信息并据此恢复作业。关键约束如果集群节点数大于 1检查点存储必须是分布式存储或共享存储这样才能保证任意节点故障后其他节点仍能加载其中保存的任务状态信息。检查点存储的详细配置HDFS / OSS / COS / S3 / LocalFile 等可参考 checkpoint storage。仓库默认的 config/seatunnel.yaml 中使用的本地文件示例为checkpoint: interval: 10000 timeout: 60000 storage: type: hdfs max-retained: 3 plugin-config: namespace: /tmp/seatunnel/checkpoint_snapshot storage.type: hdfs fs.defaultFS: file:///tmp/ # Ensure that the directory has written permission分离集群注意事项checkpoint 配置只由 Master 服务读取Worker 服务不会读取。同机部署共享配置文件时Worker 节点服务会忽略checkpoint配置。5.4 历史作业过期配置每个已完成作业的信息状态、计数器、错误日志等都存储在 IMap 对象中。随着运行作业数量增加内存占用会不断增长最终可能导致内存溢出。可以通过调整history-job-expire-minutes参数解决该问题时间单位为分钟默认值为 1440 分钟即一天。seatunnel: engine: history-job-expire-minutes: 1440SeaTunnel 还会在删除前将终态作业状态在分布式 Map 中短暂保留该保留时间由state-cleanup-delay-ms控制默认值为60000毫秒。短时间保留终态墓碑tombstone可以允许迟到的异步回调观察到终态而不是看到缺失的 Map 条目设置为0会恢复更激进的清理策略但同时会收窄对终态竞争的保护窗口。seatunnel: engine: state-cleanup-delay-ms: 600005.5 类加载器缓存模式该配置主要解决因持续创建并尝试销毁类加载器导致的资源泄漏问题。如果遇到与 metaspace 空间溢出相关的异常可以尝试开启该配置。开启后为了降低类加载器的创建频率SeaTunnel 在作业完成时不会尝试释放对应的类加载器使其可被后续作业复用。也就是说当运行作业中使用的 Source/Sink 连接器种类不太多时该配置效果更明显。默认值为true。seatunnel: engine: classloader-cache-mode: true5.6 IMap 持久化配置Worker 节点不生效SeaTunnel 使用 IMap一种分布式 Map可在节点和进程间实现数据的读写详见 hazelcast map存储每个任务及其状态使得任务所在节点故障后其他节点可以获得任务之前的状态信息从而恢复任务、实现任务容错。默认情况下IMap 信息只存储在内存中。可以通过设置 IMap 数据的副本数参考 5.1 节的backup-count来增强可靠性副本数为 2 意味着每条数据同时存储在两个不同节点上一旦某个节点故障IMap 中的数据会在其他节点上自动补足到设置的副本数。但所有节点都停止时IMap 中的数据会丢失集群节点重新启动后所有之前运行的任务都会被标记为失败需要用户通过seatunnel.sh -r指令手动恢复。要解决该问题可以将 IMap 中的数据持久化到外部存储如 HDFS、OSS 等。这样即使所有节点都停止IMap 数据也不会丢失集群节点重启后之前运行的所有任务都会自动恢复。IMap 的 MapStore 持久化配置示例如下typeIMap 持久化类型。目前仅支持hdfs。namespace用于区分不同业务的数据存储位置例如 OSS bucket 名称。clusterName主要用于集群隔离可用于区分不同集群如 cluster1、cluster2也用于区分不同业务。fs.defaultFS使用 HDFS API 读写文件使用该存储必须提供 HDFS 配置。使用 HDFS 配置示例map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /tmp/seatunnel/imap clusterName: seatunnel-cluster storage.type: hdfs fs.defaultFS: hdfs://localhost:9000无 HDFS 且集群只有一个节点时可使用本地文件map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /tmp/seatunnel/imap clusterName: seatunnel-cluster storage.type: hdfs fs.defaultFS: file:///注意事项engine_runningJobMetrics存储的是高频率的运行时指标快照即使map.engine*配置了map-store它也会被有意排除在持久化 IMap 存储之外以避免仅用于可观测性的状态造成过度的 WAL 增长。引擎重启后运行中作业的指标会从后续上报中重建而不是沿用重启前的快照。使用 OSS 配置示例map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /tmp/seatunnel/imap clusterName: seatunnel-cluster storage.type: oss block.size: block size(bytes) oss.bucket: oss://bucket name/ fs.oss.accessKeyId: OSS access key id fs.oss.accessKeySecret: OSS access key secret fs.oss.endpoint: OSS endpoint使用 OSS 时请确保lib目录中存在以下 JAR版本号遵循${library.version}-${seatunnel.shade.version}格式如3.1.4-3.0.0请以发行包中的实际 JAR 文件名为准aliyun-sdk-oss-3.13.2.jar hadoop-aliyun-3.3.6.jar jdom2-2.0.6.jar netty-buffer-4.1.89.Final.jar netty-common-4.1.89.Final.jar seatunnel-shade-hadoop3-uber-${seatunnel.shade.hadoop.version}-${seatunnel.shade.version}.jar其中seatunnel-shade-hadoop3-uber来自 Apache SeaTunnel Shade 项目提供打包重定位的 Hadoop 客户端所有第三方类被重定位到org.apache.seatunnel.shade.*命名空间下以避免与 SeaTunnel 自身依赖产生类路径冲突。使用 S3兼容 Minio配置示例S3 配置遵循 Hadoop S3A 文件系统Native S3标准使用fs.s3a.access.key与fs.s3a.secret.key属性以兼容现有 Hadoop 生态map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /seatunnel/engine clusterName: seatunnel storage.type: s3 s3.bucket: s3a://your-bucket fs.defaultFS: s3a://your-bucket fs.s3a.endpoint: http://your-minio-endpoint:port fs.s3a.path.style.access: true fs.s3a.access.key: YOUR_ACCESS_KEY fs.s3a.secret.key: YOUR_SECRET_KEY fs.s3a.aws.credentials.provider: org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider使用 S3 时请确保lib目录中存在以下 JARseatunnel-shade-hadoop3-uber-${seatunnel.shade.hadoop.version}-${seatunnel.shade.version}.jar seatunnel-shade-hadoop-aws-${seatunnel.shade.hadoop-aws.version}-${seatunnel.shade.version}.jar分离集群注意事项由于只有 Master 节点存储 IMap 数据、Worker 节点不存储 IMap 数据因此 Worker 服务不会读取该参数项。5.7 作业调度策略当资源不足时作业调度策略支持两种模式WAIT等待资源可用REJECT拒绝作业默认值。seatunnel: engine: job-schedule-strategy: WAIT注意当使用dynamic-slot: true时job-schedule-strategy: WAIT配置会失效并被强制改为REJECT因为该参数在动态 Slot 场景下没有意义。5.8 Coordinator Service 配置CoordinatorService 负责将每个作业从 LogicalDag 生成 ExecutionDag、再生成 PhysicalDag 的过程最终为作业创建 JobMaster以处理调度、执行与状态监控。core-thread-numseatunnel coordinator job 执行器的 cached thread pool 的 corePoolSizemax-thread-num同一时间可以执行的最大作业数。coordinator-service: core-thread-num: 30 max-thread-num: 10005.9 job-metrics-partition-count作业指标分区数Worker 节点不生效配置项JOB_METRICS_PARTITION_COUNT控制 Hazelcast IMap 中存储运行中作业指标所使用的分区数默认值1单 key向后兼容用途增大该值可将指标分散到多个分区减少许多任务并发更新指标时的锁竞争。seatunnel: engine: job-metrics-partition-count: 4将指标分布到 4 个分区而不是使用单一 key。当任务数超过约 20,000 时增大分区数收益显著。作为实践参考分区数在 1,0002,000 左右往往能在减少锁竞争与降低开销之间取得最佳平衡建议从该范围起步再根据集群规模与工作负载特征调整。注意事项增大分区数在重度竞争下可提升并发能力但设置过高也会带来分布与合并的额外开销可能降低整体性能。分区数应在作业启动前配置作业启动后更改可能导致指标 key 不匹配因此修改该配置项后建议重启 SeaTunnel。六、SeaTunnel Engine 网络服务配置SeaTunnel Engine 的所有网络相关配置都在hazelcast-master.yaml与hazelcast-worker.yaml中仓库对应文件为 config/hazelcast-master.yaml 与 config/hazelcast-worker.yaml。6.1 cluster-nameSeaTunnel Engine 节点使用cluster-name判断另一节点是否与自己处于同一集群。如果两个节点的集群名不同SeaTunnel Engine 会拒绝服务请求。6.2 network基于 Hazelcast 的发现机制SeaTunnel Engine 集群是由运行 SeaTunnel Engine server 的集群成员组成的网络成员会自动加入并组成集群。请注意集群形成后成员之间的通信始终通过 TCP/IP与使用何种发现机制无关。SeaTunnel Engine 支持以下发现机制tcp-ip可以将 SeaTunnel Engine 配置为完整的 TCP/IP 集群配置细节参考 Discovering Members by TCP。在分离集群模式下Master 与 Worker 服务使用不同端口。Master 节点网络配置hazelcast-master.yamlhazelcast: cluster-name: seatunnel network: rest-api: enabled: true endpoint-groups: CLUSTER_WRITE: enabled: true DATA: enabled: true join: tcp-ip: enabled: true member-list: - master-node-1:5801 - master-node-2:5801 - worker-node-1:5802 - worker-node-2:5802 port: auto-increment: false port: 5801 properties: hazelcast.heartbeat.failuredetector.type: phi-accrual hazelcast.heartbeat.interval.seconds: 2 hazelcast.max.no.heartbeat.seconds: 180 hazelcast.heartbeat.phiaccrual.failuredetector.threshold: 10 hazelcast.heartbeat.phiaccrual.failuredetector.sample.size: 200 hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis: 100Worker 节点网络配置hazelcast-worker.yamlhazelcast: cluster-name: seatunnel network: join: tcp-ip: enabled: true member-list: - master-node-1:5801 - master-node-2:5801 - worker-node-1:5802 - worker-node-2:5802 port: auto-increment: false port: 5802 properties: hazelcast.heartbeat.failuredetector.type: phi-accrual hazelcast.heartbeat.interval.seconds: 2 hazelcast.max.no.heartbeat.seconds: 180 hazelcast.heartbeat.phiaccrual.failuredetector.threshold: 10 hazelcast.heartbeat.phiaccrual.failuredetector.sample.size: 200 hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis: 100TCP 是独立 SeaTunnel Engine 集群中官方推荐的方式。此外Hazelcast 还提供其他服务发现方法详见 hazelcast network。关键心跳参数说明两个配置文件通用参数说明hazelcast.heartbeat.failuredetector.type故障检测器类型phi-accrual为基于累积概率的故障检测hazelcast.heartbeat.interval.seconds心跳发送间隔秒hazelcast.max.no.heartbeat.seconds最大无心跳时间秒超过则判定节点故障hazelcast.heartbeat.phiaccrual.failuredetector.thresholdphi-accrual 故障检测器的 phi 阈值hazelcast.heartbeat.phiaccrual.failuredetector.sample.sizephi-accrual 采样的心跳样本数hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millisphi-accrual 心跳间隔的最小标准差毫秒七、启动 Master 节点通过-d参数以守护进程方式启动 Master 节点mkdir -p $SEATUNNEL_HOME/logs ./bin/seatunnel-cluster.sh -d -r master日志会写入$SEATUNNEL_HOME/logs/seatunnel-engine-master.log。对应地从 seatunnel-cluster.sh 源码可以看到-r master角色会加载jvm_master_options与hazelcast-master.yaml主类为org.apache.seatunnel.core.starter.seatunnel.SeaTunnelServerstdout 输出到logs/seatunnel-engine-master.out。八、启动 Worker 节点同样通过-d参数以守护进程方式启动 Worker 节点mkdir -p $SEATUNNEL_HOME/logs ./bin/seatunnel-cluster.sh -d -r worker日志会写入$SEATUNNEL_HOME/logs/seatunnel-engine-worker.log。启动脚本同时支持-r master_and_worker默认角色即混合集群模式与-cn指定集群名。如需查看集群成员信息可执行sh bin/seatunnel-cluster.sh -m -cn my_cluster输出包含 Member ID、Address、RoleACTIVE MASTER / MASTER / WORKER与 Hazelcast 版本。九、提交与管理任务9.1 使用 SeaTunnel Engine 客户端提交任务配置 SEATUNNEL_HOME客户端机器的SEATUNNEL_HOME需要与服务器保持一致同样通过/etc/profile.d/seatunnel.sh配置export SEATUNNEL_HOME${seatunnel install path} export PATH$PATH:$SEATUNNEL_HOME/bin配置 SeaTunnel Engine 客户端SeaTunnel Engine 客户端的全部配置都在hazelcast-client.yaml仓库对应文件为 config/hazelcast-client.yaml。cluster-name客户端必须与 SeaTunnel Engine 使用相同的cluster-name否则 SeaTunnel Engine 会拒绝客户端的请求。network需要在这里添加所有 SeaTunnel Engine Master 节点的地址。hazelcast-client: cluster-name: seatunnel properties: hazelcast.logging.type: log4j2 network: cluster-members: - master-node-1:5801 - master-node-2:5801仓库默认的 hazelcast-client.yaml 中还包含connection-strategy.connection-retry.cluster-connect-timeout-millis: 3000的客户端连接重试配置。提交与管理工作集群部署完成后可通过 Submitting And Managing Jobs 教程完成任务的提交与管理。常用命令速览# 查看客户端帮助 sh bin/seatunnel.sh -h # 提交作业默认集群模式 sh bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template # 异步提交提交后客户端立即退出 sh bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template --async # 指定作业名称 sh bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template --async -n myjob # 校验配置静态校验不提交作业 sh bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template --dry-run static # 列出所有作业 sh bin/seatunnel.sh -l # 查看指定作业状态 sh bin/seatunnel.sh -j jobId # 暂停作业需开启 checkpoint sh bin/seatunnel.sh -s jobId # 恢复作业需 jobId 与配置文件 sh bin/seatunnel.sh -r jobId -c $SEATUNNEL_HOME/config/v2.batch.config.template # 取消作业 sh bin/seatunnel.sh -can jobId1 [jobId2 jobId3 ...] # 强制取消作业 sh bin/seatunnel.sh -f jobId1 [jobId2 jobId3 ...]需要特别说明的是暂停/恢复作业仅支持开启了 checkpoint 的作业实时同步作业默认开启 checkpoint批处理作业默认不开启需要在作业配置的env中配置checkpoint.interval来启用。暂停以 split 为最小单位恢复后从暂停的 split 继续运行取消作业后其断点信息会被删除无法再通过-r恢复。9.2 使用 REST API 提交任务SeaTunnel Engine 提供了用于提交和管理任务的 REST API详细信息可参考 REST API V2。在使用 REST API 前需要在 Master 节点的hazelcast-master.yaml中开启 REST 端点即上文配置中的rest-api.enabled: true并启用CLUSTER_WRITE与DATA两个 endpoint group这也是分离集群 Master 配置文件与 Worker 配置文件的一个关键差异。十、分离集群部署自检清单完成部署后建议按以下清单逐项检查节点角色Master 节点进程是否使用-r master、Worker 节点是否使用-r worker启动集群名称hazelcast-master.yaml、hazelcast-worker.yaml、hazelcast-client.yaml三处的cluster-name是否一致端口规划Master 使用 5801、Worker 使用 5802或自定义端口且member-list中包含了全部 Master 与 Worker 节点的地址与端口HA 配置至少部署 2 个 Master 节点并确认backup-count满足max(1, min(5, N/2))检查点存储集群节点数大于 1 时确认 checkpoint storage 配置为共享/分布式存储IMap 持久化如需要全部节点停机后任务自动恢复配置map.engine*.map-store指向 HDFS/OSS/S3客户端连通性客户端hazelcast-client.yaml的cluster-members指向所有 Master 节点地址。按照以上步骤完成配置与启动后即可获得一套 Master 低负载、Worker 可水平扩展、支持故障自动切换与任务容错恢复的高可用 SeaTunnel Engine 分离集群。【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考