架构实战营模块七作业

作业:王者荣耀商城异地多活架构设计

【背景】

假设现在决定要实现王者荣耀里面的商城的异地多活架构，请你分析设计一下。

【作业要求】

1. 分析王者荣耀商城的业务特点，设计其异地多活架构。

2. 按照模块 7 第 5 课的方法来设计异地多活架构。

【提示】

1. 王者荣耀的商城是虚拟物品商城，和淘宝这种实物电商有两个很大的区别，注意识别出来;

2. 用户要先调用微信钱包或者 QQ 钱包充值点券，然后在商城里面用点券支付;

3. 用户买英雄和皮肤的时候同样的英雄和皮肤只能买 1 个，不能重复购买;

4. 用户买鲜花、改名卡之类的道具可以买多个;

5. 分析步骤参考模块 7 第 6 课的案例；

设计步骤

我们按照业务定制型异地多活的设计思路来设计王者荣耀商城的异地多活：

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

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

业务分级

王者荣耀商城的核心是交易，和实物电商不同的是，王者荣耀商城卖的是游戏里的虚拟物品，在交易的过程中，不需要特别考虑库存超卖和物流配送的问题。产生交易的主要流程如下：

通过以上流程图可得出结论：实现王者荣耀商城异地多活的 TOP4 功能是：登录、查看商品、购买、充值。由于购买和充值都涉及余额的变更，余额是强一致性数据，在跨城模式下，很难实现真正意义的“多活”，因此需要对业务进行改造，允许在跨城机房故障时，非归属地用户的交易先充值再购买。

数据分类

【登录】

1. 依赖 QQ 和微信账号授权登录，本身无需登录信息;

2. 微信和 QQ 授权登录会返回给王者荣耀全局唯一 RoleID;

3. 王者荣耀只需要记录 RoleID 对应的区服信息，区服数据只会新增不会修改；

【商品信息】

1. 商品 ID 每次新建，全局唯一，不会修改;

2. 商品信息在运营后台维护，发生故障时，可暂时容忍数据不能修改，但必须可读；

【购买商品】

1. 订单 ID：每次新建，全局唯一，不会修改；

2. 订单数据：和订单 ID 绑定，为了降低复杂度，业务上限制玩家的订单一旦创建不会修改；

3. 英雄 &皮肤的发放：基于 RoleID 全局唯一 ，保证最终一致性，尽最大努力缩短不一致的时长；

4. 鲜花、改名卡等道具的发放：数据不满足唯一性，发生故障时，业务可容忍保证最终一致性；

5. 余额扣减：强一致性数据，不可丢失；

【充值】

充值依赖微信钱包或者 QQ 钱包，用户充值后需要增加点券的数量，余额属于强一致性数据，不可丢失。

数据同步

异常处理

【登录】

1. 微信和 QQ 挂了怎么办?

直接挂公告:系统停服维护。

2. 玩家在某个区服开了小号，没同步到异地机房，玩不了怎么办?

等系统恢复就可以玩了。

【交易】

1. 商品数据未能同步到异地机房，数据不一致怎么办？

容忍，待运营手动修复。

1. 充值的过程中机房挂了，用户付了钱确没有充值成功怎么办？

如果充值的订单数据还在，则主动查询支付结果，否则需要和渠道进行对账。

1. A 机房数据库损坏，数据未及时同步到 B 机房，导致用户购买的道具用不了怎么办？

根据日志进行数据修复，或给用户补偿。

系统架构