后端并发编程异步编程【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址https://gitcode.com/gh_mirrors/ak/akka-core点击查看免费下载Akka Cluster 的核心是集群成员服务Cluster Membership Service它负责跟踪集群中有哪些节点、各节点处于什么状态以及它们是否健康并且完全不依赖任何外部基础设施如 ZooKeeper 或 etcd仅通过 gossip 协议与故障检测器即可让所有节点对集群构成达成一致。本文以官方文档 cluster-membership.md 为主体结合 akka-cluster 模块的真实源码Cluster.scala、Member.scala、ClusterDaemon.scala与默认配置reference.conf带你完整掌握成员状态机、加入/离开/下线全流程、Leader 职责、WeaklyUp 机制与全集群关闭等关键能力可直接用于生产集群的运维排障与架构设计。集群成员服务概述集群成员服务要解决的核心问题是始终准确知道集群由哪些节点组成、每个节点的健康状况如何。它的两大通信支柱是gossip 协议集群状态通过 gossip 在所有节点间传播最终收敛到一致视图详见 cluster-concepts.md 中的 Gossip故障检测器failure detector自动探测节点是否存活详见 cluster-concepts.md 中的 Failure Detector。在成员服务之上Akka 还构建了一批更高层级的集群工具Cluster Sharding、Cluster Singleton、Cluster-aware Routers 等参见 Higher level Cluster tools。理解成员服务是理解这些上层能力的前提。节点标识hostname:port:uid集群中每个节点的唯一标识是一个三元组hostname:port:uid对应源码中的 UniqueAddressfinal class UniqueAddress(val address: Address, val longUid: Long) extends Product with Serializable with Ordered[UniqueAddress]其中hostname:port用于定位节点而UID 唯一标识该地址上的这一次 ActorSystem 实例。UID 的存在让 Akka 可以可靠地触发远程 death watch远程死亡监视因为即便旧实例已经消亡只要有新的 UID系统就能区分“同一个地址上的新旧两个实例”。由此引出一个重要约束同一个 ActorSystem 一旦被移出集群就永远无法再次加入该集群。如果希望让同一个hostname:port重新加入集群必须停止原 ActorSystem 并启动一个新的实例——新实例会获得一个不同的 UID。从源码 Member.scala 还可以看到Member对象除了uniqueAddress之外还携带status当前状态、roles角色集合和appVersion应用版本hashCode/equals仅基于uniqueAddress计算与状态无关。成员状态Member States集群成员状态是一种专门化的 CRDT冲突无关复制数据类型这意味着它拥有单调的合并函数当不同节点上发生并发变更时更新总能被合并并收敛到相同的最终结果——这是集群在分区、并发下仍能最终一致的根本保证。Akka 定义了以下成员状态状态含义joining加入集群时的瞬时状态weakly up网络分裂期间的瞬时状态仅在akka.cluster.allow-weakly-up-memberson时出现默认开启up正常运行状态preparing for shutdown / ready for shutdown全集群关闭前可选进入的过渡状态leaving / exiting优雅移除过程中的状态down被标记为下线不再参与集群决策removed墓碑状态不再是成员这些状态在源码 Member.scala 中被定义为MemberStatus枚举且显式声明了允许的状态转换表allowedTransitionsJoining - Set(WeaklyUp, Up, Leaving, Down, Removed) WeaklyUp - Set(Up, Leaving, Down, Removed) Up - Set(Leaving, Down, Removed, PreparingForShutdown) Leaving - Set(Exiting, Down, Removed) Down - Set(Removed) Exiting - Set(Removed, Down) PreparingForShutdown - Set(ReadyForShutdown, Removed, Leaving, Down) ReadyForShutdown - Set(Removed, Leaving, Down) Removed - Set.empty任何不在该表中的转换例如Up直接跳到Removed都会被Member.copy(status)中的require检查拦截并抛出IllegalArgumentException——状态机在源码层面被强制约束。注意MemberStatus还提供了 Java API 辅助方法joining、up、leaving、down、removed等方便 Java 侧使用。成员事件Member Events通过订阅集群事件流应用可以跟踪成员的完整生命周期。所有事件都实现了ClusterEvent.MemberEvent接口见 ClusterEvent.scala核心事件如下事件触发时机ClusterEvent.MemberJoined新成员加入集群状态变为JoiningClusterEvent.MemberUp新成员状态变为Up已正式成为集群成员ClusterEvent.MemberExited成员正在离开集群状态变为Exiting。注意该事件在其它节点发布时原节点可能已经关闭ClusterEvent.MemberRemoved成员被彻底移出集群携带previousStatus指明此前是Down还是ExitingClusterEvent.UnreachableMember至少一个其它节点的故障检测器判定该成员不可达ClusterEvent.ReachableMember所有此前判定其不可达的节点都重新检测到其可达ClusterEvent.MemberPreparingForShutdown成员正在为全集群关闭做准备ClusterEvent.MemberReadyForShutdown成员已就绪可执行全集群关闭此外还有MemberWeaklyUp、MemberLeft、MemberDowned等事件以及用于感知集群领导变化的LeaderChanged、RoleLeaderChanged。订阅方式为通过Cluster(system).subscribe(subscriber, to: Class[_]*)注册监听见 Cluster.scala可以只订阅关心的若干事件类型。成员生命周期Membership Lifecycle加入集群join→joining→up节点通过join动作被引入集群进入joining状态。调用的是Cluster(system).join(address)见 Cluster.scala其实现向集群核心发送ClusterUserAction.JoinTo消息。也可以通过配置文件中的akka.cluster.seed-nodes在启动时自动加入或者调用joinSeedNodes(...)动态指定种子节点。在所有节点都通过 gossip 看到新节点处于joining即达到gossip 收敛之后由 leader 将成员状态提升为up。从 ClusterDaemon.scala 的源码可以看到joining → up的迁移还受最小成员数约束val enoughMembers: Boolean isMinNrOfMembersFulfilled def isJoiningToUp(m: Member): Boolean (m.status Joining || m.status WeaklyUp) enoughMembersisMinNrOfMembersFulfilled检查全局akka.cluster.min-nr-of-members默认 1以及各角色role.min-nr-of-members是否满足两者都在 reference.conf 中可配置。该特性通常与Cluster(system).registerOnMemberUp { ... }搭配使用将某些动作如启动业务 Actor延迟到集群达到指定规模后再执行见 Cluster.scala。优雅离开leave→leaving→exiting→removed当节点以安全、预期的方式离开集群例如通过 协调关闭 coordinated shutdown 触发时调用leave动作使其进入leaving状态。Leader 在看到该节点处于leaving状态的收敛后将其推进到exiting当所有节点都看到exiting状态再次收敛后Leader 将该节点移出集群并标记为removed。Cluster(system).leave(address)的实现是发送ClusterUserAction.Leave消息见 Cluster.scala。值得注意的细节leave命令可以向集群中任意成员发起不一定是离开者本人且离开者的集群扩展非整个 ActorSystem/JVM会在 Leader 将其置为Exiting后关闭。若该过程中出现网络故障导致流程卡住仍可能需要手动down才能完成移除。不可达unreachable时的处理当节点被故障检测器判为unreachable时gossip 收敛无法达成因此大多数 Leader 动作都无法执行例如无法让新节点加入集群。要向前推进节点必须重新变为reachable或者被显式地down掉。原因在于不可达节点的状态未知集群无法判断它究竟是崩溃了还是仅仅因为网络问题或 GC 停顿而暂时失联。下线的具体方式见下文「用户动作」一节。崩溃后无法重入与「同地址自动恢复」特例被exiting或down的节点其 ActorSystem不能再次加入集群。特别是节点在不可达期间被down之后又恢复网络连通也不能重新加入——此时必须重启该节点上的进程创建全新的 ActorSystem 重新走一遍加入流程。一个特例节点未经 leave/down 流程就重启了例如宿主机意外重启。新实例以相同hostname:port尝试重新加入时集群可能仍把旧实例记为unreachable。但由于新实例地址host 和 port与旧实例相同集群可以明确判定旧实例已经消失因此会自动将旧实例标记为down新实例无需人工干预即可重新加入。这正是 UID 设计带来的工程红利。Leader 的角色leader的职责是在达成收敛后确认状态变更。只要 gossip 收敛每个节点都能无歧义地确定谁是 leader——任何节点都可能根据当前集群构成被推举为 leader它只是一个角色而非固定节点。相关概念见 cluster-concepts.md 中的 Leader。收敛是绝大多数状态变更的前提没有收敛时不同节点可能对“谁是 leader”有不同看法。因此大多数常规变更如joining → up必须等待收敛确保所有节点对当前状态一致且变更只由一个节点发起。源码 ClusterDaemon.scala 中leaderActions()首先检查membershipState.convergence(...)仅在收敛时才执行leaderActionsOnConvergence()。少数动作允许在无收敛时执行当存在不可达节点时集群可能被分区脑裂场景每个分区对“哪些节点可达”各有自己的视图各分区内的节点都可能自视为本侧可达节点的 leader。这类情况下 leader 执行的任何动作都必须设计为“所有并发 leader 都会得出相同结论”。最重要的例子就是脑裂时对节点的 down 操作手动或自动以恢复收敛——这正是内置的 Split Brain Resolver 所实现的内容。另一个无需收敛即可执行的转换是WeaklyUp标记见下节。从 ClusterDaemon.scala 的注释可以完整看到 leader 在收敛时的动作清单JOINING → UP、LEAVING → EXITING、移除不可达的EXITING、移除不可达的DOWN/EXITING、更新 vclock 版本与 seen 表等。WeaklyUp 成员如上一节所述只要存在unreachable节点gossip 收敛就不可能达成大多数 leader 动作无法执行。通过开启akka.cluster.allow-weakly-up-members默认开启详见下文默认值说明加入中的节点即使在收敛尚未达成时也可以被提升为WeaklyUp一旦恢复收敛leader 会将WeaklyUp成员提升为Up。配置项在 reference.conf 中的真实定义是# If this is set to off, the leader will not move Joining members to Up during a network # split. This feature allows the leader to accept Joining members to be WeaklyUp # so they become part of the cluster even during a network split. The leader will # move Joining members to WeaklyUp after this configured duration without convergence. # The leader will move WeaklyUp members to Up status once convergence has been reached. allow-weakly-up-members 7s也就是说默认值7s表示“启用且加入节点在 7 秒内无法达成收敛时被提升为WeaklyUp”设置为off则完全禁用该特性。对应的源码实现位于 ClusterDaemon.scalaleader 在未收敛时累计leaderActionCounter当LeaderActionsInterval * leaderActionCounter WeaklyUpAfter即达到7s且未在全集群关闭流程中!preparingForShutdown时调用moveJoiningToWeaklyUp()而leaderActionsOnConvergence()中的isJoiningToUp会把Joining或WeaklyUp统一提升为Up见 ClusterDaemon.scala。你可以订阅WeaklyUp成员事件来利用这一状态下的成员但必须清醒认识到网络分区另一侧的成员对“新成员的存在”一无所知。因此例如在 quorum 决策中不应统计WeaklyUp成员否则可能做出基于不完整视图的错误判断。相关测试可在 SplitBrainResolverSpec.scala 中找到对WeaklyUp场景的覆盖验证。全集群关闭Full Cluster Shutdown某些罕见场景下全集群关闭比滚动升级更合适——例如协议变更导致向后兼容代价过高时直接重启整个集群反而更简单。自 Akka2.6.13起可以发出信号告知集群“即将发生全集群关闭”从而抑制昂贵的动作Cluster Sharding 的 rebalance分片再平衡Cluster Singleton 的迁移。这样关闭过程会尽可能快新版本可以无延迟地启动。如果集群关闭后不打算立即重启则无需做关闭前的准备。使用方式两种 API 均可用Classic APICluster(system).prepareForFullClusterShutdown()其实现向集群核心发送ClusterUserAction.PrepareForShutdown见 Cluster.scalaTyped API发送PrepareForFullClusterShutdown命令定义于 akka-cluster-typed 的 Cluster.scala由AdaptedClusterImpl转发到 classic 实现。随后等待所有Up成员变为ReadyForShutdown再统一关闭并重启所有节点。行为细节尚未Up的成员Joining或WeaklyUp将保持在原状态已经在离开流程中Leaving或Exiting的节点会继续沿正常路径退出。源码侧ClusterDaemon.scala 的checkForPrepareForShutdown()会在检测到集群进入关闭准备状态时向自身转发PrepareForShutdown同时leaderActionsOnConvergence中!preparingForShutdown的检查保证了准备关闭期间不再把新成员提升为Up见 ClusterDaemon.scala。成员状态图与状态转换规则官方文档给出了完整的成员状态转换图可直观理解各状态之间的迁移路径用户动作User Actions节点/管理员可以发起三类用户动作动作说明join将单个节点加入集群。可以是显式调用也可以在启动时通过配置指定要加入的节点而自动执行leave通知节点优雅地离开集群。通常由 ActorSystem 或 JVM 关闭通过 协调关闭 触发down将节点标记为下线。这是移除崩溃节点未执行leave所必需的。可由人工触发也可通过 Cluster HTTP Managementakka-management触发或由 downing provider如 Split Brain Resolver自动触发Leader 动作Leader Actionsleader负责确认用户动作、推动成员进出集群完整的转换规则为joining ⭢ upjoining ⭢ weakly up该动作无需收敛即使存在不可达节点也可执行weakly up ⭢ up需重新达到完全收敛后leaving ⭢ exitingexiting ⭢ removeddown ⭢ removed失败检测与不可达Failure Detection and Unreachability需要特别澄清的是unreachable并不是一个独立的成员状态而是叠加在既有状态之上的一个标记flag。集群中每个监控某节点的故障检测器都可以独立地将其标记为不可达随后故障检测器会持续监控直到重新检测到其可达并移除该标记。一个节点只有在所有监控节点都重新看到它可达之后才被整体视为reachable。故障检测器本身的参数心跳间隔、阈值、可容忍暂停等都在 reference.conf 的akka.cluster.failure-detector一节中配置默认实现为PhiAccrualFailureDetector基于 Phi 累积故障检测算法。总结集群成员服务是 Akka Cluster 的基石它以hostname:port:uid唯一标识节点以 CRDT 化的成员状态保证最终一致通过joining → up、leaving → exiting → removed、down → removed等受源码级状态机约束的转换驱动完整生命周期并由 leader 在 gossip 收敛后统一确认变更。面对不可达与脑裂WeaklyUp与 Split Brain Resolver 提供了在无法收敛时继续推进或恢复一致性的手段prepareForFullClusterShutdown则为全集群快速重启提供了显式协议支持。理解这些状态、事件与动作是正确运维 Akka Cluster、排查节点反复加入失败、以及设计高可用集群方案的基础。延伸阅读Gossip 与收敛机制、协调关闭、Split Brain Resolver、Akka Cluster 总览。赞分享后端并发编程异步编程【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址https://gitcode.com/gh_mirrors/ak/akka-core点击查看免费下载相关推荐Akka-Core Cluster 集群入门指南完整解析成员管理、Gossip 协议与故障检测Akka Core Cluster 集群入门指南完整解析成员管理、Gossip 协议与故障检测 Akka Core 的 Cluster 模块是 Akka 分布后端并发编程异步编程hello-uniapp开发资源汇总从学习到生产的必备工具hello uniapp开发资源汇总从学习到生产的必备工具 如果你正在寻找一个完整的 uni app开发资源集合 来加速你的跨平台应用开发进程那么hello示例工程前端opencode-anthropic-auth安全分析Token与refresh_token存储在哪里opencode anthropic auth安全分析Token与refresh_token存储在哪里 如果你正在使用 opencode anthropic上一篇openeuler/prefetch_tuning常见问题解答编译错误、参数失效与系统兼容性解决方案下一篇DiffSynth-Engine开发者手册API参考与自定义插件开发完整教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考