架构实战营模块七作业
作业:王者荣耀商城异地多活架构设计
【背景】
假设现在决定要实现王者荣耀里面的商城的异地多活架构,请你分析设计一下。
【作业要求】
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 机房备库。
评论