架构训练营 week7 作业

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

【背景】

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

【作业要求】

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

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

【提示】

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

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

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

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

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

分析：

这个任务是要根据王者荣耀商城的业务来设计业务定制型的异地多活架构

业务定制型的异地多活架构的设计步骤主要有四个：

1. 业务分级

2. 数据分类

3. 数据同步设计

4. 异常处理

• 业务分级

如果把商城业务看做一个整体，那么对于里面的业务进行分析，主要有：商品浏览，购物车，商品促销，点券管理，商品结算，点券充值。

既然是商城，那么首要的就是要赚钱，充值是最重要的，但是因为充值是第三方做的，我们系统只是唤起充值页面，所以这块并不用做异地多活。那么充值之后会得到点券，这个点券对于用户而言就是钱，所以这个是很重要的业务。要让用户消费点券，就要让用户看到可以买什么，所以商品展示也是重要的。再来就是要把钱算对，否则用户投诉了，因而结算也是很重要的。虽然购物车也挺重要，但是用户不会像淘宝用户一样，把购物车里塞满商品，等它降价，所以对于购物车的异地多活并不重要，里面东西没了就没了。

所以最后，进行分级就是：商品展示，点券管理、商品结算这三个功能

• 数据分类

【商品展示】

1. 商城商品，id 全局唯一，并且新增以后可能修改，例如打折等等。

【点券管理】

1. 点券余额，与用户 id 绑定，全局一致性。

2. 消费记录，与用户 id 绑定，只会新增，不会修改。

【商品结算】

1. 绑定商品，id 全局唯一，每次算法生成，并且新增以后不会修改。每个用户只能买一个

2. 消耗品，id 全局唯一，每次算法生成，并且新增以后不会修改。但是每个用户可以买多个

3. 订单记录，id 全局唯一，每次算法生成，因为是要付款以后才会获得，因此可以等用户付款之后再生成订单记录，所以生成的订单记录后续不会修改。

• 数据同步设计

【商品展示】

1. 商城商品，可以采用数据库同步+消息队列同步。

【点券管理】

1. 点券余额，全局一致性，所以要用数据库同步余额，充值只能在归属地充值，否则处理起来很麻烦。

2. 充值记录，消息队列同步。

【商品结算】

1. 绑定商品，全局一致性，所以这个也要数据库同步，并且只能在归属地购买。

2. 消耗品，可以用数据库同步+消息队列同步。

3. 订单记录，可以采用消息队列同步

• 异常处理

• 用户所在地机房故障，并且用户刚刚充值，点券还没同步到异地机房。

方案：可以让用户等待一下，如果真的发生点券丢失，可以通过后台操作帮用户增加点券。

• 用户消费点券之后，归属地服务器故障，记录还未同步到异地机房，导致用户没有看到充值记录

方案：让用户等待一下即可

• 用户到了非归属地进行游戏，想要购买皮肤等绑定商品

方案“”可以让用户回到归属地购买，或者后台操作，帮用户购买此绑定商品

• 用户购买了消耗品，归属地机房故障，商品数据还没有同步到异地机房，或者由于某些原因消耗品丢失

方案：让用户等待一下，在丢失的情况下可以帮在后台帮用户调整商品数量以赔偿用户损失。

• 用户购买商品之后，归属地机房故障，订单数据还没有同步到异地机房，导致用户看不到订单数据。

方案：让用户等待一下即可。

• 架构图