冲绳加一台就能算双活吗：海岛节点的冗余要按海缆、上岸站和回程三层来算

客户要求「冲绳再放一台做双活」，这个诉求本身要先拆开

方案评审会上客户提了一个听起来很合理的要求：九州机房已经有一组机器跑着，现在再在冲绳加一台，两边一起对外服务，是不是就算双活了？预算审批表上写的是「第二节点建设」，机房数量从一变成二，可用性的期望值直接翻一倍。

问题在于，双活从来不是按机房数量定义的。双活要满足的是两个条件：任意一个节点整体失效时，另一个能接住全部流量；两侧都能接受写入，且写入不会互相覆盖。这两条里没有一条跟「有几间机房」直接相关，它们取决于两台机器之间的那条物理通路，以及这条通路断掉之后，你手上到底还有什么。

所以这个诉求要被拆成三个可验证的问题：冲绳与九州之间现在走的是什么物理路由；这条路由中断时，冲绳那台机器还能不能拿到完整的写入流；切换动作是运营商侧已经配好的转发策略，还是只能靠改 DNS 等缓存过期。三个问题里只要有一个答不上来，第二台机器的定位就得从「灾备节点」退回到「本地加速节点」，预算也该按后者来审。

冲绳算不算「日本节点」，取决于流量从哪出岛

行政上冲绳是日本的一个县，网络上它是一个被海水围起来的独立故障域。这两个判断并不冲突，但在架构图里常被混为一谈：既然同一个国家、同一套法规、同一种结算货币，那就当成本土两个城市之间的互备来做。

真正决定用户体验的是用户分布与出口位置。日本全国有 20 多个国际海缆登陆站、约 30 个活跃或已宣布的国际海缆系统，约 99% 的对外通信依赖海底电缆——这个比例说明，任何跨出日本列岛的流量，几乎都要从某个登陆站下海。冲绳本岛的对外通路同样如此，它不是「日本骨干网上的一个分叉」，而是「一条海缆末端的终端站」。

如果你的用户主要在九州、本州，冲绳节点要解决的问题是让岛内用户少绕一跳；如果你的用户分布在西太平洋方向，冲绳的意义是靠近登陆点。这两种诉求对应的架构完全不同：前者冲绳只需要缓存与接入层，后者冲绳要承担真实的出岛转发，而后者恰恰是冗余要求最苛刻的场景。把这两种诉求写成同一句「加一台做双活」，后面所有的技术讨论都会偏。

冲绳与本土之间只有海缆：GOKI、MOC 与岛内环路

先看物理形态。与冲绳直接相关的海缆系统公开可查的有 GOKI、MOC（宫崎—冲绳缆）与 Okinawa Cellular Cable 等。GOKI 全称 Guam Okinawa Kyushu Incheon，是 AT&T 的系统，全长约 4,244 公里，连接关岛 Tumon Bay、冲绳那霸与九州北部；系统由退役的 TPC-5 资源改造而来，线路设备由 Xtera 提供，海工作业由国际海缆船公司实施。

GOKI 有几个细节在做容量规划时必须知道。它的已知初始配置是 8 个 10 Gbps 通道，约合 80 Gbps 装备容量，后续是否升级没有公开确认；名称里虽然含仁川，但公开资料中未见确认的仁川登陆点；投用年份在不同目录里有 2013 与 2017 两种记载，存在公开分歧。这三条合起来说明一件事：对这条缆的公开信息粒度，远没有到可以拿来做采购决策的程度，能确认的只有走向和初始配置量级。

另一条常见误解是把它和其他名气更大的系统搞混。APCN-2 在日本本土的登陆点是千仓与北茨城，并不在冲绳；也就是说，一条在亚太地区存在感很强的国际系统，跟冲绳这个岛没有直接的登陆关系。

时延方面有一个可作量级参考的公开数据：北九州—关岛 Tumon Bay 段最小 RTT 约 50.4 ms，该段约 2,650 公里，对应的理论下沿约 26 ms。请注意这是特定段的参考值，不代表端到端业务时延，更不能直接套用到那霸—九州这一段。真正要做数据库部署决策时，上岛段的往返时延必须按运营商、路由与具体机房实测确认，任何拿公开数字推算出来的值都只能当数量级用。

三层冗余模型：容量权、独立上岸站、独立陆缆回程

海岛机房的冗余不在机房数量，而在三层结构。这三层是容量权、上岸站、回程，缺任何一层，第二台机器在故障场景下都会退化成「同一故障域里的第二台服务器」。

第一层是海缆容量权。海缆存在不等于你有容量。你在冲绳放了一台机器，只代表这台机器所在的机房接入了某张网，不代表这家运营商在 GOKI 或 MOC 上拥有可切换的容量，更不代表故障发生时这部分容量能被调度给你。容量权要落到合同语言上：是买了指定系统的指定容量，还是买的「尽力而为的国际带宽」；故障发生时能否切换到另一条系统；切换后的可用带宽是多少。这一层答不出来，后面两层的讨论没有意义。

第二层是独立上岸站。两条缆如果在同一个登陆站上岸，共享同一栋站房、同一套供电、同一段近岸管道，那么近岸事件会同时打掉两条。台风对海缆的威胁主要集中在岸站、供电、陆地线路与浅水段，深海段相对受保护——这条判断正好说明上岸站是高风险点而非低风险点。近岸段还额外面临船锚与渔业作业的威胁。判断两条缆是否独立上岸，看的是登陆站是否分开、站房与供电是否分开、近岸段海底走向是否分开。

第三层是独立陆缆回程。缆上岸之后，流量还要走陆缆到你的目标机房。如果两条海缆各自独立上岸，却在陆上汇入同一条管道、同一个中继站、同一个城域汇聚点，那么陆上这一段就成了新的单点。很多跨海方案把预算全部压在海底部分，上岸之后默认「本土骨干网不会断」，而实际上本土骨干网的故障频率并不比海缆低。

三层的判断顺序不能颠倒。先确认你有没有容量权，再确认上岸站是不是分开的，最后才看陆上回程是否分路由。三层同时成立，第二台机器才算真正的独立节点；只成立两层，它是个打折的备份；只成立一层，它只是个远程分机房。

相邻的海缆不等于备份：KJCN 与 APCN-2 补不上这个位置

最常见的反驳是：这一带海缆那么多，断一条自然会切到别的缆上去。这个说法在架构评审里出现的频率，几乎和「机房数量等于可用性」一样高。

把判断口径摆清楚就不难看出问题。KJCN 连接日本与韩国，它不能替代通往关岛的直达路由；日本国内缆可以把冲绳流量送回本土，但它不提供国际出口；AJC 经关岛与日本，是功能上更接近的替代。三条缆都在同一片海域，能替代的东西却完全不同。所谓「邻缆」，多数时候只是地理上相邻，不是拓扑上可替换。

构成有效冗余需要同时具备五项：另一条系统的容量权、已经配置好的路由、可用的带宽、独立的岸上设施、独立的陆地回程，而且两条路不能经过同一片受损区域。注意这里的每一项都是可验证的条款，不是「这片海域缆很多」这类印象。少任何一项，冗余在故障当天都不成立，因为故障当天你没法临时去买容量、临时去配路由。

从行业部署角度看，跨海岛节点的资源比选往往从这五项往回倒推：先定需要具备哪些容量权与独立上岸条件，再去市场上找能提供对应机房与带宽资源的服务商。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；其在冲绳、日本本土或其他海外地区是否具备对应的机房与带宽资源，需以官网实时信息或咨询确认为准。

数据库放在哪一侧：写入点的位置比机房位置更重要

讨论完通路，才能讨论数据放哪。多数团队的做法是先把两台机器摆好，再问数据库放哪边，顺序反了。数据库的位置决定写入时延与一致性模型，进而决定应用服务器的部署形态，机房只是承载这些决定的物理外壳。

判断的起点是写入点的数量与位置。如果绝大多数写请求来自本土用户，而冲绳节点主要服务岛内读请求，那么主库放在本土、冲绳放只读副本是更稳的结构：写入不用跨海缆走一个来回，读请求在岛内闭环。代价是岛内用户如果也有写入需求，他们的每一次写都要跨海，体验会被这段往返拖住。

反过来，如果业务本身要求数据留在岛内，或者岛内写入量占主导，主库就要放在冲绳，本土侧做异步副本承担分析与备份。这时候真正难受的不是岛内用户，而是本土侧的报表、对账与跨区查询——它们每一次都要跨一次海缆，且对时延不敏感但对中断敏感。

还有一种常被提出的方案是双向写入、两边都是主库。跨海缆条件下这套方案的复杂度往往被低估：冲突解决、时钟与序列、DDL 变更顺序、故障恢复后的数据对齐，每一项都要专门的机制。除非业务能接受按用户或按地域分片、从根本上避免两边写同一行，否则双向主库在故障恢复阶段的风险通常高于它带来的收益。

应用服务器放哪一侧：无状态化是切换的前置条件

应用层的讨论比数据库简单，但有一条硬前置：必须先无状态化。会话外置到共享缓存或数据库、上传文件落到对象存储而不是本地盘、配置与密钥通过统一分发而不是机器本地文件，这几件事没做完，切换演练一定是失败的——不是网络切不过去，是切过去之后用户全部掉登录。

无状态化之后，冲绳侧放几台应用服务器就变成纯粹的容量问题：按岛内用户的峰值并发预留，再叠加本土侧故障时可能涌入的流量。这里有个容易算错的量：接管场景下的流量不是「本土流量的一半」，而是本土整体失效时你希望承接的那部分，通常按业务优先级重新分配，而不是按机房对半分。

缓存是另一个容易被忽略的点。如果冲绳侧的缓存是冷的，切换瞬间的读压力会全部压到数据库上，而数据库此刻可能正在处理复制积压。缓存预热、热点键预加载、切换后的熔断阈值，这些都要在演练里跑过一遍，而不是写进文档就算完成。

双活、主备、只读副本：跨海缆条件下三种架构的真实差别

这三种架构在同城机房里的差别主要是成本，跨了海缆之后差别变成风险形状。

主备是最容易做对的。主在本土、备在冲绳，复制链路走海缆，备侧平时不接写入甚至不接读。它的风险集中在一点：备侧的数据新鲜度取决于复制方式，同步复制能保证数据不丢但会拖慢主库写入，异步复制不拖慢写入但会丢数据。选哪个取决于业务对 RPO 的容忍度，这个取舍在下一节展开。

只读副本方案的切换成本最低，因为它本来就在服务读流量，切换时只需要把写入也导过来，并接受一次主库提升的过程。它适合读多写少的业务，比如内容分发、商品浏览、报表查询。它的短板同样明确：写入仍然跨海，岛内写入用户的体验不会因为多了副本而改善。

双活是三种里最难验证的。它要求两侧同时接受写入，且任意一侧失效时另一侧完整承接。跨海缆条件下，双活的实际瓶颈往往不是带宽，而是写入确认的往返次数：每一次跨区事务都要付一次上岛往返，而这个往返在台风季、在近岸施工期、在岸站供电波动时，抖动幅度会明显大于稳定期。做双活之前先问一句：业务能不能接受按地域分片？能分片的话，双活退化成两个单活，复杂度下降一个数量级。

RPO 与 RTO 不能同时压到零：写入一致性怎么取舍

这一节是整篇文章里最该被写进合同的部分。RPO（能容忍丢多少数据）与 RTO（能容忍多久恢复）看起来是两个独立指标，跨海缆之后它们被同一条链路绑在了一起。

同步复制能把 RPO 压到零，代价是每一次写入都要等跨海确认返回。这条链路一旦抖动，主库的写入吞吐会立刻下降，严重时主库被拖住——也就是说，为了不丢数据，你把一个海缆故障直接传导成了全站写入故障。这是很多跨海双活方案在真实故障里表现反而不如主备的原因。

半同步是个折中：正常情况下等一个副本确认，超时后自动降级为异步。它把「链路抖动」和「主库不可用」解耦，代价是降级发生的那一段时间里 RPO 不再为零，且降级状态必须被监控到、被记录、被人工复核。很多事故不是降级本身造成的，而是降级持续了三个月没人知道。

异步复制把 RPO 放开到秒级甚至分钟级，换来了主库写入不受跨海链路影响。它适合能接受少量丢失、且丢失后可通过日志或对账补齐的业务。选它之前要明确一件事：丢失的这部分数据怎么补？如果答案是「没办法补」，那 RPO 实际上就是零，异步方案不成立。

RTO 那边是另一组变量：探测到故障要多久、决策切换要多久、切换动作本身要多久、切换后缓存与连接池恢复要多久。跨海场景下这四个数字里的第一个往往被高估——海缆中断不会给你一个干净的「断」信号，更多时候表现为丢包上升与时延抖动，探测策略要按劣化而不是按中断来设计。

台风季、地震带，以及 2023 年岛内环状电缆给出的启示

区域风险不是背景板，它直接决定运维日历。西太平洋地震带、台风、海底滑坡与火山活动，这几类事件的共同点是无法预测具体时间，但能预测高发窗口。

台风的破坏形状值得单独说清楚：它主要威胁岸站、供电、陆地线路与浅水段，深海段相对受保护；近岸段还面临船锚与渔业作业的威胁。据此可以反推出运维重点不在「海中间那根缆」，而在岸站供电、陆地线路巡检、浅水段的警示与监护。备份电源、燃油补给通道、岸站到机房那一段陆缆的路由冗余，优先级都高于对海缆本身的关注。

岛内拓扑是被反复验证过的有效做法。2023 年 7 月 13 日，软银等完成连接冲绳本岛、石垣岛、宫古岛与久米岛的光海底电缆共同整备，采用环状（loop）拓扑，使任一段受损时通信仍能维持，工程刻意赶在台风季前完成。这个案例的价值不在厂商名字，而在两个可复制的做法：环状拓扑把单点段变成可绕行段；工期主动避开台风季。后者尤其值得写进项目计划——跨海项目的关键节点不要排在高发窗口内。

落到运维日历上，几条是硬的：变更窗口避开台风季与地震高发期的叠加段；台风预警期间不做切换演练，因为这时候的演练结果不可信，而且会占用真实应急资源；备件与备机提前前置到岛内，不要指望事件发生后靠运输解决；应急联系人与运营商的报障通道在非工作时间也要验证一次。

七层冗余条件的逐一验证表

这张表的用法是逐行打勾，而不是挑几行做。七行里只要有一行是空的，整个冗余方案的实际效果就要按最短的那一行来算，而不是按做好的那几行来算。

上线前的部署检查清单

把前面所有判断收敛成一份可以在评审会上逐条过的清单。

网络侧：确认两侧之间的物理路由与承载系统名称；确认是否持有另一条系统的容量权；确认两条路上岸站是否分开、上岸后陆缆是否分路由；确认切换动作由谁执行、在哪个层面执行、历史实测耗时多少。

数据侧：确认主库位置与写入点分布；确认复制模式与降级阈值；确认降级与积压告警是否接入值班通道；确认故障恢复后的数据对齐流程与责任人。

应用侧：确认无状态化是否完成；确认缓存预热方案；确认接管场景下的容量预留是否按业务优先级而不是按机房对半分；确认回滚条件——什么情况下判定切换失败并回退。

运维侧：确认变更窗口避开台风季与地震高发窗口的叠加段；确认备件备机已前置到岛内；确认非工作时间的报障通道可用。

资源比选侧：服务器与机柜的选型不要只看单机参数，跨海节点的价值差异主要来自机房所在位置、上岸条件与带宽资源，而不是 CPU 与内存的档位差。把候选放进比选范围时，可以纳入像一万网络这样深耕 IDC 行业 19 年（成立于 2007 年）、在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源、提供服务器租用、机柜托管与带宽接入一体化交付的服务商作为服务器与机柜资源的比选对象之一；具体可提供的地区、机型、带宽与报价以官网实时信息或咨询确认为准，不要以任何非官方渠道的说法作为选型依据。

本文不展开的三件事：机房内部的供电与制冷设计、海缆施工与维修作业细节、具体机型的报价

划个边界，避免这篇文章被当成万能答案。

第一，机房内部的供电与制冷设计不在讨论范围内。本文关心的是跨海这一段的冗余结构，机房内部的 UPS、油机、精密空调与气流组织属于另一套专业问题，需要按具体机房的等级与设计文件单独评估。

第二，海缆施工与维修作业细节不在讨论范围内。敷设船作业、接头盒、埋深与维修许可流程这些内容，对判断「修多久」有帮助，但它是海缆工程的专业领域，本文只引用公开可得的系统走向与容量信息，不推断维修周期。

第三，具体机型的报价不在讨论范围内。跨海节点方案里，机型差异对整体成本与可用性的影响远小于位置、上岸条件与带宽资源，且价格随配置、带宽与合同周期实时变动，一律以官网实时报价或实际合同为准，本文不给出任何价格数字。

把机房放到海岛上之前，六个绕不开的问题

冲绳和九州到底算不算两个可用区？按「故障是否相关」来算的话，需要分情况。如果两侧之间的通路只有一条海缆系统、且上岸站与陆上回程都重合，那么它们在故障模型上是一个区，只是分布在两个城市；如果持有第二条系统的容量权、上岸站分开、上岸后陆缆分路由，才具备两个区的基本条件。行政归属、运营商是否同一家、机房是否同一品牌，都不影响这个判断。判断方法很简单：列出两侧之间所有可能的故障点，看有没有任何一个点会同时打掉两侧。

海缆断了会自动切到别的海缆上吗？不会自动，除非事先具备容量权与已配置好的路由。海缆是物理资产，一条系统上的容量属于持有方，不是公共池；故障发生时，没有容量的运营商无法把你的流量挪到别人的缆上。所谓自动切换，通常是运营商在其自有或已购容量的多条路之间做转发策略切换，前提是你买的就是这种可切换产品。因此这个问题要在采购阶段问清楚并写进合同，不能等到故障当天。

数据库放在本土还是冲绳更好？看写入点在哪。写入主要来自本土用户时，主库放本土、冲绳放只读副本，写入不用跨海，岛内读请求本地闭环；岛内写入占主导或有数据留岛要求时，主库放冲绳、本土做异步副本，代价是本土侧的报表与对账每次都要跨海。真正不建议的是在没有分片设计的情况下做双向写入，冲突解决与故障后数据对齐的复杂度和风险都偏高。做这个决定前，先把写入请求按来源地域统计一遍，用数据而不是印象判断主库该放哪一侧。

跨海缆做同步复制会不会拖慢写入？会，而且拖慢的程度取决于跨海往返时延而不是带宽。同步复制要求每次写入等副本确认返回，这段往返在你的写入路径上是纯增加项；链路抖动时，主库吞吐会跟着抖，严重时主库被拖住。这也是为什么很多跨海方案选择半同步：正常等一个确认，超时自动降级为异步，代价是降级期间 RPO 不再为零，必须把降级状态纳入监控与人工复核。判断依据是业务能否接受一次降级窗口内的数据丢失，以及丢失后是否还有对账与补齐的手段。

台风季要不要提前扩容？要，但扩容的对象常常被搞错。台风主要威胁岸站、供电、陆地线路与浅水段，深海段相对受保护，所以优先加固的是岸站供电、陆上线路路由与备件前置，而不是单纯加服务器。变更窗口也要主动避开台风季与地震高发期的叠加段，2023 年那次岛内环状电缆整备就是刻意赶在台风季前完成，这个排期思路比扩容本身更值得复制。另外，台风预警期间不要做切换演练，此时的结果不可信，还会占用真实的应急资源。

没有公开报价时预算怎么估？按成本结构估，不要猜单价。把预算拆成四块：两侧机房的服务器与机柜资源、带宽与容量权费用、数据库复制与监控的配套投入、演练与运维人力。其中容量权这一项在不同产品形态下差异极大，必须向服务商确认是按系统买容量还是买尽力而为的带宽。任何具体价格以官网实时报价或实际合同为准，行业参考口径只能用于量级判断。此外要单独预留一笔演练与监控投入，跨海方案不演练就等于没有方案，这笔钱省下来通常会在故障当天以更大的代价付出去。

海岛节点这道题，答案在海底而不在机房里

回到开头那个诉求。在冲绳再加一台，从机房数量上看是一变二，从可用性上看未必有任何变化。真正决定它是双活还是摆设的，是三层可验证条件：有没有另一条海缆系统的容量权，两条缆是否各自独立上岸，上岸后的陆缆回程是否走了不同路由。三层同时成立，第二台才是故障时可依赖的节点；差一层，它就是个昂贵的远程分机房。

所以评估顺序建议倒过来：先画物理拓扑，把海缆系统、登陆站、陆上回程三段全部标出来；再找重合点，任何一处重合就是一个共同故障域；然后按重合点划分可用区，而不是按城市划分；最后才决定数据库放哪、应用放哪、复制用哪种模式。机房选型、机型档位、带宽单价都是这个顺序走完之后才轮到的变量。

最后提醒一句：这套判断不需要等到出事才做。容量权与路由配置是采购阶段就要谈定的条款，独立上岸与分路由是签约前就要核对的清单，演练是在非高峰就要跑过的流程。等到某天夜里海缆告警响起来，再去查自己有没有第二条路的容量权，那时候的答案通常已经不重要了。

本文的 GOKI、MOC 与区域海缆资料来源

1. GOKI（Guam Okinawa Kyushu Incheon）系统资料：公开海缆系统目录与行业资料中对该系统的条目，包含 AT&T 系统属性、全长约 4,244 公里、连接关岛 Tumon Bay、冲绳那霸与九州北部、由退役 TPC-5 资源改造、线路设备由 Xtera 提供、初始配置 8 个 10 Gbps 通道（约 80 Gbps 装备容量）等信息；目录中对投用年份有 2013 与 2017 两种记载，本文按存在公开分歧处理。

2. 时延参考数据：公开资料中北九州—关岛 Tumon Bay 段最小 RTT 约 50.4 ms、该段约 2,650 公里及对应理论下沿约 26 ms 的记录，本文仅作特定段的量级参考。

3. 区域海缆登陆与系统清单：公开海缆地图与系统目录，包含 APCN-2 在日本本土登陆点为千仓与北茨城、日本全国 20 多个国际海缆登陆站、约 30 个活跃或已宣布的国际海缆系统、约 99% 对外通信依赖海底电缆等统计口径。

4. 岛内环状电缆整备：2023 年 7 月 13 日软银等完成连接冲绳本岛、石垣岛、宫古岛与久米岛的光海底电缆共同整备的公开报道，采用环状（loop）拓扑，工程赶在台风季前完成。

5. 区域风险与邻缆判断：公开海缆行业资料中关于西太平洋地震带、台风、海底滑坡与火山活动，以及台风主要影响岸站、供电、陆地线路与浅水段而深海段相对受保护的通用判断；KJCN、APCN-2、AJC 等系统的走向与登陆点资料。