這個問題和秒殺,庫存問題是類似的.

https://yq.aliyun.com/edu/lesson/play/270

write.blog.csdn.net/postedit/47340675?ticket=ST-202343-fYu0bMCATjor1YrOjMgM-passport.csdn.net

【阿里線上技術峰會】何登成：AliSQL效能優化與功能突破的演進之路

1. 去併發--排隊是解決這個問題的核心.

n個執行緒. 被分層n組. 通過庫,表,行逐級hash,智慧擴容縮https://yq.aliyun.com/edu/lesson/play/270 .

如果庫層級不排序,那麼就業務方通過redis分散式鎖處理,做到mq通知. mq會是瓶頸.

   何登成-mysql庫存最大500併發量.--- 4k --併發提交後4w

2. 批量提交 -登哥使用了這個技術

3. 切分帳戶,庫存欄位. 分別搶購. 會導致獲取總量較複雜.

並且要循環扣(每次扣1個),或者可能導致餘額不足但不保證有少量餘額.

(需要動態的縮減帳戶數量.鎖帳戶然後操作轉移錢款 ( 分散式鎖,最好一條儲存過程搞定,少一次網路互動.).  select num from update   set num-num where account_id=1;然後 update set id2.num+=id1.num where id=2;

4. 特殊場景,前端業務自行攔截(下沉到資料庫服務端會導致無效邏輯判斷過多. 功能越複雜,自然cpu計算就多.例如B+樹降級為hash索引).總量就是4,那麼一旦排隊大於4*x (或者手動定死控制)個後就設定標誌位攔截所有請求. (這個和客戶端執行緒池有異曲同工之妙)

  支付寶需要有個賬戶記賬，現在很多業務已經出現了很多熱點賬戶。比如網際網路大商家，\\\

      賬號有餘額，主要用於不能扣成負數。 大併發交易下餘額快速變化，導致資料庫競爭等待。

      原則: 不同的業務要求,不同的設計,同時會影響業務需求. 

三大需求,是否都容易滿足:

1.減款

2.加款

3.讀取總金額

最簡單設計: 帳戶表+流水錶. 每次帳戶加減款都需要增加流水,和帳戶變動.

業務需求: 高併發帳戶.

技術選擇 1. 悲觀鎖(高併發帳戶), 樂觀鎖(普通併發帳戶).  3. 順序化 同步轉非同步,mq 降低峰值.

儲存選擇: redis 還是 資料庫. redis本身併發能力就是比資料庫要好. 但是單機支援的資料量不如資料庫大. 只存放account的值的話到還好.

賬戶轉賬分兩個介面，一個可扣成負數,一個不能扣成負數.

 1 如何消除餘額競爭呢？

   方案一：變成兩個賬戶   模仿 擔保交易，設定兩個賬戶    1. 扣款賬戶  2. 加款賬戶

  1.1.  商家都是頻繁加款 ,加款賬戶只記流水,不計算餘額. 避免頻繁競爭

  1.2.  加款帳戶的流水定時彙總到扣款帳戶上.

  1.3   扣款賬戶用於退款和提現, 因為頻率不高.  即保證餘額控制,也沒有併發問題.  退款有些業務能扣成負數,有些業務不能.

  缺點: 進入的錢不一定能時時能用. (對小商家不適用,比較計較)

  優點: 這樣就避免了熱點賬戶的餘額計算。

  方案二： 賬戶分普通賬戶，加頻賬戶，減頻賬戶，雙頻賬戶

型別為加錢頻繁賬戶，加錢不改變餘額，定時任務收集改變。 撿錢操作時時進行。

減頻賬戶，拆分子賬戶。

扣款只賬戶會有個問題，前面扣掉了，但是最後不夠扣。

最佳方案，回滾，即逆操作，加款。

次佳方案， 使用只能扣成一次負數

雙頻賬戶：加款依然如此，減款同上。

 延遲提現問題：即2天內收入只允許某種業務扣款（內部消費，代駕現金抵扣），但不允許提現扣款。

        採用普通賬戶，但是要滿足提現延遲方案？

        小商家加的錢必須時時能用. 又要求延遲提現怎麼辦?

 只能通過訂單維度,目前這個訂單現在有多少錢凍結中(已退款的錢不應該凍結). 展現哪些訂單是凍結的,凍結金額是多少.

              一旦錢被消費了, 賬戶餘額可能少於訂單的凍結的金額,可提現餘額可能為負數. 

       客戶可能來投訴, 因為他自己意識不到錢被消費了(抵扣資訊費)和提現金額變少有關聯.