容量冗余设计与分钟级/小时级恢复节奏

为应对某个机房整体不可用这类极端故障，微博核心池的容量冗余分两个层面设计，且冗余比例不同：前端Web层的冗余同用户规模成正比、预留日常峰值50%左右的冗余度；后端缓存等资源因为相对成本较低，每个机房都按整体两倍的规模冗余——这个差异化冗余比例的逻辑是，前端算力相对昂贵、按实际峰值需要精打细算地留50%余量即可，后端缓存资源便宜，索性留足两倍余量以获得更大的安全边际。故障发生后，恢复过程按代价从低到高分阶段推进：第一步只把核心接口迁移到其他健康机房，这个操作分钟级即可完成，而且因为后端冗余是按整体两倍配置的，即便把所有核心接口的流量全部迁移过来，剩余机房也扛得住；第二步，把其他服务池的前端机也临时改造成核心池前端机，这样能在一小时内实现整体流量的承接；如果故障机房恰好是负责数据落地的机房，DBA会把从库提升为主库，运维同步调整队列机的开关配置，让存活机房承接数据落地功能。整个恢复过程中有一个关键的时间窗口作为缓冲：核心缓存可以脱离数据库独立支撑大约一个小时，这意味着即便数据库层的主从切换还没完成，只要缓存还在，服务整体依然能保持平稳，不会立即因为数据库层的调整而对用户可见地受影响。这条设计揭示的一般性原理是：故障恢复不是一步到位的单一动作，而应该按”代价越低、越先执行”的顺序拆解成多个阶段（先迁核心接口→再扩容前端→最后调整数据库主从），每个阶段都要有明确的时间预期（分钟级/一小时内），并且要靠一个额外的缓冲层（这里是能撑一小时的缓存）把各阶段之间的时间差兜住，避免恢复过程本身对用户造成可感知的影响。

结构图：

flowchart TD
    A["某机房整体不可用"] --> B["第1步：核心接口迁移\n（分钟级完成，后端2倍冗余可承接）"]
    B --> C["第2步：其他服务池前端机\n改造为核心池前端机\n（1小时内完成整体流量承接）"]
    C --> D["如故障机房负责数据落地：\nDBA将从库升为主库\n运维调整队列机配置"]
    E["核心缓存脱离数据库\n可独立支撑约1小时"] -.->|"为B/C/D争取缓冲时间\n用户侧感知平稳"| A