架构实战营模块七作业

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

【背景】

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

【作业要求】

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

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

【提示】

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

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

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

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

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

设计步骤 1-业务分级

本次作业要求将“商城”也作为核心业务功能来实现异地多活。

设计步骤 2-数据分类

1、RoleID：登录后就不会变化了

2、点券余额：一致性要求较高，且不能够丢失

3、物品库存：数据是强一致性的

4、订单 ID：每次新建，全局唯一，不会修改。

5、订单数据：和订单 ID 绑定，只会新建不会修改，例如 RoleID、商品名称、商品价格等。

设计步骤 3-数据同步

1、RoleID：数据库同步

2、点券余额：数据库同步

3、物品库存：数据库同步

4、订单 ID：每次新建，全局唯一，不会修改，用算法生成，数据库同步即可

5、订单数据：和订单 ID 绑定，不会修改，数据库同步即可

设计步骤 4-异常处理

1、充值后点券未及时到账，无法购买物品

提升系统易用性设计，例如系统会提示用户“转账申请流程中，请稍后”等等。

2、购买道具后，系统没有及时返回结果

提升系统易用性设计，例如系统会提升用户“支付正在核对校验中，请稍后”等等。

商场异地多活架构图

说明：

1、数据库设计：区服数据库和商场数据库都按区互为主备进行数据同步

2、库存拆分：两个机房之间的物品库存可以进行拆分，如果本地库存为 0，调用异地的扣库存服务

3、事务合并：点券余额进行同步的时候，需要考虑当 A 机房出现故障时候

1）如果 B 机房中当前区为主库，则可以正常处理余额数据，待 A 机房恢复后讲数据同步至对应区的备库

2）如果 B 机房中当前区为备库，则此时余额数据可能出现不一致的情况，因为通过临时表记录相关事务，例如“充值 100，消费 80”待 A 机房恢复后，B 机房将临时表数据写入 A 机房的消息队列，A 机房消费消息队列的数据，进行事务合并得到真实的余额，并记录在 A 机房对应区的主库中，由主库通过“余额同步”至 B 机房备库。