[發(fā)明專利]高并發(fā)通用支付方法

有效

• 申請?zhí)枺?/td>: 201410262934.2
• 申請日: 2014-06-13
• 公開（公告）號: CN104050564B
• 公開（公告）日: 2017-11-14
• 發(fā)明（設(shè)計）人: 封維波;楊超
• 申請（專利權(quán)）人: 中國民航信息網(wǎng)絡(luò)股份有限公司
• 主分類號: G06F17/00
• 分類號: G06F17/00
• 代理公司: 北京瑞思知識產(chǎn)權(quán)代理事務(wù)所(普通合伙)11341
• 代理人: 李濤,袁紅紅

技術(shù)領(lǐng)域

本發(fā)明涉及電子支付技術(shù)領(lǐng)域，尤其涉及一種高并發(fā)通用支付方法。

背景技術(shù)

隨著電子客票的推廣和普及，航空公司為適應(yīng)市場需求的變化，也迫切希望其購票款可直接通過信用卡完成支付。主機(jī)CCV指令是一個信用卡驗證指令，現(xiàn)在系統(tǒng)中絕大多數(shù)的驗證操作都是通過SITA的CCA系統(tǒng)（信用卡授權(quán)系統(tǒng)）進(jìn)行的，如圖1所示。

CCV指令直接調(diào)用CCA，將逐步過渡到調(diào)用航信自己的開放端系統(tǒng)實現(xiàn)與各信用卡授權(quán)系統(tǒng)、銀行及其他第三方支付平臺的直連，這樣可以大大節(jié)省CCA系統(tǒng)使用費(fèi)用，并收取服務(wù)費(fèi)。

在卡支付驗證后臺系統(tǒng)領(lǐng)域，一般采用的都是基于TUXEDO交易中間件的支付驗證架構(gòu)，為了滿足外部系統(tǒng)同步調(diào)用的需求，常用的架構(gòu)設(shè)計中往往存在低并發(fā)、可擴(kuò)展性差、通用性差的缺點(diǎn)。

缺點(diǎn)一：低并發(fā)：外部系統(tǒng)調(diào)用支付驗證服務(wù)時采用的是Tuxedo同步請求，每一個同步請求就會占用一個Tuxedo驗證服務(wù)，通常驗證服務(wù)又會調(diào)用其它的驗證系統(tǒng)進(jìn)行驗證，所以一次驗證通常耗費(fèi)的時間可能會比較長。如果系統(tǒng)完全依賴于增加TUXEDO驗證服務(wù)的個數(shù)來提高并發(fā)處理能力，則系統(tǒng)的并發(fā)處理能力將嚴(yán)重依賴于Tuxedo驗證服務(wù)的個數(shù)。如果驗證服務(wù)個數(shù)小于并發(fā)請求個數(shù)時，將導(dǎo)致請求堆積在處理隊列中，形成一個性能的拐點(diǎn)，單個請求的處理時間將會在這個拐點(diǎn)陡然增加。

缺點(diǎn)二：可擴(kuò)展性差：支付系統(tǒng)根據(jù)卡的類型不同，會調(diào)用不同的外部系統(tǒng)進(jìn)行驗證，調(diào)用外部系統(tǒng)的方法根據(jù)實際情況也會不同，可能是Socket也可能是MQ。因此擴(kuò)展性差會表現(xiàn)為以下兩點(diǎn)，一是在不影響現(xiàn)有服務(wù)的情況下，不能方便地接入其他服務(wù)來增強(qiáng)現(xiàn)有系統(tǒng)的功能；二是不能方便的擴(kuò)展不同的鏈路，不能提供一個統(tǒng)一的鏈路管理來提供不同的鏈接方式，他們的鏈接往往是針對一個外部交易平臺重新編寫程序來提供一個服務(wù)來進(jìn)行處理，可擴(kuò)展性較差。

缺點(diǎn)三：通用性差：一般的支付系統(tǒng)都是自成體系，往往都只是針對一家銀行或者信用卡授權(quán)中心進(jìn)行獨(dú)立處理，系統(tǒng)的通用性較差，增加新的卡類型往往需要重新編寫所有代碼，這會大大增加人力成本。

發(fā)明內(nèi)容

有鑒于此，本發(fā)明提供了一種高并發(fā)通用支付方法，能夠通過同時處理多個交易請求實現(xiàn)高并發(fā)；并通過對與外部交易系統(tǒng)的交互采用統(tǒng)一的鏈路管理的方式實現(xiàn)了高擴(kuò)展性。

本發(fā)明提供的一種高并發(fā)通用支付方法，包括：

步驟1：當(dāng)系統(tǒng)入口服務(wù)接收到同步請求時，生成用于保存所述同步請求的結(jié)構(gòu)體TransInfo對象，并向所述TransInfo對象分配序列號，然后將所述序列號保存于TransInfo對象中；

步驟2：將所述TransInfo對象放入TransInfo處理隊列；

步驟3：將所述TransInfo對象tpforward服務(wù)，從而進(jìn)入服務(wù)的請求隊列，等待處理，并將所述TransInfo對象的序列號保存在所述tpforward的參數(shù)中。

所述方法還包括：構(gòu)建發(fā)送線程以遍歷所述TransInfo處理隊列，并根據(jù)所述TransInfo處理隊列中的TransInfo對象的狀態(tài)進(jìn)行處理，包括：刪除TransInfo處理隊列中狀態(tài)為無效的TransInfo對象；發(fā)送TransInfo處理隊列中狀態(tài)為發(fā)送前的TransInfo對象。

當(dāng)TransInfo處理隊列為空時，所述發(fā)送線程會進(jìn)行阻塞以等待新的TransInfo對象被放入所述TransInfo處理隊列中。

所述方法還包括：構(gòu)建接收線程以遍歷所述TransInfo處理隊列，并將服務(wù)返回的數(shù)據(jù)放入所述TransInfo處理隊列中對應(yīng)的TransInfo對象中，并相應(yīng)修改所述TransInfo對象的狀態(tài)為已接收。

所述方法還包括：系統(tǒng)入口服務(wù)調(diào)用自身的tpforward請求到達(dá)時，提取所述tpforward請求中保存的TransInfo對象的序列號，從TransInfo隊列中找到對已的TransInfo對象，如果所述對已的TransInfo對象的狀態(tài)為已接收，則將接收到的結(jié)果tpreturn（返回請求）給外部系統(tǒng)，并將所述對已的TransInfo對象的狀態(tài)更新為無效，結(jié)束一次外部請求過程；其中，所述tpforward請求即tpforward服務(wù)的TransInfo對象所保存的同步請求。