在 MongoDB 上模擬事務操作來實現支付

我們的產品叫「學海密探」，屬于在線教育行業，產品需要有支付功能，然而支付最蛋疼是什么？有人會說是支付寶和微信等支付接口的接入開發！沒錯，但支付接口的開發算是比較簡單的了，我覺得凡是跟錢有關系的操作最重要的是事務問題，這一點很重要，很重要，真的很重要！LeanCloud 官方文檔中有提到 MongoDB 不支持事務，并建議對事務有強烈需求的開發者使用其他折中方式來實現。我們的支付必須用事務，我們經過 N 輪討后論設計了一套基于 LeanCloud 的支付場景的通用解決方案，也許其他團隊比我們做得好，在這里還是分享下我們的一些見解吧。

我們在用戶表 _User 中加入了一個 paylogs 字段，類型是 Array，主要用于存放著每一次支付日志的 id，用它來判斷用戶的賬戶 account 的值，比如錢扣沒扣，加沒加等情況。因為在支付過程中不能保證每一次操作都成功，所以還要引入一個日志表 log 來做數據的一致性，保證用戶資金變動與實際相符。log 表里有一個「狀態」字段 state，它的取值為 0 ~ 5，主要是從發起支付開始，生成 order 表，生成 log 表等，并記錄 log 的狀態，后續所有的業務都要根據 state 的狀態執行不同的業務操作，不管在哪個狀態出問題都可以根據 log表的 state 狀態重復執行相應的業務操作，從而保證支付過程的數據一致性！

比如在充值的時候，用戶扣費成功后，修改用戶的 account 值成功了，但在修改 state 字段時失敗了，下一次再執行時又怎么判斷用戶的 account 值已經改變了呢？這個問題真是太重要了，這就要用到那個 paylogs 字段，判斷 paylogs 字段是否有值，八戒影院有值說明剛才用戶的 account 值已經操作過了，此時可以不用操作，如果沒有再進行操作。這里利用了 LeanCloud 數據存儲接口的按條件更新數據的功能（使用 query 參數）來保證操作的原子性，從而也解決了并發問題！這個 query 參數真得要夸一下，在 LeanCloud 還沒提供這個功能之前，我們只能采用 log 表中的新舊值比對來解決數據一致問題，但無法避免并發問題，這樣當用戶數據錯了，我們只能認為支付失敗，然后進入人工干預環節，很是麻煩。

最后再說說我們和 LeanCloud 的相遇。最初是通過朋友圈知道了 LeanCloud，后來就一直關注著。也試過一些項目，發現開發應用真是方便許多。原本大量的后端需求都要自己研發，現在都省了，只需要專注于寫應用端的代碼，效率自然會提高一倍以上，開發迭代速度也上去了。當然也有過顧慮，生怕遇到一些特殊場景 LeanCloud 滿足不了那我們就悲劇了！但后來看到一些知名的應用都在用 LeanCloud，心里也就安穩了，有前輩們踩過坑，有 LeanCloud 的技術支持做后盾，我們就這樣選定了 LeanCloud。

隨著項目的進行，我們從傳統的后端服務接口開發變成了面向「Document」開發，服務端工作減輕了不少。雖然在數據設計中遇到一些復雜結構的問題，比如 Pointer 和 Relations 的問題。記得當時 Array 不支持 Pointer 的 include，所以考慮用 Relations，但在 LeanCloud 社區中又看到幾個相關問題都推薦使用 Array 或者 Pointer，后來通讀了相關文檔對數據模型有了更深的理解，問題也就少了，所以說全面了解文檔是至關重要的。