——我对公司机房数据处理流程的改造体会

         公司第三方代收水费前置机程序开发肇始于2014年。当时因为只有邮政一家接入，所以采用的数据流处理方式为串行，如图1所示，流程为3个步骤：接受请求、处理请求、返回结果。 

这个处理方式对于“一对一”的请求没有任何问题，除了效率上差一些外起码不会出现问题。但是随着公司更多的第三方平台的接入，这种串行处理方式就暴漏出它的问题了，最致命的弱点恰恰就在一对一这个问题上。“一对一”的意思就是同一时刻只处理一个业务请求，只有等数据全部处理完成后，才会再接受另一个请求；但是处理请求是需要时间的，如果在处理请求期间有另外一个平台的业务请求到来，那么就会被丢弃从而出现账务问题。这就是为什么在新接入了建行、农行、微信公众号、微信生活缴费、支付宝生活缴费、移动荷包等第三方平台之后不断出现了账务问题的原因所在。

    问题既然找到了，那么要怎么解决呢？对于需要同一时刻处理多个请求的问题，唯一的解决办法是改串行处理方式为并行方式，如图2所示，前置机程序同时接受多个业务请求并且处理。从原理来说很简单，但是对于程序的改造来说工程量却是十分巨大。这就好比你要把一栋2层楼的房子改造成20层楼的高楼，唯一的办法就是推倒重来。为此，要想把串行方式改为并行方式，就需要对原来的程序进行几乎推倒重来的大改进。

    经过4个月的努力，程序的重构终于完成，代码80%以上被重写，数据处理流程参见图3，当有业务请求到来的时候首先由接受请求进程将请求数据缓存到相应的业务数据缓冲区中，然后分别由具体的业务处理进程从缓冲区中获取到请求数据，并作相应处理，完成后将请求处理结果返回给请求者。

        从图3可以看出重构后的程序中，一共采取了5个进程，分别是“接受请求进程，交费处理进程，冲正处理进程和2个查询处理进程”这里使用2个查询处理进程是因为从以往的日志分析中得出查询业务量远远多于其他的业务量。并且这5个进程是独立运行的，相互之间没有直接的制约关系。同时为了避免出现数据丢失的情况，我还使用了3个数据缓冲区，既查询请求数据缓冲区、交费请求数据缓冲区、冲正请求数据缓冲区，具体的业务处理进程通过读取缓冲区中的数据来处理，不直接从接受请求进程获取数据，并且采用先进先出的原则，保证先到达的数据先处理。

重构后的前置机程序经过半年来的稳定运行，已经完全做到了当初我所设想的，通过重构使因为前置机程序本身构架问题所造成的错误率降为零。因为使用了多线程技术，从而使程序在性能上得到了质的飞跃，更重要的是给负责第三方对帐的同事减轻了不少不必要的工作量，另外，通过这次重构我也从中学到了不少新东西，使我的编程思想得到了刷新。(信息设备科：常健林）