SeaTunnel 引擎 TCP/IP 集群成员发现配置详解【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel本文面向需要部署多节点 SeaTunnel EngineZeta集群的开发者系统讲解如何将基于 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 发现的核心配置元素要完成配置需要设置两个要素将tcp-ip元素的enabled属性设为true在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中的每个成员条目可以是写法示例说明主机名machine1、machine2节点的主机名由 DNS 或/etc/hosts解析主机名 端口machine3:5799显式指定该成员的服务端口IP 地址192.168.1.21节点的 IPv4 地址IP 地址段192.168.1.0-7展开为192.168.1.0到192.168.1.7共 8 个地址其中192.168.1.0-7这种写法表示一个 IP 范围它会被展开为192.168.1.0、192.168.1.1、…、192.168.1.7共 8 个地址方便覆盖一个子网内连续的一段机器。逗号分隔的 members 简写除了逐行列出成员之外也可以使用members元素以逗号分隔的方式一次性写入所有地址例如members192.168.1.0-7,192.168.1.21/members上述两种形式表达的是同样的成员集合你可以根据配置的可读性偏好任选其一。成员列表的完整性要求至少一个活跃成员使用 TCP/IP 发现时你不必把所有集群成员都列全但必须保证当一个新成员加入集群时member-list中列出的成员里至少有一个是当前活跃的即已经在线并已加入集群。换句话说成员列表的作用是给新节点提供敲门砖新节点只要能够通过 TCP 联系到列表中任意一个在线节点就可以从该节点处获知整个集群的完整成员信息并完成入网如果列表中的所有节点都处于离线状态新节点将无法组网。未指定端口时的默认尝试规则如果成员条目中未显式提供端口例如直接写machine1或192.168.1.21Hazelcast 会自动依次尝试端口5701、5702及后续端口直到找到目标成员。这一行为与端口配置中的auto-increment机制相互配合Hazelcast 允许成员在配置端口不可用时自动递增端口号寻找可用端口。因此建议在生产配置中显式声明端口如hostname:5801或通过port元素的portauto-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: 30TCP 加入时尝试端口的最大次数可以精确控制节点的监听与连接行为引擎实际使用的集群端口由仓库默认设为5801而非 Hazelcast 默认的5701因此在书写member-list时建议显式携带端口。多节点场景master / worker 分离部署的成员列举对于采用主从分离部署的集群仓库提供了两套独立配置hazelcast-master.yamlMaster 节点监听 5801与 hazelcast-worker.yamlWorker 节点监听 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 clusterKubernetes仓库的 Helm 部署模板deploy/kubernetes/seatunnel/conf/hazelcast-master.yaml在容器环境中默认使用join.kubernetes的service-dns发现机制这是另一种不依赖组播的云原生方案Multicast仅适用于组播可达的局域网跨网段、跨云环境下不可用。如果你需要在不同网段或云环境中组网TCP/IP 是优先选择在 Kubernetes 环境内则可以直接使用 Helm 模板自带的 DNS 发现。完整实践步骤结合上述原理与仓库配置将多节点 SeaTunnel Engine 切换为 TCP/IP 集群的完整步骤如下确定集群端口默认建议使用仓库约定端口5801可修改port.port并保持auto-increment: false以固定端口若需保留自动递增注意成员未显式端口时 Hazelcast 会从 5701 起自动尝试编辑每台节点的 hazelcast.yaml将network.join下启用tcp-ip在member-list中列出所有节点的真实主机名或 IP建议携带端口保证至少一个条目指向活跃节点确保各节点cluster-name一致引擎节点通过cluster-name判断对方是否属于同一集群名称不一致会被拒绝服务请求配置客户端 hazelcast-client.yaml在cluster-members中列出全部服务端节点地址保持cluster-name与服务端一致逐个启动节点使用./bin/seatunnel-cluster.sh -d启动日志写入$SEATUNNEL_HOME/logs/seatunnel-engine-server.log后启动的节点会通过member-list中的活跃成员加入集群验证组网通过引擎日志确认节点加入事件或使用 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考