架构实战训练营模块七

一.需求背景

设计王者荣耀里面的商城的异地多活架构

二.业务分级

1.点券充值

2.点券消费

3.商城浏览

商城是在登录游戏后浏览或充值及消费点券,所以将登录商城等功能的异地多活与游戏的登录放在一起,此处仅考虑登录商城后用户的行为操作.

三.数据分类

1.点券充值

充值流水号:全局唯一不可变,由于充值依赖第三方服务,如 qq 和微信,所以充值流水号是关联商城点券和充值记录的关键数据,同时也作为用户充值退款的重要依据.

点券余额:全局唯一,随着充值的记录及消费的记录改变.

2.点券消费

消费流水号:全局唯一不可变,用来记录点券消费的相关信息,包含购买的皮肤等道具信息.

购买的道具信息:全局唯一不可变,购买后需要与用户 ID 绑定,才能在对战或使用道具时进行使用.

点券余额:同点券充值.

3.商城浏览

皮肤英雄等道具信息:全局唯一,只读,方案可以配合点券充值和消费落地即可.

四.数据同步

1.点券充值

充值流水号:全局唯一不可变,数据库+消息队列同步.

点券余额:全局唯一,使用数据库同步,同样采用用户 ID 作为分区的方式,当一中心主库不可用时,路由器至二中心并写入备库,在一中心恢复后,数据库组从同步恢复.

2.点券消费

消费流水号:全局唯一不可变,数据库+消息队列同步,采用用户 ID 作为分区键,当一中心主库不可用时,路由器至二中心并写入备库,在一中心恢复后,数据库组从同步恢复,使用消息队列记录备份过程信息以及在宕机时间过长时作为备选方案进行数据同步处理.

点券余额:处理方式同点券充值.

3.商城浏览

每个中心各设置主库即可,轮训获取商品信息.

4.异常处理

调用第三方充值失败时:不处理,用户刷新后再次充值即可.

调用第三方充值成功但商城服务处理失败时:记录第三方充值流水信息,用户申诉时人工介入,手动更新充值结果.

针对点券余额某一中心宕机时:采用用户 ID 作为分区键,当一中心主库不可用时,路由器至二中心并写入备库,在一中心恢复后,数据库组从同步恢复,使用消息队列记录备份过程信息以及在宕机时间过长时作为备选方案进行数据同步处理.

点券消费失败:用户申诉时人工介入,选择为用户添加对应的商品或冲正点券余额.

商城浏览获取商品信息失败:不处理,用户刷新页面后就可从下一个中心获取商品信息.

5.异地多活架构图

异地分为一中心和二中心两个机房,用户请求通过 DNS 路由访问机房归属地路由,归属地路由通过请求中的用户 ID 进行用户机房归属路由,双机房采取主备同步复制的方式进行数据同步,同时增加消息队列作为默认的同步方式.