业务背景

【业务数据】

2020.11 月公布数据，全年日均活跃 1 亿，注册玩家数 6 亿，最高同时在线 100 万。

2020.2 月，单月交易额达 1331 万元。

【业务功能】

1. 商品浏览：英雄、皮肤、道具等；

2. 充值：充值游戏点卷；

3. 购买：购买英雄、皮肤、道具等；

4. 优惠：折扣劵等。

【关键业务约束】

1. 用户属于不同的区服，同一微信 ID 可以加入多个区服，俗称“大号”、“小号”；但英雄、皮肤、点卷等不可跨区使用；

2. 虚拟商品，只可购买一次，且购买后不涉及退货、发货等；

3. 余额不足不能进行购买。

设计步骤

1、业务分级

如下业务中，异地多活应该保证哪个或者哪几个核心业务？

商品浏览、充值、购买、优惠。

业务优先级：商品浏览>购买>充值>优惠

【相关问题】

1、如果商品不能充值，无法购买怎么办？

可容忍，等业务恢复后再充值，且只有在余额不足等情况下才影响购买

2、购买直接影响游戏收入，为什么商品浏览的优先级高于购买？

商品无法浏览的话客户不会进行购买，并且客户如果选中商品后，即使现在不能购买能恢复后大概率依然会购买

2、数据分类

【商品浏览】

商品 id：全局唯一，且商品新增后就不会变了；

【购买】

购买订单：统一商品（英雄、皮肤）不能重复购买，与 RoleId 和商品 id 绑定，只会新增不会修改；

余额：强一致性，会修改。

3、数据同步

【商品信息】

商品信息主主同步即可

【购买】

余额：全局一致性，采用数据库同步余额，充值只能在归属地充值；

订单数据：玩家的英雄、皮肤购买后也不会变，数据库同步即可

4、异常处理

【商品浏览】

1. 新增商品时，新增数据未同步到异步机房，无法购买怎么办？

可容忍，等系统恢复后再浏览。

【购买】

1. 购买过程中系统挂掉怎么办？

系统恢复后重新购买即可。

2. 购买订单数据未及时同步到异地机房，用户无法使用英雄、皮肤等怎么办？

等恢复了再用。

架构示意图