多活架构基础概念
多活架构，说白了就是让多个数据中心同时对外提供服务。每个中心都是活的，都能处理用户请求。这和传统的“主备模式”完全不同——主备模式下，备机多半闲着，太浪费。
我当初接触这个概念时，也觉得挺简单。无非就是多部署几套系统嘛。但真正深入后才发现，这里面门道很深。尤其是日志一致性这块，稍不留神就会踩坑。
今天就聊聊多活架构最核心的几个概念。
什么是多活？
多活，指多个数据中心同时处于活动状态。它们共同承载业务流量。任何一个中心出问题，其他中心能立即接手。
核心思路呢？就两点：
- 流量分摊——所有数据中心都在干活，没有闲置资源
- 故障切换——某个中心挂了，流量自动转到其他中心
你想想看，要是能做到这两点，系统可用性就能大幅提升。但代价就是一致性变得复杂了。
多活 vs 主备
很多人把多活和主备混为一谈。嗯，这里要注意，它们是两码事。
| 对比维度 | 主备架构 | 多活架构 |
|---|---|---|
| 资源利用率 | 备机闲置，浪费资源 | 所有节点均在用，效率高 |
| 切换耗时 | 分钟级甚至更久 | 秒级甚至无感知 |
| 一致性难度 | 相对低 | 相对高 |
| 建设成本 | 中等 | 较高 |
| 典型场景 | 金融核心库 | 互联网中台、全球化业务 |
我有个项目，刚开始选的是主备。后来业务发展到海外，欧洲用户总抱怨延迟高。最后改成了多活架构，用户满意度一下就上来了。
多活的三种常见模式
多活不是只有一种玩法。根据数据同步的方式，我把它分成三类：
1. 强同步多活
写入一个节点，必须等所有节点都写成功，才算完成。数据一致性最强，但延迟也最大。适合跨机房距离近的场景。
2. 异步多活
写入本地节点就返回成功。数据通过异步方式同步到其他节点。性能好，但存在数据丢失的风险。
3. 最终一致性多活
各节点独立写入。后台通过补偿机制慢慢拉齐数据。这种模式最灵活，但日志一致性测试也最复杂。我们在课程后面会重点讲它的测试方法。
数据同步的核心挑战
多活最大的挑战，说白了就一个：数据怎么同步。
我之前在项目里吃过这个亏。两个数据中心同时接入了同一条订单，结果订单号冲突了。为什么？因为没有全局唯一的ID生成器。
常见的数据冲突场景包括：
- 主键冲突：两个中心同时插入相同ID的记录
- 更新丢失：同时修改同一条数据，后写入的覆盖了先写入的
- 时序错乱：跨中心的操作顺序和实际发生顺序不一致
这些问题，都会在日志中留下痕迹。所以我们的测试案例，就要针对这些痕迹来设计。
日志一致性的起点
说到这里，你可能理解了：多活是架构，日志一致性是手段。为了让多个数据中心的数据保持一致，我们必须跟踪每一条日志的流向。
为什么要强调日志？因为日志是最底层的数据记录。只要日志是对的，数据就能恢复。
我们测试的目标很明确：
- 验证不同中心的日志是否一致
- 发现日志中的冲突和遗漏
- 确保故障切换后，日志不丢失、不重复
// 一个简单的日志格式示例
{
"logId": "uuid-xxxx-yyyy",
"timestamp": 1700000000123,
"dataCenter": "DC1",
"operation": "INSERT",
"table": "user_order",
"data": { "orderId": "ORD001", "amount": 99.00 }
}这个日志里有数据中心标记。有了它，我们才能追溯数据的来源和去向。
搞懂多活，才能测好日志
好了，说了这么多，其实就一个核心结论：多活架构是系统可用性的保障，但它引入了数据一致性的复杂性。而日志一致性测试，就是为了解决这种复杂性而生的。
后面的章节，我们会围绕日志的冲突检测、同步验证、补偿机制等展开。这次先把基础打牢。
我记得刚带团队时，有成员问：为什么要先学架构，再学测试？我说，不懂架构的测试，就像蒙着眼睛开车。你连路都看不清，怎么能测到位呢？