張大鵬

摘要：隨著市場(chǎng)需求的增加，對(duì)供水行業(yè)中遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)的高并發(fā)訪問(wèn)承受能力也有著越來(lái)越高的要求。該文針對(duì)基于Oracle數(shù)據(jù)庫(kù)搭建的遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)，從系統(tǒng)架構(gòu)、網(wǎng)絡(luò)設(shè)備配置、軟件設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)、優(yōu)化和業(yè)務(wù)管理幾個(gè)方面進(jìn)行了探索研究，以期得到合理的解決方案。

關(guān)鍵詞：Oracle;數(shù)據(jù)庫(kù);高并發(fā);優(yōu)化;遠(yuǎn)傳水表

中圖分類號(hào)：TP311? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A? ? ? ? 文章編號(hào)：1009-3044（2018）34-0009-03

1引言

合肥供水集團(tuán)有限公司近期實(shí)施兩萬(wàn)塊遠(yuǎn)傳水表自動(dòng)抄表系統(tǒng)，遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)是該系統(tǒng)的組成部分，承擔(dān)著水表數(shù)據(jù)的采集、管理和應(yīng)用的功能，面向底層發(fā)布采集指令或定時(shí)接收數(shù)據(jù)集中器的寫入請(qǐng)求進(jìn)行數(shù)據(jù)存儲(chǔ)，面向上層提高數(shù)據(jù)加工、查詢、統(tǒng)計(jì)、傳輸?shù)姆?wù)。在當(dāng)前兩萬(wàn)塊水表的應(yīng)用場(chǎng)景和通用軟硬件配備下，遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)的常規(guī)搭建，不會(huì)存在數(shù)據(jù)并發(fā)寫入引起的系統(tǒng)不可忍受的遲緩——甚至宕機(jī)的問(wèn)題。

但是，隨著應(yīng)用業(yè)務(wù)的成熟，按照規(guī)劃后期會(huì)有十萬(wàn)、百萬(wàn)數(shù)量的智能水表接入，幾十萬(wàn)或近百萬(wàn)條的抄表數(shù)據(jù)需要同時(shí)寫入數(shù)據(jù)庫(kù)，那么遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)就要考慮解決高并發(fā)訪問(wèn)帶來(lái)的問(wèn)題，需要提高抄表數(shù)據(jù)記錄采集的TPS。

市場(chǎng)上專業(yè)的大公司有解決高并發(fā)訪問(wèn)問(wèn)題的專業(yè)產(chǎn)品，同時(shí)可以為用戶定制開(kāi)發(fā)，當(dāng)然他們的IT解決方案中包括高大上的硬件和軟件，價(jià)格之昂貴一般公司難以承受。另外，淘寶網(wǎng)站、12306票務(wù)系統(tǒng)采用了在通用解決方案的基礎(chǔ)上，進(jìn)行自主開(kāi)發(fā)和研究，也成功地解決了高并發(fā)訪問(wèn)的問(wèn)題。

2高并發(fā)訪問(wèn)解決方案

隨著合肥供水集團(tuán)遠(yuǎn)傳水表的大量使用，抄表方式正在由手持抄表向遠(yuǎn)程全自動(dòng)抄表轉(zhuǎn)變，一套由遠(yuǎn)傳水表、數(shù)據(jù)集中器、GPRS通信網(wǎng)絡(luò)、遠(yuǎn)傳抄表數(shù)據(jù)平臺(tái)組成的自動(dòng)抄表系統(tǒng)正在實(shí)施，遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)控制數(shù)據(jù)集中器，進(jìn)行指令交互和水表數(shù)據(jù)采集，目前從集團(tuán)公司六個(gè)抄表站下轄的區(qū)域內(nèi)選定了共兩萬(wàn)塊水表接受系統(tǒng)管理。為了適應(yīng)水表的快速擴(kuò)充和接入系統(tǒng)實(shí)施自動(dòng)抄表的要求，設(shè)計(jì)的數(shù)據(jù)平臺(tái)要在高并發(fā)訪問(wèn)層面上具有前瞻性，在三到五年內(nèi)面臨水表業(yè)務(wù)擴(kuò)充的情況，在已有軟硬件環(huán)境下能夠接受高并發(fā)訪問(wèn)的壓力。

在遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)項(xiàng)目后續(xù)的實(shí)施過(guò)程中，結(jié)合合肥供水集團(tuán)遠(yuǎn)傳水表的分布、抄表站點(diǎn)的分布、抄收業(yè)務(wù)規(guī)則等實(shí)際情況，可以從系統(tǒng)架構(gòu)、網(wǎng)絡(luò)設(shè)備配置、軟件設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)和業(yè)務(wù)管理方面進(jìn)行合理的統(tǒng)籌安排，有針對(duì)性地采取措施來(lái)應(yīng)對(duì)高并發(fā)抄表數(shù)據(jù)寫入和響應(yīng)的問(wèn)題。

2.1劃分系統(tǒng)層級(jí)

遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)在集團(tuán)總公司部署一級(jí)平臺(tái)，每個(gè)抄表站分別部署二級(jí)平臺(tái)，一級(jí)平臺(tái)設(shè)置為系統(tǒng)主站，每個(gè)二級(jí)平臺(tái)設(shè)置為從站。從站系統(tǒng)負(fù)責(zé)本轄區(qū)下的遠(yuǎn)傳水表的抄表、核對(duì)、計(jì)量、分析、校驗(yàn)的工作，然后把經(jīng)過(guò)審核確認(rèn)的數(shù)據(jù)集中上傳給集團(tuán)公司的主站，主站系統(tǒng)負(fù)責(zé)數(shù)據(jù)的集中和應(yīng)用。

通過(guò)劃分層級(jí)實(shí)現(xiàn)了抄表任務(wù)的分解，避免了主站的同一時(shí)間段內(nèi)的高并發(fā)訪問(wèn)。

2.2軟件設(shè)計(jì)

2.2.1開(kāi)發(fā)框架

當(dāng)前，軟件開(kāi)發(fā)的技術(shù)框架林林總總百花齊放，那邊廂唯IT巨頭馬首是瞻，這邊廂在高舉去IOE的大旗，把龐大的互聯(lián)網(wǎng)+帝國(guó)打造得獨(dú)步世界無(wú)人能敵。那么我們是向左還是向右？放眼看來(lái)，巨頭的重量級(jí)產(chǎn)品解決方案的效果自然毋庸置疑，反其道而行之的輕量級(jí)架構(gòu)方案也是一騎絕塵風(fēng)生水起，但是我相信，無(wú)論是兩種路線下的哪種方案，都是在充分考慮了自己的實(shí)際情況，組合了每個(gè)路線中的合適產(chǎn)品構(gòu)建了一個(gè)完美有效專有體系。因此，只要是經(jīng)過(guò)充分論證選型合適，就可以避免很多問(wèn)題。

調(diào)研一些遠(yuǎn)傳數(shù)據(jù)采集系統(tǒng)發(fā)現(xiàn)，大多使用Java語(yǔ)言開(kāi)發(fā)，后臺(tái)數(shù)據(jù)庫(kù)有Mysql、Oracle等。結(jié)合我們公司的技術(shù)人員情況和水表廠家可能的支持，推薦使用Java開(kāi)發(fā)語(yǔ)言和Oracle11g數(shù)據(jù)庫(kù)組合的方案。有很多Java的框架方案可以選擇，為進(jìn)一步論證提供基礎(chǔ)，這里拋磚引玉提供兩個(gè)：

（1）Java+Struts+Spring+Hibernate+Oracle

（2）Java+Struts+Spring+Mybaits+Oracle

2.2.2分時(shí)采集

遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)在不進(jìn)行多層級(jí)平臺(tái)劃分的情況下，只設(shè)置集團(tuán)公司一個(gè)數(shù)據(jù)中心，通過(guò)軟件邏輯設(shè)計(jì)也可以對(duì)高并發(fā)訪問(wèn)進(jìn)行分解。我們可以對(duì)多個(gè)抄表站的數(shù)據(jù)采集工作在時(shí)間上進(jìn)行統(tǒng)籌規(guī)劃，安排每個(gè)抄表站在自己專用時(shí)間段內(nèi)采集數(shù)據(jù)。

當(dāng)然，平臺(tái)分層和采集分時(shí)兩個(gè)方案可以結(jié)合使用，遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)即進(jìn)行主、從分級(jí)，也在從站進(jìn)行數(shù)據(jù)采集的時(shí)候，按自己抄表站下轄的不同片區(qū)進(jìn)行分時(shí)間段采集數(shù)據(jù)。

2.3數(shù)據(jù)庫(kù)設(shè)計(jì)

2.3.1訪問(wèn)優(yōu)化

遠(yuǎn)傳水表數(shù)據(jù)平臺(tái)采用oracle 11g數(shù)據(jù)庫(kù)，如果只使用一個(gè)數(shù)據(jù)庫(kù)，在數(shù)據(jù)采集的時(shí)候，同時(shí)有查詢統(tǒng)計(jì)的業(yè)務(wù)發(fā)起，那么采集來(lái)的數(shù)據(jù)不一定寫進(jìn)去，查詢統(tǒng)計(jì)也遲遲不見(jiàn)結(jié)果出來(lái)?？梢圆扇≡趦蓚€(gè)庫(kù)上（主、從庫(kù)）讀、寫分離的模式，主庫(kù)負(fù)責(zé)寫數(shù)據(jù)、讀數(shù)據(jù)，從庫(kù)負(fù)責(zé)讀數(shù)據(jù)，解決讀寫操作爭(zhēng)搶資源造成性能下降的問(wèn)題。

數(shù)據(jù)庫(kù)的讀寫分離方案，首先要實(shí)現(xiàn)主、從庫(kù)的數(shù)據(jù)同步，可以采用Oracle自有的組件功能，如Oracle 11g的Active Data Guard。出于穩(wěn)定性、處理能力等考慮也可以選擇商業(yè)化的產(chǎn)品，國(guó)外的有Quest公司的SharePlex，國(guó)內(nèi)的有DSG公司的RealSync，還有Oracle自有的GoldenGate，都可以選擇使用。每次有寫庫(kù)操作，同步更新cache，每次讀取先讀cache再讀DB。

其次，在程序開(kāi)發(fā)中，要制定和實(shí)現(xiàn)數(shù)據(jù)訪問(wèn)策略，寫數(shù)據(jù)操作指向主庫(kù)，讀數(shù)據(jù)操作指向從庫(kù)。