本地容灾 & 跨洲容灾方案选择

对于互联网行业，保证服务的可用性（Availability）非常关键，往往能很大程度的影响用户体验。

在互联网的容灾方案中，一般要求 RPO=0，也就是数据不能有丢失，这个时候数据同步方案的选择就比较关键了。

考虑到数据延迟的问题，我们需要区分同城和跨洲的容灾（数据复制）方案。

同城的数据延迟一般在 20ms 左右，跨洲一般会超过 100ms。

对于同城架构，由于数据同步延迟较小，所以我们一般考虑双写的方案。

具体的同步策略有如下选型：

1. 分布式数据库，如 oceanDB 等。自身的多副本机制就能保证数据的跨机房同步。

2. Mysql binlog 同步。值得注意的是 binlog 需要在事务中开启同步。

3. 应用端的数据库双写。

4. 基于消息中间件的异地复制。

对于跨洲，由于数据延迟较大，一般的交易数据不可能接受在事务中进行双写操作。这个时候根据 CAP 理论，我们需要根据数据类型的不同，选择不同的同步策略：

• 对于配置型、状态型（如用户信息、用户资产等），由于实时性要求不这么高，可以采用双写的模式：

• 跨洲双写；

• 基于队列的跨洲同步。

• 对于流水型数据（如支付信息、订单信息等），由于实时性要求高，在事务中进行双写会比较影响用户体验。这部分数据目前看还没有太好通用解决方案。可以考虑基于 Event Log 的模式进行跨洲数据复制：

• 应用基于 Event Driven 的方式构建，通过 event 可以恢复数据；

• event 之间控制严格的幂等性质；

• event 的同步采用消息队列的方式跨洲同步；

• 状态数据采用跨洲异步同步 snapshot 的方式；

• 恢复的时候采用 snapshot+event log 回放的方式。

采用这种方式，避免了状态数据同步的延迟，同时也能很好的保证 RPO。