作业题目

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

【背景】

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

【作业要求】

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

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

【提示】

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

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

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

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

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

作业内容

1. 业务背景

2. 业务分级

3. 数据分类

4. 数据同步

5. 异常处理

6. 架构示意图

业务背景

本次作业讨论的为王者荣耀商城业务。业务主要包括几部分内容：

1. 商品列表

2. 账户

3. 用户背包

特点在于：

1. 王者荣耀商城商品没有库存概念

2. 王者荣耀商城分为一次性商品、永久商品，一次性商品可以多次购买。

3. 用户要先充值再使用账户余额购买

4. 王者荣耀商城购买后的商品存放在背包中

5. 可以赠予他人

6. 商品列表极少改变

7. 用户背包、账户余额本质上都属于用户数据，绝大多数场景都只在本用户账户下发生，无需考虑夸机房业务。涉及到跨机房的主要是赠予他人业务，该允许有延迟发生。

业务分级

根据王者荣耀业务的高可用分级，由高到低分别是：

1. 用户背包

2. 商品列表

3. 购买功能

4. 账户充值

用户背包中包含了与主业务游戏对战相关的英雄、皮肤等商品，因此用户背包业务优先级最高。要满足用户在对战时调用用户背包中商品列表的能力。

商品列表中包含了英雄、皮肤的介绍，在保证用户可以正常对战的前提下，还要满足用户查看英雄皮肤的商品介绍功能，大多数商城的流量都只是观看英雄、皮肤的介绍，而不是购买，即使当前无法购买，也可以在功能恢复后进行购买。

因此次之为购买功能。

最后为账户充值

数据分类

数据主要包括：

1. 用户背包数据：很少变，最终一致性。

2. 商品数据：极少变，最终一致性。

3. 账户数据：很少变，强一致性。

用户背包数据，对战中要使用，并且由于购买后可能马上就要对战，因此对实时性有一定要求，但延迟影响较低。

账户数据是用户的资金，这方面要求强一致性。不允许用户账户余额多扣，以及用户余额凭空消失的情况发生。但考虑到用户一般也不会在王者荣耀的账户中存储过多资金，因此可以适当降低要求。

数据同步

用户背包功能

用户背包数据：很少变，采用数据库同步+消息队列同步。

背包物品使用：很少变，采用数据库同步+消息队列同步。极端场景能容忍少扣数据。

商品列表

商品数据：可以认为不变，因为每次变更都是运营提前准备好的，可以定时发布，采用数据库同步。

购买功能

账户余额：很少变，消费要求强一致性（账户余额不允许为负数）。采用数据库同步+消息队列同步。

（充值和消费，数据库同步消费记录+余额，消息队列同步充值/消费这个动作的操作日志。）

消费记录：只有新增，全局唯一，采用数据库同步+消息队列同步。

背包物品添加：要求最终一致性。

账户充值

账户余额：很少变，充值要求最终一致性（允许延迟）。（充值和消费，数据库同步消费记录+余额，消息队列同步充值/消费这个动作的操作日志。）

异常处理

背包功能

一次性商品商品使用后，未生效怎么办？

这里主要包括，对自己使用的增加经验值等券券商品，以及对他人使用的亲密度商品，可以容忍延迟。

扣除商品数量时，记录日志，定时任务通过日志补偿恢复。

商品列表

运营定时更新数据，发生异常概率极低，容忍度较高。

购买功能

购买后余额扣除，但商品未到账，怎么办？

此时只能容忍，因为纯机房本地操作，两个操作只进行了一部分的可能性不高，可以通过后期补偿的方式进行。

账户充值

允许延迟发生。

异地多火架构示意图