崔陽(yáng)

文章編號(hào)：2096-1472（2022）-02-14-04

DOI：10.19644/j.cnki.issn2096-1472.2022.002.004

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

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

中圖分類(lèi)號(hào)：TP319? ? ?文獻(xiàn)標(biāo)識(shí)碼：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）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1? ?功能設(shè)計(jì)

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

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

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

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

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

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

3.2? ?實(shí)現(xiàn)過(guò)程

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

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

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

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

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

public struct MqttClientTcpOptions

{

Server;? ? ? ? ? ? // 服務(wù)器地址

Port;? ? ? ? ? ? ? // 服務(wù)器端口

ClientId;? ? ? ? ? ?// 客戶(hù)端ID

UserName;? ? ? ? ?// 用戶(hù)名

Password;? ? ? ? ? // 密碼

KeepAlivePeriod;? ? // 保持連接時(shí)長(zhǎng)

CleanSession;? ? ?// 斷開(kāi)時(shí)是否保留會(huì)話(huà)

DefaultCommunicationTimeout;

// 默認(rèn)連接超時(shí)時(shí)長(zhǎng)

}

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

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

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

{

"command_type"： " schedule_data"，

"data"：[{

"upc_code"：，

"product_name"： ""，

"price"： ""，

"member_price"： ""，

"unit： ""，

}]

}

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

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

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

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

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

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

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

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

5? ?結(jié)論（Conclusion）

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

參考文獻(xiàn)（References）

[1] 陳平，高懷恩，陳炯標(biāo)，等.基于物聯(lián)網(wǎng)的智慧超市[J].電視技術(shù)，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] 吳斌峰.基于微服務(wù)架構(gòu)的物聯(lián)網(wǎng)中間件設(shè)計(jì)[J].計(jì)算機(jī)科學(xué)， 2019，46（S1）：580-584，604.

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

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

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

[7] 單美靜.基于AHP法的移動(dòng)支付安全風(fēng)險(xiǎn)評(píng)估[J]計(jì)算機(jī)科學(xué)，2015，42（S2）：368-371.

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

[9] 陽(yáng)旺，樊振宇，吳帆.基于6LoWPAN與MQTT的無(wú)線(xiàn)傳感網(wǎng)絡(luò)設(shè)計(jì)[J].國(guó)防科技大學(xué)學(xué)報(bào)，2019，41（01）：161-168.

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

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

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

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

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

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

作者簡(jiǎn)介：

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

基金項(xiàng)目：中國(guó)勞動(dòng)關(guān)系學(xué)院科研項(xiàng)目（20XYJS004）.