架构实战营模块七 作业
作业:王者荣耀商城异地多活架构设计
【背景】
假设现在决定要实现王者荣耀里面的商城的异地多活架构,请你分析设计一下。
【作业要求】
1. 分析王者荣耀商城的业务特点,设计其异地多活架构;
2. 按照模块 7 第 5 课的方法来设计异地多活架构。
【提示】
1. 王者荣耀的商城是虚拟物品商城,和淘宝这种实物电商有两个很大的区别,注意识别出来;
2. 用户要先调用微信钱包或者 QQ 钱包充值点券,然后在商城里面用点券支付;
3. 用户买英雄和皮肤的时候同样的英雄和皮肤只能买 1 个,不能重复购买;
4. 用户买鲜花、改名卡之类的道具可以买多个;
5. 分析步骤参考模块 7 第 6 课的案例。
设计步骤一 业务分级
整体场景:注册,登录(联合登录),支付(微信钱包,QQ 钱包),充值,商品浏览,商品购买
其中需要异地多活保障的核心业务识别为:登录,支付(支付本体由三方系统负责,自身负责保障支付状态同步),充值,商品浏览,商品购买,即除了注册以及支付核心业务的其他所有业务模块。(注册不影响现有日活转化,只影响招新,所以优先级略低)
设计步骤二 数据分类
用户信息关键数据:RoleID
1. 依赖 QQ 和微信账号授权登录,本身无需登录信息;
2. 微信和 QQ 授权登录会返回给王者荣耀全局唯一 RoleID;
3. 王者荣耀只需要记录 RoleID 对应的区服信息,区服数据只会新增不会修改。
登录关键数据:Session
确保没有关键充值和交易信息存储在 session 域,则 session 为可丢失数据重新恢复即可
充值关心数据:点券余额,充值流水
点券余额需要做到强一致性
充值流水作为事务性数据,需要考虑事务合并
商品关键数据:道具展示信息,道具上下架状态,道具购买次数限制,道具已购买次数,
道具展示信息为纯静态信息
道具上下架状态,道具购买次数限制可以作为静态信息,缓存在 CDN,后台走 purge 更新
道具已购买次数可以考虑做本地缓存,即超过可购买次数需要屏蔽该商品(如皮肤只可购买一次)
设计步骤三 数据同步
![](https://static001.geekbang.org/infoq/2f/2f5c7882875b1f3e338731d9580b48b1.png)
设计步骤四 异常处理
微信、QQ、三方充值故障:发布维护公告
充值失败,充值点券未到账:人工客服介入,待系统恢复后合并事务检查最终结果
道具购买后无法使用:界面提示等待,人工客服计入,待系统数据同步后通知结果,适当补偿
架构图
![](https://static001.geekbang.org/infoq/c7/c743e9855df180e743f6c63ef0e34334.png)
评论