張大鵬

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

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

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

1引言

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

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

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

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

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

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

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

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

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

2.2軟件設(shè)計

2.2.1開發(fā)框架

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

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

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

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

2.2.2分時采集

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

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

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

2.3.1訪問優(yōu)化

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

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

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