基于MQTT的掃碼支付系統數據交互層的設計與應用

崔陽

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

DOI：10.19644/j.cnki.issn2096-1472.2022.002.004

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

關鍵詞：掃碼支付系統;數據交互層;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）

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

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

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

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

2.1? ?系統運行的基本流程

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

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

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

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

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

2.2? ?當前系統存在的不足

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

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

3 數據交互層的設計與實現（Design and implementation of data-interaction layer）

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

3.1? ?功能設計

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

為了滿足掃碼支付系統的性能需求，數據交互層應具備以下基本功能：

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

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

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

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

3.2? ?實現過程

數據交互層的實現過程主要包括以下幾個關鍵模塊：

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

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

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

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

public struct MqttClientTcpOptions

{

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

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

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

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

Password;? ? ? ? ? // 密碼

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

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

DefaultCommunicationTimeout;

// 默認連接超時時長

}

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

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

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

{

"command_type"： " schedule_data"，

"data"：[{

"upc_code"：，

"product_name"： ""，

"price"： ""，

"member_price"： ""，

"unit： ""，

}]

}

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

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

4? 數據交互層的應用（Application of data-interaction layer）

掃碼支付系統數據交互層的開發環境為Visual Studio 2018，開發語言為C#。服務器和商戶終端機的運行環境為64 位Windows 10，數據庫為SQL Server。

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

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

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

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

5? ?結論（Conclusion）

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

參考文獻（References）

[1] 陳平，高懷恩，陳炯標，等.基于物聯網的智慧超市[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] 吳斌峰.基于微服務架構的物聯網中間件設計[J].計算機科學， 2019，46（S1）：580-584，604.

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

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

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

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

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

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

[10] 張玉杰，張海濤，張婷婷.基于MQTT的物聯網系統消息發布/訂閱方法研究[J].電視技術，2017，41（Z3）：83-87.

[11] 姜妮，張宇，趙志軍.基于消息隊列遙測傳輸的推送系統[J].計算機工程，2015，41（9）：1-6.

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

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

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

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

作者簡介：

崔? ?陽（1979-），男，博士，講師.研究領域：知識工程與知識發現.

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