淘宝同城双活是阿里的核心，下面我详解淘宝同城双活架构@mikechen
淘宝同城双活
淘宝的架构，演进经历过从单机房到同城双活，再到异地多活（单元化架构）的过程。
在淘宝的演进脉络中，同城双活：是支撑早期海量流量和解决机房容灾（RTO/RPO 接近 0）的最关键一步。
所谓同城双活，是指在同一城市的两个独立机房或数据中心中，同时承载业务流量。
并具备互相切换、共同服务的能力，从而在保障性能的同时提升系统容灾水平。
淘宝同城双活架构
淘宝同城双活架构，整体如下图所示：
从架构设计上看，同城双活通常包含流量调度、数据同步、应用部署和故障切换四个关键部分。
┌── 杭州机房A
│ ├── 应用集群
用户 → DNS/GSLB → 流量调度 ┤ ├── Redis
│ ├── MySQL
│ └── MQ
│
└── 杭州机房B
├── 应用集群
├── Redis
├── MySQL
└── MQ
首先，在流量层面，需要通过DNS、全局流量调度或负载均衡系统，将用户请求按策略分配到两个机房。
一般会结合就近访问、容量比例和健康状态进行动态调度，避免某一侧过载。
其次，在应用层面，两地部署相同版本的服务，并保持配置一致，以确保任一机房都能独立处理请求。
数据同步：是双活架构中最复杂的部分。
淘宝这类平台的数据类型繁多，包括订单、商品、用户、支付等核心数据，不同业务对一致性要求不同。
通常会采用分层数据策略：强一致业务，尽量通过单写、或分区写入控制冲突；
而对一致性要求相对较低的业务，则采用异步复制、最终一致性等方式。
为了避免双写冲突，还需要引入幂等设计、版本控制和分布式事务补偿机制。
可以说，双活架构成败的关键，很大程度上取决于数据设计是否合理。
在故障处理方面，同城双活的优势尤为明显。
当某一机房发生宕机、网络中断或部分服务异常时，流量可以迅速切换到另一机房继续承载业务，从而减少中断时间。
对于电商场景来说，这种快速恢复能力能够显著降低交易损失，是非常关键的。