按照业务的优先级进行排序，优先保证核心业务异地多活；

基于核心业务的流程和数据，设计定制化的异地多活架构。

【优点】

对基础设施无强要求，例如机房部署、存储系统、时延等，一般部署在远距离的两个城市，可以支持区域级别故障处理。

【缺点】

1. 不通用，每个业务都需要单独来做异地多活，业务需要改造；

2. 难扩展，核心业务如果有重大变化，异地多活方案要重新设计。

XX游戏异地多活设计

1.业务分级

TOP1：登录；

TOP2：支付。

2.数据分类

1. 登录关键数据：session、角色 ID、账号密码；

2. 支付关键数据：支付本身依赖支付宝、微信，支付后的点券元宝等是游戏管理的。

3.数据同步

1. session：不同步，重复生成；

2. 角色 ID：全局唯一，消息队列同步 + 算法重复生成；

3. 账号密码 & 支付：第三方管理，无需处理。

4.异常处理

1. 人工修复；

2. 礼包、代金券补偿。

xx游戏异地多活架构

左图：

存在全局单点、跨机房同步时延问题。

右图：

1. 业务层数据同步；2. 二次读取；3. 可重复生成全局唯一数据

XX游戏异地多活设计核心 - RoleID

为什么不直接返回用户名和用户ID？

为了保证隐私，更重要的是为了安全，微信不希望游戏将用户的账号洗掉，比如有人拿着账号去做骚扰。

xx游戏异地多活设计核心 - 算法生成 RoleID

MD5切换成CRC32算法是为了不让反推出roleID，CRC32可能会有一定的冲突，但是冲突的概率很小，业务可接受。

ITPub博客

异地多活之业务定制型异地多活架构