广播电台容灾这件事，我们做了 20 年才搞明白
KAVANA 工程团队 — 2026 年 6 月
有一种事故，比静默更难发现。
不是开天窗——开天窗你马上就知道，监控报警、电话打过来、领导催。而是那种系统"看起来在跑"的状态：播出机的进程活着，音频矩阵有信号，但实际上发射机那头输出的是三十分钟前缓存的一段音乐，循环播，没人发现，直到上午来上班的第一个人开收音机才意识到昨晚出了事。
我们做广播播控系统二十年，见过太多这种"静默故障"。这篇文章，想把容灾这件事从头捋一遍——不是产品手册，是真实踩坑的记录。
磁带年代：容灾靠人
2005 年之前，大多数县级台的容灾方案就是一盘备用磁带和一个值班的播出员。
主机坏了？插磁带。下午没稿子？提前录好推给下午的班。天气预警？编辑手写一张稿子送到播出间，主播现播。
这套方案有它的合理性：它简单，可操作，失败路径清晰——出了问题就是人的问题，可以追责，可以复盘，可以改流程。
但它有一个根本上的脆弱点：它依赖于"有人在场"。
凌晨两点机器坏了，谁在？节假日呢？台里人员精简之后，值夜班的只剩一个人，他去了厕所这十分钟，出事了怎么办？
磁带年代的容灾，本质上是人肉容灾。在那个时代是够用的，因为大家都这样。
双机互备的第一个十年：稳定性是头等大事
2005 年到 2015 年，整个行业的主流方案是双机热备：主机跑播出，备机实时同步状态，主机一旦挂掉，备机接管。
我们研发 MGR 的早期版本，核心目标只有一个：把主备切换时间压到可接受的范围内。
这听起来不难，但实操里有三个坑，我们反复踩。
第一个坑：故障检测的误报。 早期版本用单一心跳包检测主机状态，一旦网络抖动、交换机负载高，心跳丢几个包，备机就以为主机挂了，触发切换。结果是：主机好好的，备机接管了，两台机器同时往发射机送信号，输出的是两个时间偏移不一致的节目流混叠在一起。这个问题到监管那里，就是重大播出事故。
我们后来改成三路监控冗余判定——心跳、TCP 端口探活、音频电平三者同时失常才触发切换。单一通道失常视为网络抖动，不切换。
第二个坑：切换之后的状态恢复。 备机接管的瞬间，它需要知道"现在应该播什么"。如果切换依赖从网络共享读取播单状态，而主机崩溃的同时网络也受到了影响（现实中这很常见，断电往往连交换机一起断），备机就会卡在读文件的重试循环里，期间同样是静默。
解法是：备机在本地预缓存完整的播单状态，每 60 秒刷新一次，切换时从本地执行，不依赖任何网络操作。
第三个坑：主机恢复之后的抢占竞争。 备机接管 4 分钟后，主机 UPS 重启，主机又活了，主机认为自己应该恢复播出，备机也在播出。两台机器打架，两路信号同时送到发射机。这个问题我们在某台实际发生过，持续了 11 分钟没被发现，因为凌晨 2 点没人在。
解法是确定性仲裁：双主冲突时，硬件 ID 字典序较小的那台让步，退出主播角色。不优雅，但可预期。
一场机房水管爆裂，让我们认识到单机房 HA 的边界
2018 年，我们有一家合作的县级台遇到了一次非典型故障：机房里的消防水管老化，深夜爆裂，机房泡水，主机和备机同时报废。
双机互备，再冗余，也只是两台机器在同一个机房。一次机房级事故，就把所有冗余一扫而空。
那次事故之后，我们开始认真对待跨机房同步这个方向。
单机房 HA 的本质是：防范单点硬件故障。它能解决 UPS 失效、硬盘坏道、主板损坏这类问题。但它无法对抗：
- 机房物理损毁（水灾、火灾、供电线路事故）
- 全楼断电超出 UPS 续航时间
- 自然灾害导致的基础设施中断
这些不是小概率事件。在二十年的服务周期里，我们合作的 500 多家电台，遇到过两次机房水患、一次机房小范围起火（排线老化短路）、若干次市政供电中断超过 6 小时。
省级台机房起火那次：教会我们什么是真正的容灾
那次不是我们合作的电台，是一家省级台，我们是从行业交流中听说的细节。
排线老化引发了小范围火情，机房紧急断电处置，播出中断约 40 分钟。恢复之后发现，因为主备两套系统都在同一个机房，备机同样受影响，并没有完成自动接管。
事后那家台重新规划了架构：在另一栋楼的弱电机房放了一套独立的备播系统，与主机房之间用光纤直连，实时同步播单和音频素材，一旦主机房整体不可用，可以在人工介入的情况下 10 分钟内切到备楼播出。
这个方案并不完美——还是需要人工介入，还是有 10 分钟窗口——但它解决了"机房整体不可用"这个单机房 HA 无法覆盖的场景。
KAVANA-DOG 在这个方向上的演进，就是把跨机房同步做进了标准流程。主备机之间的状态同步，包括播单、配置、已合成的音频索引，都走加密长连接实时同步；备机的 WAV9 音频完整性校验在接管前自动执行，防止"接管成功但播的是错的"这种静默错误。
具体的技术实现可以看 https://www.kavanafm.com/dog，我们在文档里把状态机和仲裁协议都写得比较详细。
春节合家欢节目转播中断：一次软件层面的容灾考验
这是一个很不一样的故障模式。
某年除夕，一家地市台在转播上级台的春节联欢节目。转播链路走的是卫星接收+本地播出机转发。
深夜约 11 点，卫星接收端信号突然中断（后来查明是馈源积雪导致接收角度偏移）。播出机按照设定的逻辑，应该在信号丢失超过 30 秒后自动切换到本地备用节目。
但实际上，那台系统的"信号丢失检测"依赖的是音频电平阈值判断，而卫星接收链路虽然内容中断，但底噪依然存在，电平并没有掉到阈值以下。系统认为信号正常，没有触发切换，播出机对外输出的是无内容的白噪声，持续了约 7 分钟。
这次事故的教训不是硬件冗余，而是故障检测的逻辑必须区分"有信号"和"有有效内容"。我们在 DOG 的后续版本里加入了内容层检测：不只看电平，还对音频帧做语音活动检测（VAD），静默段和噪声段区别对待。
AI 化之后：容灾多了一个新维度
最近两三年，AI 合成内容进入播出链路之后，容灾有了新的复杂度。
传统容灾的对象是硬件和软件——机器挂了、进程崩了。AI 化播出的容灾还要多考虑一层：内容生成失败。
LLM 接口超时、TTS 合成失败、网络不通……在以前，这类问题最多是某条新闻没有语音版，影响范围有限。但如果 AI 合成是某档节目唯一的内容来源，生成失败就意味着那档节目没有内容可播。
我们目前的方案是分级降级：
- 一级：优先走本地 GPU TTS，RTF 0.07 以下，本地合成
- 二级：本地 GPU 不可用时，走阿里云 CosyVoice 云端 API
- 三级：云端也不可用时，使用预生成的缓存版本（每日定时生成备用版本存档）
- 四级：缓存也过期超过 24 小时，系统发出告警，播出员手动干预
这四级降级，保证了即使最坏情况下也有可用内容，而不是静默。
https://www.kavanafm.com/mgr 里对这套多级降级的配置有详细说明，县级台可以根据自己的网络条件和硬件配置调整启用哪几级。
我们真正搞明白的那件事
二十年下来，容灾这件事，我们真正搞明白的是：
容灾不是一个功能，是一套设计哲学。
单点冗余解决不了双点同时失败的问题。硬件冗余解决不了内容层故障。软件冗余解决不了机房级事故。
真正的容灾，是在每一个假设前面加一个问号：假设这个也挂了，系统怎么办？假设网络也断了，本地还能跑多久？假设主备都失效，操作员在 10 分钟内能做什么？
把这些问题想清楚，然后逐层建立防线。不是花哨的架构图，是可以在凌晨两点没人在的情况下撑过去的系统。
我们还在做，还在改。如果你的电台也在考虑容灾升级，欢迎来聊。https://www.kavanafm.com/dog 是容灾相关的产品页，https://www.kavanafm.com/mgr 是播出主控的完整方案，也可以直接联系我们的工程团队。
KAVANA 由湖南声广科技有限公司开发，广播电视节目制作经营许可证湘字第 00565 号，网络安全等级保护三级认证。技术文档与开放规范：github.com/kavanafm