架构实战营模块七 作业

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

【背景】

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

【作业要求】

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

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

【提示】

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

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

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

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

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

设计步骤一 业务分级

整体场景：注册，登录(联合登录)，支付（微信钱包，QQ 钱包），充值，商品浏览，商品购买

其中需要异地多活保障的核心业务识别为：登录，支付(支付本体由三方系统负责，自身负责保障支付状态同步)，充值，商品浏览，商品购买，即除了注册以及支付核心业务的其他所有业务模块。(注册不影响现有日活转化，只影响招新，所以优先级略低)

设计步骤二 数据分类

用户信息关键数据：RoleID

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

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

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

登录关键数据：Session

1. 确保没有关键充值和交易信息存储在 session 域，则 session 为可丢失数据重新恢复即可

充值关心数据：点券余额，充值流水

1. 点券余额需要做到强一致性

2. 充值流水作为事务性数据，需要考虑事务合并

商品关键数据：道具展示信息，道具上下架状态，道具购买次数限制，道具已购买次数，

1. 道具展示信息为纯静态信息

2. 道具上下架状态，道具购买次数限制可以作为静态信息，缓存在 CDN，后台走 purge 更新

3. 道具已购买次数可以考虑做本地缓存，即超过可购买次数需要屏蔽该商品（如皮肤只可购买一次）

设计步骤三 数据同步

设计步骤四 异常处理

1. 微信、QQ、三方充值故障：发布维护公告

2. 充值失败，充值点券未到账：人工客服介入，待系统恢复后合并事务检查最终结果

3. 道具购买后无法使用：界面提示等待，人工客服计入，待系统数据同步后通知结果，适当补偿

架构图