企业官网建设流程全解析

SeaTunnel 引擎 TCP/IP 集群成员发现配置详解

【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel

本文面向需要部署多节点 SeaTunnel Engine（Zeta）集群的开发者，系统讲解如何将基于 Hazelcast 的引擎从默认组播发现切换到 TCP/IP 全地址发现模式：从tcp-ip元素的enabled开关、member-list的多种成员写法（主机名、IP 段、端口显式指定）、逗号分隔的members简写形式，到默认端口的自动尝试规则，并结合本仓库的 hazelcast.yaml、hazelcast-master.yaml、hazelcast-worker.yaml、hazelcast-client.yaml 等真实配置给出可直接落地的完整示例。读完本文，你将掌握 TCP/IP 发现机制的原理、配置要点、跨节点成员列举技巧以及集群客户端（Client）的配套连接配置。

背景：为什么需要 TCP/IP 成员发现

SeaTunnel Engine 的集群管理基于 Hazelcast IMDG）。

Hazelcast 默认的成员发现方式是组播（Multicast）：节点在局域网内通过广播自动相互发现。这种方式在小型局域网中开箱即用，但在以下场景并不可靠或不可用：

• 网络环境禁用了组播/UDP 广播（如多数云厂商 VPC、容器网络）；
• 集群节点跨网段、跨机房部署，组播无法穿透；
• 安全策略要求显式声明集群成员范围，不允许任意节点自动入网。

当组播不是首选时，可以把 SeaTunnel Engine 配置成全 TCP/IP 集群：在配置中显式列出全部或部分成员的主机名和/或 IP 地址，节点之间通过这些地址建立 TCP 连接完成发现与组网。

TCP/IP 发现的核心配置元素

要完成配置，需要设置两个要素：

1. 将tcp-ip元素的enabled属性设为true；
2. 在tcp-ip元素内提供member-list成员列表。

关于 TCP/IP 发现配置元素的完整说明，可参见 Hazelcast 官方文档的tcp-ip元素章节。下面是一份声明式（YAML）配置示例：

hazelcast: network: join: tcp-ip: enabled: true member-list: - machine1 - machine2 - machine3:5799 - 192.168.1.0-7 - 192.168.1.21

成员条目的三种写法

member-list中的每个成员条目可以是：

其中192.168.1.0-7这种写法表示一个 IP 范围：它会被展开为192.168.1.0、192.168.1.1、…、192.168.1.7共 8 个地址，方便覆盖一个子网内连续的一段机器。

逗号分隔的 members 简写

除了逐行列出成员之外，也可以使用members元素，以逗号分隔的方式一次性写入所有地址，例如：

<members>192.168.1.0-7,192.168.1.21</members>

上述两种形式表达的是同样的成员集合，你可以根据配置的可读性偏好任选其一。

成员列表的完整性要求：至少一个活跃成员

使用 TCP/IP 发现时，你不必把所有集群成员都列全，但必须保证：当一个新成员加入集群时，member-list中列出的成员里至少有一个是当前活跃的（即已经在线并已加入集群）。

换句话说，成员列表的作用是给新节点提供"敲门砖"：新节点只要能够通过 TCP 联系到列表中任意一个在线节点，就可以从该节点处获知整个集群的完整成员信息并完成入网；如果列表中的所有节点都处于离线状态，新节点将无法组网。

未指定端口时的默认尝试规则

如果成员条目中未显式提供端口（例如直接写machine1或192.168.1.21），Hazelcast 会自动依次尝试端口5701、5702及后续端口，直到找到目标成员。

这一行为与端口配置中的auto-increment机制相互配合：Hazelcast 允许成员在配置端口不可用时自动递增端口号寻找可用端口。因此，建议在生产配置中显式声明端口（如hostname:5801），或通过port元素的port+auto-increment明确控制，以避免依赖默认 5701 端口带来的不确定性。

仓库中的真实配置对照

当前仓库自带的 hazelcast.yaml 已经默认采用 TCP/IP 发现模式（非组播），可以作为参考基线：

hazelcast: cluster-name: seatunnel network: rest-api: enabled: false endpoint-groups: CLUSTER_WRITE: enabled: true DATA: enabled: true join: tcp-ip: enabled: true member-list: - localhost port: auto-increment: false port: 5801 properties: hazelcast.invocation.max.retry.count: 20 hazelcast.tcp.join.port.try.count: 30 hazelcast.logging.type: log4j2 hazelcast.operation.generic.thread.count: 50 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: 100

对照上文要点，可以观察到几个值得注意的细节：

• join.tcp-ip.enabled: true显式开启了 TCP/IP 发现，取代默认的组播；
• member-list中只列了一个成员localhost，这满足"至少一个活跃成员"的最小要求，适用于单机测试或本机联调；
• port.auto-increment: false且port: 5801，固定了节点服务端口，配合hazelcast.tcp.join.port.try.count: 30（TCP 加入时尝试端口的最大次数）可以精确控制节点的监听与连接行为；
• 引擎实际使用的集群端口由仓库默认设为5801（而非 Hazelcast 默认的5701），因此在书写member-list时建议显式携带端口。

多节点场景：master / worker 分离部署的成员列举

对于采用主从分离部署的集群，仓库提供了两套独立配置：hazelcast-master.yaml（Master 节点监听 5801）与 hazelcast-worker.yaml（Worker 节点监听 5802）。其中 Master 的member-list同时列出了两个节点：

hazelcast: cluster-name: seatunnel network: join: tcp-ip: enabled: true member-list: - localhost:5801 - localhost:5802 port: auto-increment: false port: 5801

这正是 TCP/IP 发现的典型多节点写法：把集群中所有（或至少一个活跃）节点的地址以"主机名/IP:端口"的形式逐一列出。在实际生产环境（如 分离集群部署指南）中，只需把localhost替换为各节点的真实主机名或 IP 即可。

集群客户端（Client）的连接配置

TCP/IP 发现只解决服务端节点之间的相互发现。当使用 SeaTunnel Engine 客户端（如seatunnel.sh提交任务）时，还需要在 hazelcast-client.yaml 中配置cluster-members，把集群中所有服务端节点的地址列出来：

hazelcast-client: cluster-name: seatunnel properties: hazelcast.logging.type: log4j2 connection-strategy: connection-retry: cluster-connect-timeout-millis: 3000 network: cluster-members: - localhost:5801

客户端配置的要点（详见 hybrid-cluster-deployment.md 第 6 节）：

• cluster-name必须与服务端一致，否则引擎会拒绝客户端的请求；
• cluster-members需要添加所有 SeaTunnel Engine 服务端节点的地址；
• cluster-connect-timeout-millis控制客户端连接集群的重试超时，集群未就绪时（如所有节点刚重启）可以适当调大。

TCP/IP 发现与其它发现机制的取舍

从仓库文档 hybrid-cluster-deployment.md 第 5.2 节可以看到：无论使用哪种发现机制完成组网，集群一旦形成，成员之间的通信始终通过 TCP/IP 进行——发现机制只决定"如何找到彼此"。

在可用机制中：

• TCP/IP：需要手工维护成员列表，但可控性强、无组播依赖，是仓库明确推荐的独立 SeaTunnel Engine 集群方式（"TCP is the recommended method for use in a standalone SeaTunnel Engine cluster"）；
• Kubernetes：仓库的 Helm 部署模板（deploy/kubernetes/seatunnel/conf/hazelcast-master.yaml）在容器环境中默认使用join.kubernetes的service-dns发现机制，这是另一种不依赖组播的云原生方案；
• Multicast：仅适用于组播可达的局域网，跨网段、跨云环境下不可用。

如果你需要在不同网段或云环境中组网，TCP/IP 是优先选择；在 Kubernetes 环境内则可以直接使用 Helm 模板自带的 DNS 发现。

完整实践步骤

结合上述原理与仓库配置，将多节点 SeaTunnel Engine 切换为 TCP/IP 集群的完整步骤如下：

1. 确定集群端口：默认建议使用仓库约定端口5801（可修改port.port），并保持auto-increment: false以固定端口；若需保留自动递增，注意成员未显式端口时 Hazelcast 会从 5701 起自动尝试；
2. 编辑每台节点的 hazelcast.yaml：将network.join下启用tcp-ip，在member-list中列出所有节点的真实主机名或 IP（建议携带端口），保证至少一个条目指向活跃节点；
3. 确保各节点cluster-name一致：引擎节点通过cluster-name判断对方是否属于同一集群，名称不一致会被拒绝服务请求；
4. 配置客户端 hazelcast-client.yaml：在cluster-members中列出全部服务端节点地址，保持cluster-name与服务端一致；
5. 逐个启动节点：使用./bin/seatunnel-cluster.sh -d启动（日志写入$SEATUNNEL_HOME/logs/seatunnel-engine-server.log），后启动的节点会通过member-list中的活跃成员加入集群；
6. 验证组网：通过引擎日志确认节点加入事件，或使用 REST API / Web UI 观察集群成员列表。

小结

TCP/IP 成员发现是 SeaTunnel Engine 在多网段、云环境等组播不可用场景下最稳妥的组网方式。核心要点可归纳为：tcp-ip.enabled: true开启发现、member-list中至少保留一个活跃成员、条目支持主机名/IP/IP 段/显式端口四种写法、未写端口时按 5701 起自动尝试、集群形成后成员间一律走 TCP 通信。结合仓库自带 hazelcast.yaml、hazelcast-master.yaml、hazelcast-worker.yaml 与 hazelcast-client.yaml 四份配置，即可快速搭建出稳定可控的多节点集群。

【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel