php 網(wǎng)絡(luò)通信 數(shù)據(jù)傳輸 補償提交

1. POST 之前檢查一下支付 LOG 表，是否已經(jīng)支付訂單
2. POST DATA 成攻后寫 支付訂單成攻寫入 LOG 標(biāo)志

按這個流程已經(jīng)解決。

1.http是基于TCP的應(yīng)用層協(xié)議，是可靠的。
2.交易的時候做transaction。
3.用同步，不要異步，可防止用戶手快連續(xù)點了兩次。

最近剛好碰到兩個案例和這個問題類似：

• 案例一：前幾天去飯店吃飯，使用手機點餐就遇到了這個問題?？赡苁且驗樗麄兿到y(tǒng)問題，第一次支付提示我系統(tǒng)異常，然后我再次支付后過幾分鐘收到兩條信用卡支付短信。
• 案例二：公司有個同事做的某兌換接口，有一段時間大量出現(xiàn)同一張兌換券短時間內(nèi)被重復(fù)兌換使用情況。

針對這些類似的業(yè)務(wù)場景，我們運用事務(wù)的思想要保證業(yè)務(wù)的唯一性，具體來說就是：同樣的數(shù)據(jù)不讓重復(fù)提交，同樣的操作只執(zhí)行一次，那么問題就來了，理論說起來簡單，到底怎么實現(xiàn)呢？

首先，理解三個重要概念：

• 操作加鎖
• 唯一業(yè)務(wù)ID
• 獲取業(yè)務(wù)處理結(jié)果

我們的最終目的是使用上面三個概念創(chuàng)建一種靈活，健壯的業(yè)務(wù)處理服務(wù)。

操作加鎖：在業(yè)務(wù)進行處理的過程中在各個關(guān)鍵位置加鎖，比如，客戶端發(fā)起創(chuàng)建訂單請求，在用戶點擊創(chuàng)建按鈕，數(shù)據(jù)發(fā)出去之前對創(chuàng)建按鈕進行加鎖，并給出相關(guān)提示（交互友好），防止二次點擊。服務(wù)器接收到用戶請求后，對該用戶進行加鎖（針對該服務(wù)或者用戶進行操作鎖定）。從而一定程度保證同一不會重復(fù)提交。這種方式比較常見與很多框架內(nèi)置方重復(fù)提交的token令牌機制。

唯一業(yè)務(wù)ID：為每個操作請求創(chuàng)建唯一的業(yè)務(wù)處理ID。這種做法常見于銀行交易系統(tǒng)，以一個中間狀態(tài)機制的形式存在，從而每個業(yè)務(wù)操作狀態(tài)對各個系統(tǒng)保持透明。

獲取業(yè)務(wù)處理結(jié)果：這個操作依賴于上面的唯一業(yè)務(wù)ID機制，客戶端根據(jù)業(yè)務(wù)操作ID主動獲取業(yè)務(wù)處理結(jié)果。

舉個實際使用場景栗子：

用戶X通過銀行A向銀行B轉(zhuǎn)一筆錢，有時候可能銀行系統(tǒng)繁忙錢并不能實時到賬，當(dāng)然銀行A肯定不能告訴他的用戶 ’ 當(dāng)前系統(tǒng)繁忙等不忙的時候你再來' 吧，銀行A會告訴用戶轉(zhuǎn)賬進行中，請耐心等候。那銀行A實際處處理這個業(yè)務(wù)的過程是怎么樣的呢，

首先，銀行創(chuàng)建業(yè)務(wù)待處理記錄，創(chuàng)建用戶轉(zhuǎn)賬請求記錄并關(guān)聯(lián)待處理記錄ID，這個待處理記錄ID就是上面說的唯一業(yè)務(wù)ID，

然后，銀行的轉(zhuǎn)賬處理子系統(tǒng)根據(jù)記錄依次的處理轉(zhuǎn)賬業(yè)務(wù)。關(guān)鍵點來了，銀行A如何保證用戶X轉(zhuǎn)的錢一定到銀行B，并且只轉(zhuǎn)一次呢？整個交互流程大致是：銀行A向銀行B發(fā)起待轉(zhuǎn)賬請求（這是還沒有真的轉(zhuǎn)錢過去），銀行B收到請求，創(chuàng)建一個收錢業(yè)務(wù)記錄，并將業(yè)務(wù)ID（也是前面說的唯一業(yè)務(wù)ID）返回給銀行A，銀行A拿到記錄ID，執(zhí)行轉(zhuǎn)賬操作，并將相關(guān)數(shù)據(jù)與前面拿到的記錄ID發(fā)送給銀行B，然后按照約定的規(guī)則查詢轉(zhuǎn)賬結(jié)果，直到銀行B返回數(shù)據(jù)告訴銀行A收到錢啦。

最后，銀行A更新相關(guān)待處理記錄，更新用戶X轉(zhuǎn)賬請求記錄。這樣就完成一筆轉(zhuǎn)賬業(yè)務(wù)處理。

當(dāng)然啦，把思路延伸一下，這個思路可應(yīng)用的場景不僅僅是支付業(yè)務(wù)。

首先你可以在發(fā)起支付的頁面生成一個token,用來驗證訂單唯一性
其次你可以你可以在支付回調(diào)的附加參數(shù)加入訂單編號等做校驗