——我對公司機房數據處理流程的改造體會(huì )

         公司第三方代收水費前置機程序開(kāi)發(fā)肇始于2014年。當時(shí)因為只有郵政一家接入，所以采用的數據流處理方式為串行，如圖1所示，流程為3個(gè)步驟：接受請求、處理請求、返回結果。 

這個(gè)處理方式對于“一對一”的請求沒(méi)有任何問(wèn)題，除了效率上差一些外起碼不會(huì )出現問(wèn)題。但是隨著(zhù)公司更多的第三方平臺的接入，這種串行處理方式就暴漏出它的問(wèn)題了，最致命的弱點(diǎn)恰恰就在一對一這個(gè)問(wèn)題上?！耙粚σ弧钡囊馑季褪峭粫r(shí)刻只處理一個(gè)業(yè)務(wù)請求，只有等數據全部處理完成后，才會(huì )再接受另一個(gè)請求；但是處理請求是需要時(shí)間的，如果在處理請求期間有另外一個(gè)平臺的業(yè)務(wù)請求到來(lái)，那么就會(huì )被丟棄從而出現賬務(wù)問(wèn)題。這就是為什么在新接入了建行、農行、微信公眾號、微信生活繳費、支付寶生活繳費、移動(dòng)荷包等第三方平臺之后不斷出現了賬務(wù)問(wèn)題的原因所在。

    問(wèn)題既然找到了，那么要怎么解決呢？對于需要同一時(shí)刻處理多個(gè)請求的問(wèn)題，唯一的解決辦法是改串行處理方式為并行方式，如圖2所示，前置機程序同時(shí)接受多個(gè)業(yè)務(wù)請求并且處理。從原理來(lái)說(shuō)很簡(jiǎn)單，但是對于程序的改造來(lái)說(shuō)工程量卻是十分巨大。這就好比你要把一棟2層樓的房子改造成20層樓的高樓，唯一的辦法就是推倒重來(lái)。為此，要想把串行方式改為并行方式，就需要對原來(lái)的程序進(jìn)行幾乎推倒重來(lái)的大改進(jìn)。

    經(jīng)過(guò)4個(gè)月的努力，程序的重構終于完成，代碼80%以上被重寫(xiě)，數據處理流程參見(jiàn)圖3，當有業(yè)務(wù)請求到來(lái)的時(shí)候首先由接受請求進(jìn)程將請求數據緩存到相應的業(yè)務(wù)數據緩沖區中，然后分別由具體的業(yè)務(wù)處理進(jìn)程從緩沖區中獲取到請求數據，并作相應處理，完成后將請求處理結果返回給請求者。

        從圖3可以看出重構后的程序中，一共采取了5個(gè)進(jìn)程，分別是“接受請求進(jìn)程，交費處理進(jìn)程，沖正處理進(jìn)程和2個(gè)查詢(xún)處理進(jìn)程”這里使用2個(gè)查詢(xún)處理進(jìn)程是因為從以往的日志分析中得出查詢(xún)業(yè)務(wù)量遠遠多于其他的業(yè)務(wù)量。并且這5個(gè)進(jìn)程是獨立運行的，相互之間沒(méi)有直接的制約關(guān)系。同時(shí)為了避免出現數據丟失的情況，我還使用了3個(gè)數據緩沖區，既查詢(xún)請求數據緩沖區、交費請求數據緩沖區、沖正請求數據緩沖區，具體的業(yè)務(wù)處理進(jìn)程通過(guò)讀取緩沖區中的數據來(lái)處理，不直接從接受請求進(jìn)程獲取數據，并且采用先進(jìn)先出的原則，保證先到達的數據先處理。

重構后的前置機程序經(jīng)過(guò)半年來(lái)的穩定運行，已經(jīng)完全做到了當初我所設想的，通過(guò)重構使因為前置機程序本身構架問(wèn)題所造成的錯誤率降為零。因為使用了多線(xiàn)程技術(shù)，從而使程序在性能上得到了質(zhì)的飛躍，更重要的是給負責第三方對帳的同事減輕了不少不必要的工作量，另外，通過(guò)這次重構我也從中學(xué)到了不少新東西，使我的編程思想得到了刷新。(信息設備科：常健林）