写点什么

架构实战营模块七 作业

作者:Jude
  • 2022 年 2 月 07 日
  • 本文字数:875 字

    阅读完需:约 3 分钟

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


【背景】

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

【作业要求】

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. 道具购买后无法使用:界面提示等待,人工客服计入,待系统数据同步后通知结果,适当补偿


架构图


用户头像

Jude

关注

还未添加个人签名 2018.10.20 加入

还未添加个人简介

评论

发布
暂无评论
架构实战营模块七 作业