王者荣耀商城异地多活架构设计 - 模块 7

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

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

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

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

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

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

4. 用户买鲜花、改名卡之类的道具可以买多个； 5. 分析步骤参考模块 7 第 6 课的案例。

异地多活：服务部署在不同的地理区域，不同地区互为备份。用来分散服务宕机风险，属于灾备架构设计方案。

异地多活架构模式分三种：业务定制型、业务通用型、存储通用型

王者荣耀商城属于业务定制型异地多活，设计步骤如下：

1.业务分级

业务分级判断维度：访问量、核心场景、收入来源

王者荣耀商城业务包括：登入，购买点券，点券兑换英雄、皮肤等虚拟商品

2.数据分类

数据分类维度

登入，购买点券，点券兑换英雄、皮肤等虚拟商品

登录数据：

依赖 QQ 和微信账户授权登录，本身无登录信息

微信和 QQ 登录后会返回游戏的全局唯一 RoleID，游戏数据只认这个 RoleID

登录后进入游戏需要选择区服，会新增 RoleID 的区服记录，只新增不修改

购买点券数据：

调用第三方支付平台（微信支付，支付宝等），返回给游戏已支付金额数。游戏给用户的区服 ID 下增加点券数。

点券兑换虚拟商品

需要生产订单数据，修改点券数，虚拟商品无需减库存。

点券数据，不能多扣，不能丢失，需强一致性

3. 数据同步

订单数据：可采用数据库同步、消息队列同步

点券数据：可采用数据库同步

库存数据：虚拟商品，无限量供应的商品，无需考虑数据一致性，限量的允许超卖、可采用库存拆分到不同机房、数据库同步

4. 异常处理

而对于多活场景产生的异常通常有 3 种处理手段：

登录失败场景：微信、QQ 身份认证服务挂了，区服爆满，无法进入，只能挂停服公告，用户容忍

支付失败场景：重新支付

点券数据未同步：不会对用户造成损失，恢复后重新同步

数据不同延迟场景：

订单数据未同步，可进行二次读取，回源读取