抢实战(二)-业务模型

或许大家体验过抢红包，但如何对现实世界的业务场景进行抽象，形成软件系统的需求，进行建模与技术选型，这是有一套“方法论”的。来看看本文吧!

0 源代码结构

1 业务&模型概述

1.1 业务场景

通过移动互联网应用发红包成为了大众普遍的娱乐现象!

1.1.1 发红包场景

• 表白、祝福、庆祝、营销等非技术性名场面
• 装逼、曝光、知识付费提问等技术性场面

1.1.2 业务用例

• 发红包
• 抢红包

1.2 业务定义

1.2.1 所谓红包?

不过是定量的数量和金额的红包序列

• 红包是具备虚拟资金特征的特殊商品
• 收/发红包实际上是资金的交易过程
• 资金交易是资金从一个账户转向另一个账户的过程

1.3 业务模型

2 数据库建模

2.1 从业务领域模型到数据库物理模型

• 物理模型和逻辑模型保持一致,亦可不一致
• 不违背业务模型逻辑的前提下可以做优化
• 冗余、合并、拆分、异构

2.2 资金账户的表设计

2.3 账户物理模型-账户表和流水表结构

2.4 ?数据库物理模型

2.4.1 ?业务模型

2.4.2 合并的?物理模型

库存主要维护： 剩余金额和数量

因为相生相死，库存模型和商品模型可以直接合并，将库存字段放入商品模型

商品和订单也是相生相死，可以合并

商品和活动也是相生相死，都是一对一关系，可以合并

所以，最终优化为两个子模型

• ?物理模型概览

3 ?算法

3.1 ?序列

按照红包总金额和总数量计算拆分后的子红包集合

• 发红包时预置,预存储,直接取
• 收红包时实时内存计算,效率高,异步存储
• 采用收红包时生成红包序列的方式

3.2 ?算法

• 普通红包数量和单个金额固定,不需要算法计算
• 碰运气红包单个金额随机,需要算法来支撑

3.3 计算逻辑要求

• 保证所有人都能抢到红包,且不能出现金额0
• 每个人抢到的红包序列和 = 红包总金额
• 红包序列是随机的,序列元素之间差异性可以控制
• 大小分布可预期
• 尽可能降低性能损耗

3.4 二倍平均算法

• 算法代码

优点

无论红包数量多大，几率都一样

缺点

可玩性低，玩不了刺激,无太大的红包产生

4 负 库存/金额 问题

作为一个高并发资金交易系统,势必存在资金交易安全和事务问题

◆ 本质是要保证剩余数量和金额字段不能为负数 ◆ 事务行锁稳定可靠 ,但性能较差,且容易引发死锁

红包业务中剩余数量和剩余金额不存在负数的场景

◆ 将剩余数量和剩余金额字段类型设计为无符号整型 ◆ 乐观锁 ,在where条件中限制,降低开销 ◆ 总体性能比事务行锁高30% ◆ 无符号字段+乐观锁的方法 ◆ 资金账户转账业务逻辑中,支出时会涉及到资金扣减 ◆ 收红包时红包剩余数量和剩余金额的扣减场景中

5 架构演进

5.1 单一应用

随着业务量增加，进入下一阶段

5.2 微服务架构 - 拆分/共享数据库

5.3 微服务架构 - 基础设施

5.4 模块内部结构

5.5 应用架构