摘 要：本文提出了基于SP/MC的網(wǎng)絡(luò)模型。描述了一種基于該模型的分布式交易系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)。介紹了該系統(tǒng)的總體設(shè)計(jì)架構(gòu)和分布式結(jié)構(gòu)，然后描述了系統(tǒng)如何實(shí)現(xiàn)各種分布式特性及一些通用服務(wù)的實(shí)現(xiàn)，如：異構(gòu)系統(tǒng)接入，負(fù)載均衡，延遲重連。最后通過多次實(shí)測(cè)數(shù)據(jù)，展現(xiàn)了基于SP/MC網(wǎng)絡(luò)模型的性能和基于該模型的交易系統(tǒng)性能。

關(guān)鍵詞：?jiǎn)紊a(chǎn)者-多消費(fèi)者網(wǎng)絡(luò)模型；分布式交易系統(tǒng)；網(wǎng)絡(luò)模型

中圖分類號(hào)：TP3

隨著NFC技術(shù)的普及和移動(dòng)APP的興起，移動(dòng)支付即將迎來高速增長(zhǎng)期；通過技術(shù)改造和系統(tǒng)優(yōu)化，使得移動(dòng)支付系統(tǒng)在可靠性，可用性和性能方面都有不同程度的提升，現(xiàn)已具備處理每秒萬筆交易的能力。高效的網(wǎng)絡(luò)通信框架和系統(tǒng)分布式化是解決海量客戶請(qǐng)求的兩個(gè)關(guān)鍵技術(shù)。

現(xiàn)有高性能網(wǎng)絡(luò)通信框架在事件分發(fā)和通知的實(shí)現(xiàn)主要使用Reactor模式實(shí)現(xiàn)[1]，事件分發(fā)后對(duì)后續(xù)數(shù)據(jù)的處理沒提供相應(yīng)的模型（一般由用戶自己實(shí)現(xiàn)）。生產(chǎn)者消費(fèi)者模型是最早用于經(jīng)濟(jì)領(lǐng)域的模型，之后被引入計(jì)算機(jī)領(lǐng)域中用于解決并發(fā)和同步問題，如：該模型在多核并行計(jì)算中的應(yīng)用[2，3]，該模型可以作為多核環(huán)境下的編程范型[4]。生產(chǎn)消費(fèi)者模型（P/C）的本質(zhì)是通過引入緩沖區(qū)在一定時(shí)間內(nèi)緩解生產(chǎn)者和消費(fèi)者之間的速率不匹配問題。在一定前提條件下，通過調(diào)整緩沖區(qū)大小，生產(chǎn)者和消費(fèi)者的比率等方式都可提高P/C模型的效率。交易系統(tǒng)的后臺(tái)業(yè)務(wù)邏輯復(fù)雜，數(shù)據(jù)處理操作與接收數(shù)據(jù)請(qǐng)求相比耗費(fèi)時(shí)間更多，符合P/C模型（單生產(chǎn)者多消費(fèi)者模型，即SP/MC模型）的應(yīng)用場(chǎng)景以解決系統(tǒng)中臨界資源的共享管理。

分布式系統(tǒng)的高可靠，高可用和橫向擴(kuò)展能力是解決大量客戶請(qǐng)求的有效手段[5]。分布式系統(tǒng)多實(shí)例部署結(jié)構(gòu)，提高了可用性和系統(tǒng)吞吐量。多實(shí)例之間互為熱備，也加強(qiáng)了系統(tǒng)的可靠性。分布式系統(tǒng)可簡(jiǎn)單通過系統(tǒng)實(shí)例的簡(jiǎn)單增加即可滿足前段請(qǐng)求劇增的需求。因此，交易系統(tǒng)的分布式化是大交易系統(tǒng)改造的趨勢(shì)。

本文提出了基于SP/MC的網(wǎng)絡(luò)模型。描述了一種基于該模型的分布式交易系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)。介紹了該系統(tǒng)的總體設(shè)計(jì)架構(gòu)和分布式結(jié)構(gòu)，然后描述了系統(tǒng)如何實(shí)現(xiàn)各種分布式特性及一些通用服務(wù)的實(shí)現(xiàn)，如：異構(gòu)系統(tǒng)接入，負(fù)載均衡，延遲重連。最后通過多次實(shí)測(cè)數(shù)據(jù)，展現(xiàn)了基于SP/MC網(wǎng)絡(luò)模型的性能和基于該模型的交易系統(tǒng)性能。

1 基于SP/MC的網(wǎng)絡(luò)模型

生產(chǎn)者和消費(fèi)者模型（P/C Model）可以適用于多種應(yīng)用，是一種解決并發(fā)問題的經(jīng)典范型[6-9]。根據(jù)P，C數(shù)目不同，P/C模型衍生出四種類型：?jiǎn)紊a(chǎn)者-單消費(fèi)者（SP/SC），單生產(chǎn)者-多消費(fèi)者（SP/MC），多生產(chǎn)者-單消費(fèi)者（MP/SC），多生產(chǎn)者-多消費(fèi)者（MP/MC）。

1.1 SP/MC模型

生產(chǎn)者和消費(fèi)者之間對(duì)數(shù)據(jù)的處理是獨(dú)立進(jìn)行，但是其交換數(shù)據(jù)使用了共享資源，一般使用隊(duì)列作為緩存，兩者對(duì)隊(duì)列的存取是并發(fā)進(jìn)行，因此，需要使用一些同步方式保護(hù)共享資源。當(dāng)隊(duì)列中數(shù)據(jù)滿的時(shí)候，生產(chǎn)者無法再生產(chǎn)，必須等待消費(fèi)者，消費(fèi)者取出隊(duì)列數(shù)據(jù)時(shí)發(fā)出事件通知生產(chǎn)者，才可繼續(xù)生產(chǎn)數(shù)據(jù)；同理，當(dāng)隊(duì)列為空時(shí)，消費(fèi)者必須等待生產(chǎn)者，生產(chǎn)者生產(chǎn)數(shù)據(jù)并發(fā)出事件通知消費(fèi)者，才可繼續(xù)處理數(shù)據(jù)。文獻(xiàn)[10]提出了常用P/C模型的描述，如圖1所示，P和C之間使用隊(duì)列（Queue Buffer）實(shí)現(xiàn)，共享資源隊(duì)列使用Monitor方式同步。Monitor除提供了對(duì)buffer提供互斥鎖序列化讀寫操作，還提供一種事件通知機(jī)制。P寫入數(shù)據(jù)至Buffer前，先判斷Buffer是否滿，滿則等待；如果Buffer不滿則添加數(shù)據(jù)，添加數(shù)據(jù)后使用semaphore通知C。C從Buffer中讀取數(shù)據(jù)前，先判斷Buffer是否為空，空則等待；如果Buffer不空則獲取數(shù)據(jù)，獲取數(shù)據(jù)后通知P。

生產(chǎn)者的能力與消費(fèi)者的能力比例影響了選擇的模型。如果P和C的能力相近時(shí)，使用SP/SC比較合適；當(dāng)生產(chǎn)者能力較強(qiáng)時(shí)，使用SP/MC比較合適；當(dāng)消費(fèi)者能力較強(qiáng)時(shí)，宜選用MP/SC模型；MP/MC是如上三種模型的普適性抽象。通過實(shí)驗(yàn)驗(yàn)證了MP/MC模型隨著CPU的增加，效率有明顯提高。但是，P和C的數(shù)目也不是越多越好，P和C數(shù)量的增加導(dǎo)致系統(tǒng)資源的開銷和系統(tǒng)調(diào)度負(fù)載的增加，影響系統(tǒng)的整體效率。由于實(shí)際系統(tǒng)的業(yè)務(wù)和環(huán)境的差異，M的取值的預(yù)先確定是個(gè)難題，一般基于經(jīng)驗(yàn)結(jié)合多次實(shí)驗(yàn)結(jié)果綜合考慮后確認(rèn)[11]。

1.2 基于SP/MC網(wǎng)絡(luò)模型

交易系統(tǒng)的網(wǎng)絡(luò)通信子系統(tǒng)可抽象為一個(gè)P/C模型。系統(tǒng)外部客戶端發(fā)起大量并發(fā)請(qǐng)求，系統(tǒng)接收請(qǐng)求后，將各種請(qǐng)求交付給不同的請(qǐng)求處理服務(wù)程序進(jìn)行數(shù)據(jù)接收，數(shù)據(jù)解析，數(shù)據(jù)處理等操作，最后將處理結(jié)果寫入網(wǎng)卡返回給客戶端。網(wǎng)絡(luò)請(qǐng)求處理程序的處理過程可抽象為消費(fèi)者，系統(tǒng)對(duì)網(wǎng)絡(luò)請(qǐng)求的接收過程即可抽象為生產(chǎn)者。

交易系統(tǒng)的外部客戶端數(shù)量和并發(fā)請(qǐng)求較多，在短時(shí)間內(nèi)可發(fā)起大量網(wǎng)絡(luò)請(qǐng)求。請(qǐng)求的后續(xù)處理有許多費(fèi)時(shí)的操作。交易系統(tǒng)的請(qǐng)求的生成能力遠(yuǎn)大于請(qǐng)求的處理能力，即生產(chǎn)者的生產(chǎn)能力遠(yuǎn)大于消費(fèi)者的處理能力，因此，選用SP/MC或MP/MC模型比較合適。

現(xiàn)代操作系統(tǒng)（Linux，Unix，Windows等）提供了非常高性能的Polling機(jī)制用于監(jiān)視網(wǎng)卡的IO請(qǐng)求，如IOCP，EPOLL，KQUEUE等[12]。使用Polling機(jī)制很容易同時(shí)接收許多網(wǎng)絡(luò)請(qǐng)求事件。如圖2所示，本系統(tǒng)在一個(gè)線程里使用EPOLL實(shí)現(xiàn)生產(chǎn)者（SP），用于獲取用戶的請(qǐng)求通知；使用多個(gè)線程實(shí)現(xiàn)多個(gè)消費(fèi)者（MC），處理后續(xù)比較耗時(shí)操作，如：數(shù)據(jù)格式的解析，多次寫入和查詢數(shù)據(jù)庫操作，遞交給其他服務(wù)處理并等待返回等。

根據(jù)交易系統(tǒng)的實(shí)際需求和特性，使用基于SP/MC的網(wǎng)絡(luò)模型作為核心架構(gòu)，利用操作系統(tǒng)的EPOLL技術(shù)實(shí)現(xiàn)生產(chǎn)者，僅需一個(gè)生產(chǎn)者即可實(shí)現(xiàn)上萬并發(fā)的請(qǐng)求，減少了操作系統(tǒng)的開銷，提高了整體系統(tǒng)的效率。使用多個(gè)消費(fèi)者并行處理耗時(shí)的后續(xù)數(shù)據(jù)處理工作，充分利用了CPU的多核心并發(fā)技術(shù)，提高了硬件資源利用率，減少硬件成本。

2 系統(tǒng)總體設(shè)計(jì)

在線交易系統(tǒng)的總體層次結(jié)構(gòu)一般由外部接口層，業(yè)務(wù)邏輯層，數(shù)據(jù)存儲(chǔ)層組成。根據(jù)實(shí)際業(yè)務(wù)的特點(diǎn)和行業(yè)實(shí)踐經(jīng)驗(yàn)，各種系統(tǒng)對(duì)每層的功能和內(nèi)部結(jié)構(gòu)定義都不盡相同。

2.1 總體系統(tǒng)架構(gòu)

以技術(shù)實(shí)現(xiàn)角度分類，本系統(tǒng)分為WEB層和APP層，系統(tǒng)的總體結(jié)構(gòu)如圖3所示。

外部接口支持HTTP協(xié)議和Raw Socket兩種接入方式。HTTP協(xié)議的接入和Raw Socket的接入分別在Web層和APP層實(shí)現(xiàn)。Web層提供兩種接入方式：帶界面顯示的接入和API級(jí)別的接入，例如：移動(dòng)和PC客戶端的接入需要顯示界面，而外部客戶系統(tǒng)的接入主要是使用基于HTTP/HTTPS的API接入。APP層也提供一種基于Raw Socket的接入方式，主要面向可信任的系統(tǒng)。

業(yè)務(wù)邏輯層和數(shù)據(jù)存儲(chǔ)層在APP層中實(shí)現(xiàn)。業(yè)務(wù)邏輯分為交易相關(guān)服務(wù)，交易無關(guān)服務(wù)和通用服務(wù)。交易相關(guān)服務(wù)是本系統(tǒng)的核心服務(wù)，為提高可靠性和安全性將其獨(dú)立實(shí)現(xiàn)，包括消費(fèi)相關(guān)，公用繳費(fèi)相關(guān)等交易。交易無關(guān)服務(wù)主要是為移動(dòng)和PC客戶端服務(wù)的功能，如：用戶登錄管理，用戶相關(guān)信息查詢和推送，系統(tǒng)基本信息維護(hù)等。通用服務(wù)包括交易系統(tǒng)常用的各種服務(wù)：全局唯一序列號(hào)生成服務(wù)，常用信息查詢服務(wù)，加密服務(wù)，短信通知服務(wù)等。

數(shù)據(jù)存儲(chǔ)層以關(guān)系數(shù)據(jù)庫為主，實(shí)時(shí)存儲(chǔ)所有交易數(shù)據(jù)，關(guān)系數(shù)據(jù)庫支持DB2和MYSQL數(shù)據(jù)庫，關(guān)鍵數(shù)據(jù)存儲(chǔ)于DB2數(shù)據(jù)庫中。對(duì)系統(tǒng)中非長(zhǎng)期保存的數(shù)據(jù)使用Key-Value的形式存儲(chǔ)于內(nèi)存緩存服務(wù)中。對(duì)變化較少訪問量較大的數(shù)據(jù)使用兩級(jí)存儲(chǔ)，最準(zhǔn)確的數(shù)據(jù)存儲(chǔ)于關(guān)系數(shù)據(jù)庫中。

2.2 分布式物理結(jié)構(gòu)

本系統(tǒng)是一個(gè)基于RPC的分布式集群，詳細(xì)的系統(tǒng)物理連接結(jié)構(gòu)如圖4所示。Web層和APP層都包括了多臺(tái)物理機(jī)，每臺(tái)物理機(jī)上部署了一套系統(tǒng)實(shí)例，同時(shí)提供服務(wù)。Web層與APP層之間使用基于自有協(xié)議的跨語言RPC方式通信。Web層與APP層的各個(gè)實(shí)例之間使用全連接的方式。

Web層的主要功能是界面顯示和HTTP協(xié)議適配。APP層則實(shí)現(xiàn)業(yè)務(wù)功能和存儲(chǔ)。APP層中每一個(gè)系統(tǒng)實(shí)例對(duì)外僅有一個(gè)Proxy服務(wù)，提供統(tǒng)一的調(diào)用接口。根據(jù)業(yè)務(wù)邏輯的特點(diǎn)和共性，提煉了一些邏輯簡(jiǎn)單的通用服務(wù)（序列號(hào)生成服務(wù)，加密服務(wù)，短信服務(wù)等），提高了服務(wù)的重用性。內(nèi)部各個(gè)服務(wù)是獨(dú)立運(yùn)行（進(jìn)程），個(gè)別服務(wù)的崩潰不會(huì)影響其他服務(wù)的運(yùn)行，增強(qiáng)了系統(tǒng)的可用性。各個(gè)服務(wù)之間使用統(tǒng)一的RPC機(jī)制通信，有利于快速增加新服務(wù)。

Web層和APP層的分布式集群部署，提高了系統(tǒng)的整體吞吐量和性能。使用分布式部署，各個(gè)系統(tǒng)實(shí)例之間互為熱備，提高了整個(gè)系統(tǒng)的可靠性和可用性。關(guān)鍵數(shù)據(jù)使用唯一的高性能數(shù)據(jù)庫存儲(chǔ)，保證了交易系統(tǒng)數(shù)據(jù)的高一致性。APP層內(nèi)部通過對(duì)服務(wù)流程提煉和業(yè)務(wù)關(guān)系抽象，形成了一些通用服務(wù)，簡(jiǎn)化了業(yè)務(wù)實(shí)現(xiàn)流程，減少了新需求開發(fā)、測(cè)試和上線時(shí)間。

3 系統(tǒng)的分布式特點(diǎn)實(shí)現(xiàn)

基于SP/MC的網(wǎng)絡(luò)模型為單個(gè)服務(wù)的高性能提供了保證。整體系統(tǒng)的可靠性，可用性需求是通過系統(tǒng)的分布式化以滿足。交易系統(tǒng)對(duì)性能，可靠性，可用性和一致性都具有較高的要求，而分布式系統(tǒng)的結(jié)構(gòu)特點(diǎn)決定了其可較好的滿足高可靠性，高可用性和高性能的要求[5]。

3.1 異構(gòu)系統(tǒng)接入

本系統(tǒng)面向客戶群有個(gè)人，公司，機(jī)構(gòu)和內(nèi)部其他系統(tǒng)等。接入的客戶端系統(tǒng)運(yùn)行于多種平臺(tái)，如Windows，Linux，Android，IOS，Unix等。本系統(tǒng)提供兩種通用的接入方式解決異構(gòu)系統(tǒng)的接入問題。個(gè)人和公司的接入主要使用基于HTTP/HTTPS協(xié)議接入。機(jī)構(gòu)和內(nèi)部系統(tǒng)使用自定義的協(xié)議——基于通用數(shù)據(jù)交換的RPC協(xié)議接入。個(gè)人和公司用戶交易量小，安全性驗(yàn)證和權(quán)限審核較高。在WEB層使用成熟的異構(gòu)系統(tǒng)接入標(biāo)準(zhǔn)協(xié)議（HTTP/HTTPS協(xié)議）提供訪問即可滿足個(gè)人和公司用戶的交易要求。個(gè)人用戶直接使用HTTP/HTTPS協(xié)議（瀏覽器或者客戶端）訪問系統(tǒng)服務(wù)，公司用戶使用REST API接口，調(diào)用交易系統(tǒng)服務(wù)。

在性能和安全性方面，機(jī)構(gòu)和內(nèi)部系統(tǒng)的接入需求與個(gè)人和公司接入不同。前者對(duì)性能要求比其他接入方式高，交易系統(tǒng)對(duì)機(jī)構(gòu)和內(nèi)部系統(tǒng)的信任度相對(duì)較高，即安全性驗(yàn)證相對(duì)較低。機(jī)構(gòu)和內(nèi)部系統(tǒng)繞過WEB層，直接通過APP層進(jìn)行接入。APP層實(shí)現(xiàn)了跨平臺(tái)和跨語言的通信協(xié)議——基于通用數(shù)據(jù)交換的RPC協(xié)議。本系統(tǒng)開發(fā)了C/C++，JAVA，PYTHON，LUA語言的二進(jìn)制工具庫提供給接入機(jī)構(gòu)，既可以保證通信協(xié)議的安全性也方便機(jī)構(gòu)的接入。

簡(jiǎn)要介紹該協(xié)議的格式和特點(diǎn)。

（1）協(xié)議是基于字符串，所以不用考慮不同平臺(tái)的字節(jié)序問題，同時(shí)也有利于調(diào)試和問題發(fā)現(xiàn)。

（2）協(xié)議分為報(bào)文頭，報(bào)文體兩部分組成，報(bào)文頭由固定魔數(shù)，版本號(hào)和有效內(nèi)容長(zhǎng)度組成。

（3）報(bào)文體是基于key-value的多個(gè)字段組成，每個(gè)字段由名稱，類型，字段組成。

（4）協(xié)議將數(shù)據(jù)分為三類，數(shù)字，字符串，數(shù)組，數(shù)組內(nèi)部可以包含其他任意類型。

該協(xié)議和RPC調(diào)用機(jī)制緊密結(jié)合?；谠搮f(xié)議的消息內(nèi)容可映射為key-value的哈希表結(jié)構(gòu)。RPC在調(diào)用前先將所有要素構(gòu)造為key-value的哈希表，調(diào)用結(jié)束后，將返回的字節(jié)流按照協(xié)議映射成為哈希表。支持一門新的語言只需實(shí)現(xiàn)協(xié)議到哈希表的互相映射即可。這種設(shè)計(jì)對(duì)不同語言的兼容性很友好，實(shí)現(xiàn)過程也很簡(jiǎn)單。

3.2 負(fù)載均衡機(jī)制及延遲重連

外部客戶端對(duì)交易系統(tǒng)的訪問只有一個(gè)入口，但是，后臺(tái)有多套服務(wù)實(shí)例為客戶端處理交易。在外部入口處，系統(tǒng)配備一臺(tái)F5硬件負(fù)載均衡平衡高負(fù)載下每臺(tái)機(jī)器的壓力，減少系統(tǒng)宕機(jī)的可能。在系統(tǒng)內(nèi)部，每個(gè)服務(wù)自己也是負(fù)載均衡代理服務(wù)，使用負(fù)載均衡的方式與其他服務(wù)或者數(shù)據(jù)庫建立多個(gè)連接，采用輪詢方式均衡負(fù)載。

分布式系統(tǒng)的負(fù)載均衡策略一般有：輪詢機(jī)制，隨機(jī)機(jī)制，基于權(quán)重的機(jī)制?；跈?quán)重的機(jī)制比其他兩種方式考慮因素多，而且實(shí)現(xiàn)方式復(fù)雜。隨機(jī)機(jī)制平均負(fù)載效果沒有輪詢機(jī)制好。特別是在系統(tǒng)較高負(fù)載壓力下，由于隨機(jī)性容易導(dǎo)致某些機(jī)器長(zhǎng)時(shí)間負(fù)載變大，如果此時(shí)一臺(tái)機(jī)器崩潰，其他機(jī)器的負(fù)載更高，進(jìn)而引發(fā)連鎖反應(yīng)最終系統(tǒng)完全崩潰，停止服務(wù)。輪詢方式的均衡平均型和實(shí)現(xiàn)簡(jiǎn)單性比其他兩種方式優(yōu)秀，因此，系統(tǒng)內(nèi)部采用輪詢方式實(shí)現(xiàn)負(fù)載均衡。

分布式交易系統(tǒng)內(nèi)部服務(wù)眾多。為減小系統(tǒng)負(fù)載和避免不必要的通信浪費(fèi)，服務(wù)之間未采用定時(shí)心跳保持連接，而使用TCP長(zhǎng)連接保持連接。假設(shè)服務(wù)A接收請(qǐng)求必須訪問服務(wù)B才能完成任務(wù)。當(dāng)服務(wù)A，B之間連接斷開，而服務(wù)A接收到新的請(qǐng)求時(shí)，服務(wù)A會(huì)發(fā)起定時(shí)從重連，一定次數(shù)后請(qǐng)求服務(wù)失敗，并寫入錯(cuò)誤日志。當(dāng)服務(wù)A沒有接收新請(qǐng)求時(shí)，服務(wù)A不會(huì)發(fā)起重連機(jī)制。通過延遲重連到請(qǐng)求發(fā)生時(shí)刻，可以避免系統(tǒng)內(nèi)部過多請(qǐng)求，減少系統(tǒng)資源浪費(fèi)。

3.3 通用服務(wù)

生成全局唯一序列號(hào)是交易系統(tǒng)各種業(yè)務(wù)都需要的功能，甚至所有數(shù)據(jù)庫也都支持生成序列號(hào)（Sequence）功能。在分布式系統(tǒng)中，唯一的數(shù)據(jù)庫服務(wù)已經(jīng)是系統(tǒng)瓶頸，無法依賴數(shù)據(jù)庫滿足該功能需求。本系統(tǒng)中將該功能抽象獨(dú)立為服務(wù)，其他服務(wù)通過統(tǒng)一的RPC接口訪問。每個(gè)服務(wù)將通過序列號(hào)標(biāo)識(shí)通過請(qǐng)求發(fā)送到序列號(hào)服務(wù)，序列號(hào)通過查找對(duì)應(yīng)的序列號(hào)數(shù)字加1后保存數(shù)據(jù)至文件后返回。該序列號(hào)生成后一般與時(shí)間結(jié)合使用，可以方便的保證全局唯一。例如：自動(dòng)增長(zhǎng)序列號(hào)取十進(jìn)制6位掩碼，結(jié)合全局唯一時(shí)間，即可滿足每秒一百萬筆以內(nèi)交易量的唯一性需求。通過為不同服務(wù)配置不同的編號(hào)，將序列號(hào)生成規(guī)則變?yōu)椋壕幪?hào)，全局時(shí)間和自動(dòng)增長(zhǎng)序列號(hào)，序列號(hào)生成服務(wù)亦可支持分布式部署。

交易系統(tǒng)中常常需要使用參數(shù)查詢功能，例如：卡號(hào)規(guī)則，商戶信息，銀行信息，系統(tǒng)參數(shù)等，數(shù)據(jù)幾乎每筆交易都需要查一到多次，但是數(shù)據(jù)查詢雖然頻繁，修改間隔較長(zhǎng)，一定時(shí)間內(nèi)是只讀數(shù)據(jù)。本系統(tǒng)獨(dú)立一個(gè)服務(wù)集中提供參數(shù)查詢，預(yù)先將數(shù)據(jù)庫中所有數(shù)據(jù)載入內(nèi)存，查詢時(shí)使用二分查找法，快速查找。同時(shí)，針對(duì)數(shù)據(jù)的可修改性，服務(wù)定時(shí)從數(shù)據(jù)庫載入所有數(shù)據(jù)，并使用RCU（Read-copy Update）技術(shù)，保證在載入所有數(shù)據(jù)過程中，不會(huì)影響服務(wù)向外部提供服務(wù)的能力。

本交易系統(tǒng)使用統(tǒng)一的數(shù)據(jù)交換協(xié)議定義了外圍異構(gòu)系統(tǒng)的接入方式；使用多級(jí)負(fù)載均衡技術(shù)，硬件負(fù)載均衡解決對(duì)外大量客戶端的接入，內(nèi)部服務(wù)之間采用多連接負(fù)載平衡方式提高單個(gè)服務(wù)的吞吐量；延遲重連策略增強(qiáng)了服務(wù)的可靠性和可用性；抽象并優(yōu)化高性能通用服務(wù)提高整體系統(tǒng)性能。

4 性能測(cè)試分析

本節(jié)分別測(cè)試了基于SP/MC的網(wǎng)絡(luò)模型和分布式系統(tǒng)的整體性能。網(wǎng)絡(luò)模型的性能測(cè)試是通過對(duì)邏輯簡(jiǎn)單的單獨(dú)服務(wù)性能而實(shí)現(xiàn)，因此也測(cè)試了分布式系統(tǒng)中單點(diǎn)瓶頸的極限性能。另一方面，以外圍系統(tǒng)的角度發(fā)起常用交易，測(cè)試了整個(gè)系統(tǒng)的性能以及可擴(kuò)展線性度。綜合兩個(gè)指標(biāo)可確定交易系統(tǒng)的性能極限。

交易系統(tǒng)主要數(shù)據(jù)請(qǐng)求一般來自固定的長(zhǎng)連接系統(tǒng)（如，機(jī)構(gòu)和內(nèi)部系統(tǒng)）。性能測(cè)試時(shí)，客戶端設(shè)置為固定數(shù)目的長(zhǎng)連接，每個(gè)客戶端連續(xù)發(fā)起交易請(qǐng)求。性能測(cè)試結(jié)果統(tǒng)計(jì)使用后臺(tái)緩存日志系統(tǒng)記錄交易數(shù)據(jù)后，再離線統(tǒng)計(jì)每秒平均交易量（TPS Transaction Per Second）。這樣既避免了多個(gè)客戶端記錄數(shù)據(jù)時(shí)引起的同步困難問題，也保證了計(jì)數(shù)的準(zhǔn)確性。

網(wǎng)絡(luò)通信框架的性能測(cè)試與業(yè)務(wù)邏輯無關(guān)，服務(wù)端選用業(yè)務(wù)邏輯較簡(jiǎn)單的序列號(hào)生成服務(wù)。而測(cè)試整體系統(tǒng)性能時(shí)，客戶端發(fā)起最常用的交易類型（如：消費(fèi)交易），后端按照正常業(yè)務(wù)邏輯處理。測(cè)試環(huán)境的操作系統(tǒng)為X86-64位SUSE 11，內(nèi)核為3.0.13，硬件配置為AMD 8-Core，2GHZ處理器，內(nèi)存16G，硬盤200G，文件系統(tǒng)EXT3。

如圖5a所示，測(cè)試了客戶端增加時(shí)對(duì)單獨(dú)服務(wù)的TPS的影響?？蛻舳藬?shù)從1增加到10個(gè)時(shí)，隨著客戶端的增加服務(wù)的TPS也遞增，但是，繼續(xù)增加客戶端，系統(tǒng)性能有增加但是不明顯，因此客戶端的請(qǐng)求為20已經(jīng)可以滿足單個(gè)服務(wù)要求。設(shè)定客戶端為20，測(cè)試單個(gè)服務(wù)消費(fèi)者數(shù)目的變化與服務(wù)TPS的關(guān)系，如圖5b所示，調(diào)整服務(wù)的消費(fèi)者數(shù)值（M）由1增加到10服務(wù)TPS有明顯提升，但是，當(dāng)M大于10后服務(wù)TPS不升反降。消費(fèi)者數(shù)值的增加會(huì)導(dǎo)致系統(tǒng)對(duì)多個(gè)消費(fèi)者線程的調(diào)度和同步的性能開銷增加，因此，最優(yōu)消費(fèi)者數(shù)目M應(yīng)為10。

整體系統(tǒng)性能測(cè)試結(jié)果中，如圖6所示，實(shí)線為系統(tǒng)實(shí)測(cè)的TPS，虛線為理論線性線條，對(duì)比可見系統(tǒng)可擴(kuò)展性比較優(yōu)秀。三個(gè)系統(tǒng)實(shí)例時(shí)，數(shù)據(jù)庫成為了交易系統(tǒng)的瓶頸，此時(shí)數(shù)據(jù)庫服務(wù)器的CPU占用率已經(jīng)達(dá)到85%以上，硬盤IO繁忙度為90%以上。

5 結(jié)論

本文提出了基于SP/MC的網(wǎng)絡(luò)模型。描述了一種基于該模型的分布式交易系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)。介紹了該系統(tǒng)的總體設(shè)計(jì)架構(gòu)和分布式結(jié)構(gòu)，然后描述了系統(tǒng)如何實(shí)現(xiàn)各種分布式特性及一些通用服務(wù)的實(shí)現(xiàn)，如：異構(gòu)系統(tǒng)接入，負(fù)載均衡，延遲重連。通過性能測(cè)試，基于SP/MC網(wǎng)絡(luò)模型和基于該模型開發(fā)的分布式交易系統(tǒng)具有優(yōu)秀的性能。交易系統(tǒng)對(duì)關(guān)鍵數(shù)據(jù)的準(zhǔn)確性和一致性要求很高，關(guān)鍵數(shù)據(jù)的存儲(chǔ)必須選用已被業(yè)界證明的關(guān)系數(shù)據(jù)庫為唯一存儲(chǔ)，因此，導(dǎo)致了數(shù)據(jù)庫成為了交易系統(tǒng)的性能瓶頸。如果交易量上升到足夠大時(shí)，可通過數(shù)據(jù)庫擴(kuò)容，數(shù)據(jù)分片，數(shù)據(jù)庫集群等技術(shù)提高整體系統(tǒng)性能。

參考文獻(xiàn)：

[1]James Coplien，Douglas Schmidt.Pattern languages of program design[M].ACM Press/Addison-Wesley Publishing，1995.

[2]Byrd，et al.Producer-consumer：Communicationin Distributed Shared Memory Multiprocessors[C].Proceedings of the IEEE，1999，Vol 87.Issue 3：456-466.

[3]Liqun Cheng，Carter J.B.，Donglai Dai.An Adaptive Cache Coherence Protocol Optimized for Producer-Consumer Sharing[C].International Conference on High Performance Computer Architecture，2007：328-339.

[4]ArnauPrat-Perez，David Dominguez-Sal，et al.Producer-Consumer： The Programming Model for Future Many-Core Processors[C].International Conference on Architecture of Computing System，2013，Vol 7767：110-121.

[5]Andrew Tanenbaum，Maarten Van Steen.Distributed Systems：Principles and Paradigms （2nd Edition）[M].Prentice Hall，2006，12.

[6]Stefano，et al.Synchronous Producer-consumer Transactions for Real-time Distributed Process Control[C].IEEE International Workshop on Factory Communication Systems，1997：27-36.

[7]Juiz，et al.Improved Performance Model of a Real-time Software Element：The Producer-consumer[C].Second International Workshop on Real-Time Computing Systems and Applications，1995：174-178.

[8]Zhang Y.，Zhang J.，Zhang，D.Implementing and Testing Producer-consumer Problem Using Aspect-oriented Programming[C].Fifth International Conference on Information Assurance and Security，2009，Vol 2：749-752.

[9]Shen C.Discrete-event Simulation on The Internet and The Web[J].Future Generation Computer Systems，2000，VOL.17.Issue2：187-196.

[10]Andrews G.R.，Schneider F.B..Concepts and Notations for Concurrent Programming[J].Computing Surveys.VOL 15.Issue 1.1983：3-43.

[11]Syed NasirMehmood，NazleeniHaron，VaqarAkhtar，YounusJaved.Implementation and Experimentation of Producer-Consumer Synchronization Problem[J].International Journal of Computer Applications，2011，VOL.14.Issue 3：32-37.

[12]W.Richard Stevens，Bill Fenner，Andrew M.Rudoff.Unix Network Programming，Volume 1[M].Addison-Wesley Professional，2003，11.

作者簡(jiǎn)介：歐鵬（1971-），男，中國(guó)銀聯(lián)技術(shù)開發(fā)中心，高級(jí)主管，高工，碩士學(xué)位，主要領(lǐng)域：項(xiàng)目管理，質(zhì)量保證，CMMI，精益6 Sigma，系統(tǒng)架構(gòu)；莊曉，曾進(jìn)，王笑，程論，工程師。

作者單位：中國(guó)銀聯(lián)股份有限公司技術(shù)開發(fā)中心，上海 201201