崔陽

文章編號：2096-1472（2022）-02-14-04

DOI：10.19644/j.cnki.issn2096-1472.2022.002.004

摘? 要：首先分析了當前掃碼支付系統(tǒng)的性能需求及存在的不足，在此基礎上為掃碼支付系統(tǒng)設計了一種基于MQTT協(xié)議、SOCKS5協(xié)議和JSON數(shù)據(jù)格式的數(shù)據(jù)交互層。該交互層優(yōu)化了掃碼支付系統(tǒng)服務器與商戶終端數(shù)據(jù)庫之間的數(shù)據(jù)交互模式，并集成了訪問代理、身份驗證等多項功能，可以使系統(tǒng)的自動化程度進一步提高，更靈活地部署于不同的環(huán)境。實踐結果表明，在廣東省某連鎖超市使用設置了數(shù)據(jù)交互層的掃碼支付系統(tǒng)后，響應時間明顯縮短，準確率和安全性也有較大提高。因此，該系統(tǒng)具有較好的推廣價值。

關鍵詞：掃碼支付系統(tǒng);數(shù)據(jù)交互層;MQTT;SOCKS5

中圖分類號：TP319? ? ?文獻標識碼：A

Design and Application of Data-interaction Layer in QR?Code-scanning Payment System based on MQTT

CUI Yang

（College of Applied Technology， China University of Labor Relations， Beijing 100048， China）

cuiyang14@163.com

Abstract： This paper proposes to design a data-interaction layer based on MQTT （Message Queuing Telemetry Transport）， SOCKS5 and JSON （JavaScript Object Notation） for QR （Quick Response） Code-scanning payment system， in view of the performance requirements and the defects of the current QR Code-scanning payment system. The proposed data-interaction layer optimizes data-interaction mode between QR code-scanning payment system server and sellers' terminal database. It also integrates multiple functions such as access agency， identity verification， etc.， which further improves the automation of the system and make the system more flexible to be deployed on different occasions. Practical results show that after using a QR code-scanning payment system with data- interaction layer in a supermarket chain in Guangdong Province， the response time is significantly shortened， and the accuracy and security are also greatly improved. Therefore， the proposed system is quite worthy of promotion.

Keywords： QR code-scanning payment system; data-interaction layer; MQTT; SOCKS5

1? ?引言（Introduction）

掃碼支付是近年正在快速推廣的一種新型購物支付模式。與傳統(tǒng)的支付模式相比，掃碼支付在降低商戶成本、節(jié)省消費者時間、建立商戶與消費者之間有效聯(lián)系機制等方面具有極大的優(yōu)勢^[1]。

當前很多企業(yè)都推出了自己的掃碼支付系統(tǒng)，但這些系統(tǒng)在應用中也逐漸暴露出了一些不足之處，其中之一就是系統(tǒng)的數(shù)據(jù)交互模式仍有待提高。掃碼支付系統(tǒng)以物聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)等為基礎，在這些領域中已經(jīng)有多種比較切實可用的數(shù)據(jù)交互技術，例如基于人工蜂群算法的物聯(lián)網(wǎng)數(shù)據(jù)可靠性傳輸方法^[2]、基于微服務架構的物聯(lián)網(wǎng)中間件方法^[3]、“SIP over MQTT”優(yōu)化傳輸機制^[4]、基于網(wǎng)絡編碼的能量受限數(shù)據(jù)傳輸機制^[5]等。本文以這些技術思想為基礎，為掃碼支付系統(tǒng)設計了一個專用的數(shù)據(jù)交互層，以提高掃碼支付系統(tǒng)服務器與商戶終端機之間數(shù)據(jù)交互的效率，更好地保障掃碼支付的過程。

2? ?掃碼支付系統(tǒng)的性能分析（Performance analysis of QR code-scanning payment system）

掃碼支付系統(tǒng)的硬件部分主要由服務器、商戶終端機、用戶移動設備等組成。其中，服務器負責處理訂單;商戶終端機負責存儲商品信息、用戶信息和訂單信息;用戶移動設備負責為用戶提供使用掃碼支付系統(tǒng)的界面。系統(tǒng)中大部分的數(shù)據(jù)交互操作發(fā)生在服務器與商戶終端機之間。

2.1? ?系統(tǒng)運行的基本流程

各種掃碼支付系統(tǒng)雖然在實現(xiàn)上有所差別，但運行過程基本相同：用戶首先通過移動設備上安裝的APP（或小程序）接入系統(tǒng)，再依次掃描商品包裝上的二維碼生成訂單。訂單信息和付款請求由APP提交到系統(tǒng)服務器，服務器收到后根據(jù)自身存儲的商品價格、折扣和用戶級別等信息計算出訂單應付金額，生成支付碼并發(fā)回給APP。APP接收并顯示支付碼，供用戶結賬使用。之后APP再將支付結果（成功、異常、失敗等）發(fā)回服務器。如果訂單已被正確支付，則服務器還需將訂單信息寫入商戶終端機的數(shù)據(jù)庫^[6]。

綜合而言，系統(tǒng)以下幾方面的性能對用戶支付體驗度有明顯影響：

第一，響應速度。自助支付的最大優(yōu)勢在于節(jié)省時間。如果系統(tǒng)每次響應和處理訂單的時間過長，會導致用戶的購物意愿降低。因此系統(tǒng)應具備一定的實時性特征，將響應速度嚴格控制在用戶的容忍范圍內(nèi)。

第二，準確性。商品價格波動比較頻繁，因此系統(tǒng)在處理訂單時必須按最新的商品價格和折扣計算付款金額，保證用戶和商戶在交易中不會蒙受損失。

第三，安全性。掃碼支付是一種金融活動^[7]，因此過程中涉及的訂單、交易金額和用戶身份等重要數(shù)據(jù)必須保證安全，防止泄露。

2.2? ?當前系統(tǒng)存在的不足

目前，很多掃碼支付系統(tǒng)的服務器仍采用直接訪問商戶終端機數(shù)據(jù)庫并控制數(shù)據(jù)讀寫的工作模式。這種模式雖然簡單易行，但也可能會導致一些問題：首先是在數(shù)據(jù)讀寫量較大時會加重服務器的負載，降低響應速度，且不利于數(shù)據(jù)的安全保護。其次是服務器中信息的更新難以做到及時和自動化，有時還要依賴人工完成，容易使服務器在計算支付金額時因信息過期而出錯。另外，當服務器與數(shù)據(jù)庫處于不同網(wǎng)絡時，可能會因防火墻設置等問題出現(xiàn)無法訪問的情況。可見，服務器與商戶終端機這種數(shù)據(jù)交互模式對系統(tǒng)的各項性能都有消極影響。

解決這一問題行之有效的方法是為系統(tǒng)增加一個數(shù)據(jù)交互層，將服務器與數(shù)據(jù)庫操作徹底分離。這樣就可以優(yōu)化系統(tǒng)結構，使系統(tǒng)的響應速度、準確性和安全性三個方面均能得到提高。

3 數(shù)據(jù)交互層的設計與實現(xiàn)（Design and implementation of data-interaction layer）

掃碼支付系統(tǒng)數(shù)據(jù)交互層遵循了物聯(lián)網(wǎng)中間件的設計思想，與系統(tǒng)其他部分耦合度低，開發(fā)過程可控且易于部署^[8]。數(shù)據(jù)交互層使系統(tǒng)的服務器與商戶終端機之間彼此透明，所有數(shù)據(jù)交互操作均經(jīng)過數(shù)據(jù)交互層完成。

3.1? ?功能設計

為更靈活地滿足不同類型客戶端的功能需求，數(shù)據(jù)交互層通常部署在商戶終端機上。經(jīng)改進后，掃碼支付系統(tǒng)的服務器與數(shù)據(jù)庫工作模式如圖1所示?？梢钥闯觯谠鲈O數(shù)據(jù)交互層后，以往服務器與數(shù)據(jù)庫的直接訪問模式就改為服務器—數(shù)據(jù)交互層—數(shù)據(jù)庫的三級訪問模式。數(shù)據(jù)庫的連接、讀寫等工作都交由數(shù)據(jù)交互層完成，服務器只需接收或轉(zhuǎn)發(fā)數(shù)據(jù)即可，不再直接干預低速且頻繁的數(shù)據(jù)庫操作。這樣不但可以減輕服務器的負載，而且數(shù)據(jù)上傳和寫入的自動化程度也得到了很大提高。

為了滿足掃碼支付系統(tǒng)的性能需求，數(shù)據(jù)交互層應具備以下基本功能：

（1）商戶終端機身份驗證。當數(shù)據(jù)交互層在商戶終端機啟動時，將向服務器發(fā)送MD5模式加密的身份信息。服務器驗證并確認無誤后，數(shù)據(jù)交互層才能與服務器和數(shù)據(jù)庫建立安全連接，并執(zhí)行后續(xù)操作，從而減少數(shù)據(jù)被劫持的風險。

（2）數(shù)據(jù)定時上傳。商戶終端機數(shù)據(jù)庫中保存的商品價格、折扣、庫存等信息變化非常頻繁，服務器在處理訂單時必須以最新信息為依據(jù)，否則會造成支付金額計算錯誤。數(shù)據(jù)交互層的數(shù)據(jù)定時上傳模塊可以根據(jù)預先設定的每次上傳間隔時間，按時自動讀取商戶終端機數(shù)據(jù)庫中最新的商品信息，并上傳至服務器，確保服務器的商品信息能夠及時更新。

（3）訂單寫入。用戶支付成功的訂單需要及時記錄到數(shù)據(jù)庫。數(shù)據(jù)交互層接收服務器發(fā)送來的訂單信息并寫入商戶終端機數(shù)據(jù)庫。由于在同一時刻可能會有大量訂單到達，因此數(shù)據(jù)交互層應以異步模式確保所有訂單都正確寫入數(shù)據(jù)庫。

（4）訪問代理。服務器與商戶終端機可能在不同的網(wǎng)絡中，無法相互訪問。這時數(shù)據(jù)交互層的訪問代理功能仍可保證服務器與商戶終端機正常建立連接。

3.2? ?實現(xiàn)過程

數(shù)據(jù)交互層的實現(xiàn)過程主要包括以下幾個關鍵模塊：

（1）數(shù)據(jù)交互層與服務器的通訊。由于數(shù)據(jù)交互層與數(shù)據(jù)庫同在一臺商戶終端機上，因此以SQL模式訪問即可。與服務器的通訊則比較復雜，這里選用的是MQTT協(xié)議。MQTT（Message Queuing Telemetry Transport， 消息隊列遙測傳輸）協(xié)議是一種構建在TCP/IP協(xié)議上、基于發(fā)布/訂閱模式的“輕量級”通訊協(xié)議。該協(xié)議提供了一種一對多的消息發(fā)布模式，定義了發(fā)布者、代理者和訂閱者三種身份^[9]，如圖2所示。

其中，客戶端是消息的發(fā)布者和訂閱者，服務器是消息的代理者。通過這種機制，MQTT協(xié)議消除了通訊程序之間的耦合性，將信息冗余降至最小，可以在低開銷、低帶寬的情況下提供實時可靠的消息服務^[10]。目前MQTT協(xié)議已被廣泛用于消息推送^[11]、遠程監(jiān)控[^12]及實時通信^[13]等領域，其特性非常符合掃碼支付系統(tǒng)應用環(huán)境的要求。

在MQTT協(xié)議框架下，數(shù)據(jù)交互層就相當于客戶端，向服務器定時上傳商品信息時充當發(fā)布者角色，從服務器接收訂單時充當訂閱者角色。服務器將用戶成功支付的訂單信息發(fā)送至數(shù)據(jù)交互層，充當代理者角色。訂閱/發(fā)布模式可以保證當用戶的移動設備將訂單信息發(fā)送至服務器時，數(shù)據(jù)交互層能夠自動同步獲取該訂單信息并寫入數(shù)據(jù)庫。在這一過程中，服務器只需轉(zhuǎn)發(fā)相應的訂單信息或接收上傳的商品信息，不再負責數(shù)據(jù)庫操作，因此大幅降低了負載。定義的數(shù)據(jù)交互層與服務器通訊主題如表1所示。

MQTTnet封裝了一個實現(xiàn)客戶端與服務端通訊的類MqttClient，類中定義了一個結構體MqttClientTcpOptions，用于設置數(shù)據(jù)交互層與服務器建立MQTT連接的參數(shù)：

public struct MqttClientTcpOptions

{

Server;? ? ? ? ? ? // 服務器地址

Port;? ? ? ? ? ? ? // 服務器端口

ClientId;? ? ? ? ? ?// 客戶端ID

UserName;? ? ? ? ?// 用戶名

Password;? ? ? ? ? // 密碼

KeepAlivePeriod;? ? // 保持連接時長

CleanSession;? ? ?// 斷開時是否保留會話

DefaultCommunicationTimeout;

// 默認連接超時時長

}

設置好MqttClientTcpOptions結構體中各項參數(shù)后，就可以調(diào)用MqttClient類的ConnectAsync方法發(fā)起與服務器的連接，成功后將建立數(shù)據(jù)交互層與服務器的會話連接。數(shù)據(jù)定時上傳和從服務器接收訂閱的訂單信息分別使用MqttClient類PublishAsync和SubscribeAsync方法。

由于MQTTnet為開源類庫，因此可以方便地在其中添加對SOCKS5協(xié)議的支持。SOCKS5是一種會話層訪問代理協(xié)議，能夠使數(shù)據(jù)交互層與服務器的通訊在處于不同網(wǎng)絡或有防火墻設置等情況下仍能正常進行^[14]。可以在MqttClientTcpOptions結構體中增加ProxyServer和ProxyServerPort參數(shù)，指定代理服務器的名稱和端口。

（2）數(shù)據(jù)格式的定義。數(shù)據(jù)交互層與服務器之間通訊的數(shù)據(jù)格式采用JSON格式。相對于XML，JSON的層次結構更為簡潔清晰，解析和傳輸效率較高^[15]。例如，數(shù)據(jù)定時上傳的JSON格式為：

{

"command_type"： " schedule_data"，

"data"：[{

"upc_code"：，

"product_name"： ""，

"price"： ""，

"member_price"： ""，

"unit： ""，

}]

}

當數(shù)據(jù)庫中的商品信息發(fā)生變化時，只需在數(shù)據(jù)格式中作相應修改即可。

（3）連接異常處理。數(shù)據(jù)交互層在運行過程中定時檢測與服務器的連接狀態(tài)。當發(fā)現(xiàn)中斷時，將立即嘗試重新連接服務器。如果是在數(shù)據(jù)上傳期間發(fā)生中斷，則連接成功后再次進行上傳操作，以避免服務器出現(xiàn)數(shù)據(jù)不一致現(xiàn)象。當重新嘗試次數(shù)達到最大值仍未能恢復連接時，模塊將向系統(tǒng)管理員發(fā)出警告。

4? 數(shù)據(jù)交互層的應用（Application of data-interaction layer）

掃碼支付系統(tǒng)數(shù)據(jù)交互層的開發(fā)環(huán)境為Visual Studio 2018，開發(fā)語言為C#。服務器和商戶終端機的運行環(huán)境為64 位Windows 10，數(shù)據(jù)庫為SQL Server。

數(shù)據(jù)交互層劃分為服務器連接、身份驗證、數(shù)據(jù)定時上傳、數(shù)據(jù)寫入和MQTT連接監(jiān)測等幾個主要模塊。數(shù)據(jù)交互層啟動后，首先在網(wǎng)絡連接正常的情況下檢驗商戶終端機與服務器是否需要啟用代理訪問。之后嘗試與服務器建立MQTT連接，若成功則向服務器發(fā)送商戶終端機名稱、密碼等身份驗證信息。若通過則繼續(xù)向服務器發(fā)送訂閱信息，并完成初始化工作，包括計時器置0，創(chuàng)建數(shù)據(jù)上傳線程和數(shù)據(jù)寫入線程，以及一些參數(shù)值的設定等;否則終止之前建立的MQTT連接。在沒有遇到系統(tǒng)退出或故障時，數(shù)據(jù)交互層將一直處于運行狀態(tài)。

數(shù)據(jù)交互層開始運行時，數(shù)據(jù)上傳線程處于阻塞態(tài)。當上傳時間點到達時，線程恢復運行，以SQL模式連接數(shù)據(jù)庫并讀取數(shù)據(jù)，轉(zhuǎn)換為JSON格式后再根據(jù)預先設定的MQTT通訊主題為數(shù)據(jù)添加頭部信息，之后上傳至服務器。如果線程收到服務器的確認信息，則重新進入阻塞態(tài)并開始新一輪計時，反之則嘗試再次上傳數(shù)據(jù)。當重傳次數(shù)達到最大值時將放棄本次時間點的上傳任務，并向管理員發(fā)出警告，由管理員決定本次改由人工模式更新還是等待下一次上傳時間點再自動更新。

訂單數(shù)據(jù)寫入過程則略復雜。由于同一時刻可能有多個商戶終端機訂閱的數(shù)據(jù)由服務器轉(zhuǎn)發(fā)至數(shù)據(jù)交互層，為防止出現(xiàn)不同步問題導致的讀寫錯誤，必須設置一個數(shù)據(jù)緩沖隊列，作為臨界資源加以保護。數(shù)據(jù)緩沖隊列為空時，數(shù)據(jù)寫入線程處于阻塞態(tài)。當數(shù)據(jù)到達時先送入數(shù)據(jù)緩沖隊列，同時數(shù)據(jù)寫入線程恢復運行，從隊列中讀取數(shù)據(jù)并解析數(shù)據(jù)頭部信息中的MQTT主題，判斷是否為商戶終端機訂閱的訂單數(shù)據(jù)，若是則將訂單數(shù)據(jù)轉(zhuǎn)換格式后寫入數(shù)據(jù)庫。圖3給出了完整的掃碼支付系統(tǒng)交互圖。

目前，該系統(tǒng)已在廣東省某大型連鎖超市中得到了應用。數(shù)據(jù)交互層的引入改變了以往人工模式更新服務器信息的情況，且在網(wǎng)絡連接正常的情況下，每次定時上傳18，000 條商品信息至服務器數(shù)據(jù)緩沖區(qū)的時間縮短至40—50 秒。同時，數(shù)據(jù)交互層可以正確地將多個用戶發(fā)送至服務器的訂單依次寫入數(shù)據(jù)庫。實踐證明，數(shù)據(jù)交互層有效地提高了掃碼支付系統(tǒng)的效率和準確性，而且對服務器、商戶終端機和數(shù)據(jù)庫的運行均沒有明顯影響。

5? ?結論（Conclusion）

掃碼支付系統(tǒng)是“智慧銷售”系統(tǒng)的重要組成部分，數(shù)據(jù)交互層的設置給出了一種提高掃碼支付系統(tǒng)性能的新思路。實際情況表明，數(shù)據(jù)交互層使掃碼支付系統(tǒng)在響應速度、準確性和安全性等方面均有所提高。今后的工作主要集中在對數(shù)據(jù)交互層的改進和新功能擴展等方面。

參考文獻（References）

[1] 陳平，高懷恩，陳炯標，等.基于物聯(lián)網(wǎng)的智慧超市[J].電視技術，2013，37（S1）：57-60.

[2] YI L， PENG Y. internet of things transmission and network reliability in complex environment[J]. Computer Communications， 2020， 150（1）：757-763.

[3] 吳斌峰.基于微服務架構的物聯(lián)網(wǎng)中間件設計[J].計算機科學， 2019，46（S1）：580-584，604.

[4] 楊海波，馬榮榮，張偉，等.面向移動互聯(lián)網(wǎng)的“SIP over? MQTT”優(yōu)化傳輸機制研究[J].小型微型計算機系統(tǒng)，2017，38（04）：776-780.

[5] 黃辰，李可維，張偉，等.無線物聯(lián)網(wǎng)中基于網(wǎng)絡編碼的能量受限數(shù)據(jù)傳輸機制[J].電子學報，2013，41（1）：144-147.

[6] 汪天星，程耕國.基于B/S的掃碼支付平臺的設計[J].現(xiàn)代電子技術，2018，41（22）：49-52，58.

[7] 單美靜.基于AHP法的移動支付安全風險評估[J]計算機科學，2015，42（S2）：368-371.

[8] 王冰，陳庭貴.基于高性能消息管理機制的物聯(lián)網(wǎng)中間件設計方法[J].計算機工程與應用，2017，53（16）：89-97，186.

[9] 陽旺，樊振宇，吳帆.基于6LoWPAN與MQTT的無線傳感網(wǎng)絡設計[J].國防科技大學學報，2019，41（01）：161-168.

[10] 張玉杰，張海濤，張婷婷.基于MQTT的物聯(lián)網(wǎng)系統(tǒng)消息發(fā)布/訂閱方法研究[J].電視技術，2017，41（Z3）：83-87.

[11] 姜妮，張宇，趙志軍.基于消息隊列遙測傳輸?shù)耐扑拖到y(tǒng)[J].計算機工程，2015，41（9）：1-6.

[12] 馬匯海，張君燕，孟彥京.基于云平臺的高頻搖振器監(jiān)控系統(tǒng)的設計與實現(xiàn)[J].中國造紙，2018，37（10）：48-53.

[13] 諶建飛，鄧敏，唐俊龍，等.實時大規(guī)模遠程實驗通信方案研究[J].計算機工程與應用，2018，54（19）：94-100.

[14] 俞定國，舒明磊，譚成翔.基于Socks5代理的移動SSL VPN系統(tǒng)研究與實現(xiàn)[J].計算機科學，2011，38（1）：119-121，144.

[15] 陳瑋，賈宗璞.利用JSON降低XML數(shù)據(jù)冗余的研究[J].計算機應用與軟件，2012，29（9）：188-189，206.

作者簡介：

崔? ?陽（1979-），男，博士，講師.研究領域：知識工程與知識發(fā)現(xiàn).

基金項目：中國勞動關系學院科研項目（20XYJS004）.