——我對公司機房數(shù)據(jù)處理流程的改造體會
公司第三方代收水費前置機程序開發(fā)肇始于2014年。當(dāng)時因為只有郵政一家接入,所以采用的數(shù)據(jù)流處理方式為串行,如圖1所示,流程為3個步驟:接受請求、處理請求、返回結(jié)果。
這個處理方式對于“一對一”的請求沒有任何問題,除了效率上差一些外起碼不會出現(xiàn)問題。但是隨著公司更多的第三方平臺的接入,這種串行處理方式就暴漏出它的問題了,最致命的弱點恰恰就在一對一這個問題上?!耙粚σ弧钡囊馑季褪峭粫r刻只處理一個業(yè)務(wù)請求,只有等數(shù)據(jù)全部處理完成后,才會再接受另一個請求;但是處理請求是需要時間的,如果在處理請求期間有另外一個平臺的業(yè)務(wù)請求到來,那么就會被丟棄從而出現(xiàn)賬務(wù)問題。這就是為什么在新接入了建行、農(nóng)行、微信公眾號、微信生活繳費、支付寶生活繳費、移動荷包等第三方平臺之后不斷出現(xiàn)了賬務(wù)問題的原因所在。
問題既然找到了,那么要怎么解決呢?對于需要同一時刻處理多個請求的問題,唯一的解決辦法是改串行處理方式為并行方式,如圖2所示,前置機程序同時接受多個業(yè)務(wù)請求并且處理。從原理來說很簡單,但是對于程序的改造來說工程量卻是十分巨大。這就好比你要把一棟2層樓的房子改造成20層樓的高樓,唯一的辦法就是推倒重來。為此,要想把串行方式改為并行方式,就需要對原來的程序進行幾乎推倒重來的大改進。
經(jīng)過4個月的努力,程序的重構(gòu)終于完成,代碼80%以上被重寫,數(shù)據(jù)處理流程參見圖3,當(dāng)有業(yè)務(wù)請求到來的時候首先由接受請求進程將請求數(shù)據(jù)緩存到相應(yīng)的業(yè)務(wù)數(shù)據(jù)緩沖區(qū)中,然后分別由具體的業(yè)務(wù)處理進程從緩沖區(qū)中獲取到請求數(shù)據(jù),并作相應(yīng)處理,完成后將請求處理結(jié)果返回給請求者。
從圖3可以看出重構(gòu)后的程序中,一共采取了5個進程,分別是“接受請求進程,交費處理進程,沖正處理進程和2個查詢處理進程”這里使用2個查詢處理進程是因為從以往的日志分析中得出查詢業(yè)務(wù)量遠遠多于其他的業(yè)務(wù)量。并且這5個進程是獨立運行的,相互之間沒有直接的制約關(guān)系。同時為了避免出現(xiàn)數(shù)據(jù)丟失的情況,我還使用了3個數(shù)據(jù)緩沖區(qū),既查詢請求數(shù)據(jù)緩沖區(qū)、交費請求數(shù)據(jù)緩沖區(qū)、沖正請求數(shù)據(jù)緩沖區(qū),具體的業(yè)務(wù)處理進程通過讀取緩沖區(qū)中的數(shù)據(jù)來處理,不直接從接受請求進程獲取數(shù)據(jù),并且采用先進先出的原則,保證先到達的數(shù)據(jù)先處理。
重構(gòu)后的前置機程序經(jīng)過半年來的穩(wěn)定運行,已經(jīng)完全做到了當(dāng)初我所設(shè)想的,通過重構(gòu)使因為前置機程序本身構(gòu)架問題所造成的錯誤率降為零。因為使用了多線程技術(shù),從而使程序在性能上得到了質(zhì)的飛躍,更重要的是給負責(zé)第三方對帳的同事減輕了不少不必要的工作量,另外,通過這次重構(gòu)我也從中學(xué)到了不少新東西,使我的編程思想得到了刷新。(信息設(shè)備科:常健林)