分布式是大型架构核心，下面我详解阿里的“同城双活”架构@mikechen
阿里同城双活
在阿里巴巴的高可用体系中，同城双活（Active-Active）是核心架构之一。
淘宝、天猫、支付宝等核心业务经过多年演进，逐步从单机房、主备容灾，发展到同城双活、异地多活架构。
同城双活，通常是指两个位于同一城市、相对独立的数据中心同时承载生产流量。
且任一中心发生故障时，另一个中心能够快速接管业务，尽量避免服务中断。
与传统“主备”模式不同，双活并不是一套系统平时闲置，而是两地同时工作、共同分担压力。
这类架构最适合对连续性要求高的业务，比如金融交易、支付、账户系统、订单核心链路等。
阿里同城双活架构
阿里同城双活架构，如下图所示：
用户
│
DNS / GSLB调度
↙ ↘
机房A 机房B
APP APP
Redis Redis
MQ MQ
DB DB
↔ 数据同步 ↔
阿里同城双活架构并不是简单地把系统复制到两个机房，而是围绕“流量调度、数据同步、应用无状态化、故障切换”四个层面展开设计。
1. 流量层双活
用户请求，首先通过全局流量调度系统进入就近或指定的机房。
两个机房都可以处理外部请求，并根据健康检查、负载情况和业务策略进行分流。
这样既能平衡压力，也能在某个中心异常时迅速完成流量迁移。
2. 应用层双活
应用服务通常被设计为无状态或低状态依赖。
会话信息、缓存、配置等尽量外置到统一存储或分布式组件中，确保请求可以在任一中心被处理，减少对本地状态的依赖。
3. 数据层双活
这是同城双活最难的部分，阿里通常会结合多副本数据库、分布式存储、消息队列和异步复制机制，保证数据在两个中心之间一致或最终一致。对强一致性要求极高的场景，会采用更严格的事务控制与仲裁机制；对可接受最终一致的业务，则会优先保证可用性和吞吐。
4. 运维与容灾层
通过自动化监控、告警、演练和故障切换机制，系统可以在发现异常后快速定位并切流，降低人工介入成本。
同时，定期进行容灾演练，验证双活链路真实可用，是架构落地的重要环节。