应用节点停止时，保持 Semaphore 可用
将活动的 Semaphore 节点放在同一个服务地址之后。通过共享数据库和 Redis 协调，在应用节点维护期间保持 UI 与 API 可访问。
基础设施依赖随时可用的自动化
事故期间，团队需要通过 Semaphore 执行恢复作业和基础设施变更。单个应用节点不可用，不应导致团队失去这项访问能力。
一个应用节点离线
打开 UI
使用 API
启动作业
通过 Enterprise 高可用性保持 Semaphore 可用
当一个节点停止时，Enterprise 高可用性可通过健康的应用节点继续提供 UI 和 API。
另一个应用节点继续提供服务
打开 UI
使用 API
启动作业
Semaphore 高可用部署需要什么
01
两个或更多 Semaphore 节点
至少运行两个等价的 Semaphore 实例，保持共享配置一致，并为每个节点设置唯一的 ha.node_id.
02
HTTP 与 WebSocket 负载均衡
通过负载均衡器路由 HTTP 和 WebSocket 连接，使其可以将不健康的节点移出节点池。
03
共享 SQL 数据库与 Redis
将各节点连接到同一个 PostgreSQL 或 MySQL 数据库，以及 Redis 后端。这些共享服务本身也需要防故障保护。高可用部署不支持 SQLite。
规划生产部署的其他部分
为团队提供所需权限
访问控制规划整个部署的可用性
在架构中明确共享状态
文档中的拓扑是双活架构：等价的 Semaphore 节点使用同一个共享 PostgreSQL 或 MySQL 数据库，并通过 Redis 协调。数据库保存应用状态，Redis 支持分布式锁、队列状态和节点间更新。该高可用设计不支持 SQLite 或 BoltDB 作为数据库。
同时支持请求与实时更新
负载均衡器必须处理 HTTP 和 WebSocket 流量，使客户端能够访问健康应用节点并接收实时更新。其自身冗余、TLS 配置、健康检查及运行行为属于部署的一部分，添加应用节点不会自动配置这些属性。
分别扩展应用与执行路径
应用节点提供 Web、API 和协调层。运行器可独立部署和扩展任务执行。这能帮助团队判断容量变化是为了应对用户或 API 负载、任务并发，还是另一个网络的访问需求，而不是假定每增加一个应用节点就能同时解决这三类问题。
为各个故障域制定独立的恢复计划
应用节点可用性、数据库恢复、Redis 可用性及站点级灾难恢复是不同的责任。备份、恢复测试、恢复目标，以及与版本兼容的升级流程仍然不可缺少。一种拓扑可能容忍某类故障，却仍易受另一类故障影响。
通过 Redis Sentinel 保持协调服务可用
当协调服务也需要故障转移时，使用 Redis Sentinel 后端。每个 Semaphore 节点通过 Sentinel 发现活动 Redis 主节点，并跟随被提升的副本，无需重启。请为各应用节点配置相同的 Sentinel 部署，并将共享数据库和负载均衡器一并纳入可用性计划。
将共享依赖纳入可用性计划
SQL 数据库、Redis 和负载均衡器服务于所有应用节点。配置 Semaphore 节点的同时，也应为这些服务设置冗余与恢复。
为数据保留恢复途径
应用冗余与数据恢复解决不同的问题。请为自动化所依赖的数据库和配置维护备份，并测试恢复流程。
文档与相关功能
FAQ
Semaphore 高可用部署需要哪些组件？
文档中的双活架构采用多个 Semaphore 应用节点、共享 PostgreSQL 或 MySQL 数据库、Redis 协调，以及支持 HTTP 和 WebSocket 流量的负载均衡器。每个节点需要适当的共享设置和唯一 HA 标识符。应与应用节点一起规划这些依赖的可用性。仅有第二个进程，并不能提供完整拓扑所需的共享状态和协调。
Semaphore 高可用性是双活还是主备？
此处描述的是双活架构，由等价的应用节点共同参与服务，不依赖专门的主应用节点和被动备用节点。请依照当前高可用指南配置受支持的设计，不要仅根据泛泛的可用性描述推断另有主备参考架构。如果基础设施需要不同拓扑，应在部署之前解决其状态和故障转移行为。
高可用部署可以使用 SQLite 或 BoltDB 吗？
不可以。文档所述的高可用设计需要共享 PostgreSQL 或 MySQL 数据库，并结合 Redis。该数据库是各参与节点共享的应用状态来源。如果从使用其他存储的单节点配置迁移，应将迁移、备份和验证作为独立工作。不能等到增加应用节点时，才第一次测试目标共享数据库是否包含并能提供所需数据。
应用高可用性也会保护数据库、Redis 和负载均衡器吗？
这些组件需要各自的韧性策略。Semaphore 多节点应用设计不会自动创建数据库故障转移、冗余负载均衡或可用的 Redis 服务。请识别各依赖的故障域、恢复流程和容量要求。测试从客户端请求到任务结果的完整路径，让可用性计划覆盖用户实际使用的服务，而不只是运行中的应用节点数量。
应用节点故障或升级时，正在执行的任务会继续吗？
不要仅因存在多个应用节点，就假定正在执行的任务不会中断。实际行为取决于执行路径、发生故障的组件，以及所使用的版本。请测试您依赖的任务生命周期，包括状态报告和运行器参与情况。同样，应有计划地处理升级兼容性和迁移，不要将每次版本变更都视为保证零停机的滚动操作。UI 可用性与任务连续性是不同的要求。
哪个方案包含高可用性，应如何评估？
高可用性是 Enterprise 功能。首先明确所需运行时段、维护流程、恢复目标，以及现有数据库与负载均衡服务。使用文档中的拓扑找出缺口，再在具有代表性的环境中测试节点下线、依赖恢复和备份。如果这些要求对业务至关重要，讨论架构会很有帮助，因为决定结果的是完整部署，而不是单个功能开关。
应用节点下线时，用户能继续使用相同 URL 吗？
这正是将活动应用节点放在同一个负载均衡服务地址之后的目的。负载均衡器必须停止向不可用节点发送请求，并支持 HTTP 和 WebSocket 流量。存活节点仍需访问共享数据库、Redis 和一致的应用配置，才能提供项目服务。
在多个私有网络中执行任务需要高可用性吗？
不需要。多个执行位置由运行器处理。高可用性关注 Semaphore 应用层，运行器则关注任务的执行位置以及能访问的系统。生产部署可同时使用二者：以 HA 应用节点提供共享 UI 和 API，并在私有基础设施附近部署项目运行器。