多活说明

编写人：刘洋

确认：张伟、周敏、李莉

系统：行政协同平台

日期：0000-00-00

结论：同城主备，写入只在主站点

一、当前架构

行政协同平台现在是同城两个站点。主站点在总部机房，承接全部写入和员工网页。备用站点平时用最近备份加当日日志保持数据，应用处于可启动状态，不接受员工写入。总部 420 人的预订、请假、访客和用品都写在主站点。真正的双写多活还没实施。张伟把双写的门槛定在工作日请求超过 20 万次，目前每天只有几千次。

二、两个站点

备用站点的目标是开始切换后 15 分钟内能再次提交。9月21日预发域名的演练用了 12 分钟，生产域名没有改。切换必须由张伟当次宣布，演练记录不能代替宣布。

三、写入规则

员工请求只进主站点。备用站点的网页在未宣布切换前返回维护提示。
请假、预订的单号在主库连续分配。切换后新单号从恢复出来的最大号继续，避免两边各发一套。
通知任务表随库一起恢复。切换窗口内未送达的消息在备用站点按原 eventId 继续发送。
对象存储生产尚未打开，导出仍在主站点同步完成，不存在两地文件不一致。

四、何时再评估双写

出现下面任一情况时，刘洋重新写一版方案：日请求连续 5 天超过 20 万；或备用切换演练两次都超过 15 分钟；或六个办公点同时上线后主库 CPU 在峰值超过 70%。在那之前，容量手段是限流 40 QPS、列表改读副本和加索引，而不是上双写。陈静把本结论记在 9月23日的架构备忘里，下次回顾定在 12 月容灾演练之后。9月21日演练没有改生产域名，当天生产最新单号连续，说明备用站点没有接到员工流量。这个事实是「写入只在主站点」的当月证据。备用站点当天的应用访问日志是 0 条业务请求，只有演练开始后的预发域名流量。主站点当天错误率 0.02%，没有因为演练升高。李莉保留了备用库的空访问日志到 9月28日。