知识卡片
不依赖单一存储同步机制，多手段组合同步数据
内容
存储系统自带同步功能（如 MySQL 主备复制、Redis 主从）看似够用，但极端场景（网络抖动、全量重同步）下可能长延迟甚至服务中断，仅依赖它会让”多活”名不副实。更稳妥的做法是组合多种手段：低频数据走消息队列异步同步，本地读不到就向对端”二次读取”，可丢弃的大数据不同步、改按路由”回源读取”，失败就重新生成。发散：可靠性常不是来自单一机制的完美，而是多种互补机制组合后的兜底效果。
参考来源
- 位置：《从0开始学架构》第34章《29｜异地多活设计4大技巧》"消息队列方式""二次读取方式""回源读取方式"三节（源文件：_epub-src/OEBPS/Text/part0033_split_005.html）
- 结论依据：原文明确"对于账号数据……我们可以将账号数据通过消息队列同步到其他业务中心""B中心在读取本地数据失败时，可以根据路由规则，再去A中心访问一次（这就是所谓的二次读取……）""对于登录的session数据，由于数据量很大，我们可以不同步数据；但当用户在A中心登录后，然后又在B中心登录，B中心……根据路由判断session属于A中心，直接去A中心请求session数据即可"。
- 原始内容：对于账号数据……我们可以将账号数据通过消息队列同步到其他业务中心……B中心在读取本地数据失败时，可以根据路由规则，再去A中心访问一次（这就是所谓的二次读取……）……对于登录的session数据，由于数据量很大，我们可以不同步数据……直接去A中心请求session数据即可。