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