支付系統經常使用設計原則

參考：http://www.jianshu.com/p/65b1...

一 表結構設計

用戶資產表：CustomerBalanceAsset

儲存用戶餘額資產。好比返現活動等，例如評價返現30元，通常咱們都是返到用戶餘額；另一些項目有充值需求，也能夠把第三方支付結構或者銀行機構內的資金充值到餘額中。

資產變更記錄表： CustomerBalanceAssetLog

儲存用戶餘額資產變更記錄。由於資產確定會發生變更（增減），必須須要log表例如customer_balance_log（能夠業務代碼實現寫入也能夠經過數據庫的event實現，建議採用前者）記錄全部的資金變更詳情，方便對帳補償差錯。

紅包表：CustomerCouponAsset

儲存用戶紅包資產，用戶參加紅包活動，領取紅包資產，會記錄到這張表中。

紅包日誌表： CustomerCouponAssetLog

儲存用戶紅包資產變更記錄，消費，過時等
...... 另一些積分，抵扣券能夠沿用相似邏輯

支付信息表：Payment

儲存用戶支付行爲信息。關鍵字段有總支付金額，支付建立人，支付狀態等。多個訂單可能合併成一個支付，或者一個訂單分拆成多個支付，因此須要和Order表多對多映射

流水錶：Transaction

儲存用戶資金單據（流水），關鍵字段爲支付渠道，支付金額，支付時間，支付狀態等。其與Payment爲多對一關係。可是不一樣的Transaction有不一樣的字段，例如微信支付有商戶訂單號，預支付單號等，這些字段是餘額資金單據不須要的，若是設計一個大Transaction表的話，不利於擴展，也會形成很多記錄會出現空字段。

所以能夠根據不一樣的資金單據設置不一樣的數據模型，好比
資產流水錶：BalanceTransactionInfo
紅包流水錶：CouponTransactionInfo
微信流水錶：WeixinTransactionInfo字表
支付寶流水錶：AlipayTransactionInfo表
......
以共享主鍵的方式與Transaction表創建一對一關係。
共享主鍵
爲了提升數據庫性能。好比咱們有一張user表，有id、用戶名，姓名、年齡、地址等等信息，但經常使用的可能只有用戶名、姓名。那麼若是咱們將全部的字段放在一塊兒會帶來沒必要要的效率損失，好比查詢出來大量無用字段，此時就能夠拆成兩張表，經常使用字段放到一張表，不經常使用的放到另一張，而且是採用同一個主鍵。

二 可靠性

存在調用支付接口支付成功，回來以後你要更新表狀態啥的，萬一更新失敗了呢？拋異常了，你是給用戶反饋支付成功了仍是失敗了？調用支付接口成功後固然是已經支付成功嘍，那麼這個時候就應該直接返回給用戶支付成功，然後可使用消息隊列將付款後的一系列操做扔到消息隊列裏去，讓它本身去玩。

一樣的道理適用於與供應商交互，當有一些關鍵操做時，均可以使用異步隊列來確保執行完成。