或許大家體驗過搶紅包，但如何對現實世界的業務場景進行抽象，形成軟體系統的需求，進行模組化與技術選型，這是有一套“方法論”的。來看看本文吧!

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 單一應用

随着業務量增加，進入下一階段

搶實戰(二)-業務模型0 源代碼結構1 業務&amp;模型概述2 資料庫模組化3 ?算法4 負 庫存/金額 問題5 架構演進