• <tr id="f0fhe"><label id="f0fhe"></label></tr>
  • <acronym id="f0fhe"></acronym>
      1. <tr id="f0fhe"></tr>
        無憂支付網首頁
        囊括國內所有第三方支付公司信息
        為客戶提供最優質的支付接口服務
        24小時服務電話
        182 2176 9212
        站內搜索
        您當前的位置:主頁 > 支付接口申請相關知識 >

        某掃碼支付系統的數據交互層優化設計

        添加時間:2022-03-02 12:57

          1、引言

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

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

          2、掃碼支付系統的性能分析

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

          2.1 系統運行的基本流程

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

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

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

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

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

          2.2 當前系統存在的不足

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

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

          3、數據交互層的設計與實現

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

          3.1 功能設計

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

        加入數據交互層后的掃碼支付系統

        圖1 加入數據交互層后的掃碼支付系統

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

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

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

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

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

          3.2 實現過程

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

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

        MQTT協議基本流程

        圖2 MQTT協議基本流程

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

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

        表1 MQTT通訊主題

        MQTT通訊主題

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

        代碼1-1

        代碼1-2

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

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

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

        代碼2

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

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

          4、數據交互層的應用

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

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

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

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

        掃碼支付系統交互圖

        圖3 掃碼支付系統交互圖

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

          5、結論

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

        上一篇:app游戲能用支付寶接口嗎?(已解決)
        下一篇:沒有了
        關閉

        1.點擊下面按鈕復制微信號

        18221769212

        2.打開微信→查找微信號

        加為好友 開始支付接入

        免费精品国产自产拍在线观看图片
      2. <tr id="f0fhe"><label id="f0fhe"></label></tr>
      3. <acronym id="f0fhe"></acronym>
          1. <tr id="f0fhe"></tr>