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