我寫的一個項目用到了支付，然後面試官照着支付這塊開始了一輪攻擊。
大概支付流程流程：
這個系統沒有往死了打，就問了幾個小問題。
1.如果在異步回調判斷結果落庫過程中因爲網絡抖動落庫失敗怎麼辦？
我回答的是如果我落庫失敗的話，就把該訂單放入本地緩存（可以用ConcurrentHashMap），然後通過定時任務把緩存的數據寫回數據庫。
2.如果在這時候用戶重複提交咋辦？
我第一反應居然是誰會這麼傻。。。 言歸正傳，這個可以在用戶提交訂單的時候，先去本地緩存中去查找有沒有該訂單，如果有了就把用戶返回去，如果就進行修改 （直接進行數據庫修改，不進緩存，如果修改失敗進緩存）
這個項目面試官還是手下留情了，事後我想這個問題想起來幾個把自己打死的問題。
1.如果服務器宕機了怎麼辦？
死亡一問（我q我自己），先說一個比較有思路的，在回調給你以後，你沒有辦法去修改數據庫 ，把訂單存在了本地緩存，這時候服務器發生宕機，那麼本地緩存的數據就丟失了。
這樣我們可以通過把數據存到redis中，redis配主從加哨兵，這下數據丟不了吧。
那網絡問題連不上redis怎麼辦（快把我打死）
其實說了這麼多問題也沒有完美的辦法，如果保證數據完整性 ，那麼就一定性能上犧牲。
後來通過通過仔細查看支付寶api還有琢磨，想出來一個還算可以解決問題的方式：
流程：
1.用戶發起支付
2.將訂單緩存到redis（代表這個訂單已經發起支付，如果用戶再次支付可以在redis中看有沒有發起支付）
3.調用sdk進行扣款，等待回調。
4.判斷回調結果，如果成功則更新數據庫，然後刪除redis中該訂單的緩存。如果失敗則直接刪除redis緩存。
5.在更新數據的時候如果發生網絡抖動，我們可以直接把redis修改掉，然後定時任務掃描redis中數據。
如果redis連接不上，存入訂單的時候失敗，我們可以直接返回給用戶false。然後redis採用主從加哨兵。
這時候就還有一個服務器可能宕機的問題了，這個問題的主要難點就在於我們進行了扣款請求，然後回調沒來呢，服務器宕機了。這個問題我們這裏還真沒辦法解決，但是支付寶已經爲你做好了。
所以我們可以對服務器進行心跳檢測，然後發現宕機，及時發送報警郵件。這樣我們還有補救的機會。
主要是自己項目比較小，面試官可能都覺得沒啥可問的。哎。