工作总结26 发票同步方案的总结

业务场景： 

把各台客户端机器里的开票软件里的发票数据，同步到服务器的信息系统里。

改进前的方案：

      利用Netty框架实现的同步工具，把发票数据由客户端推送到服务器端，由服务器端的数据同步到互联网库的税控发票表里，然后互联网库再利用触发器实时推送模式同步到商密网数据库的税控发票表里。

如图所示：

       这种方案，导致了数据库的连接没有释放，导致Netty的工作线程一直被占用着，最终导致服务器端的线程不能释放，一直被占用，其他的同步请求就没法接受处理，Netty服务器端会报连接状态：CLOSE_WAIT。最终用户的发票一直同步不成功，显示连接超时！只有个别的用户会成功。

分析原因：

1、 Netty的线程一直被占用着，开始认为是数据库连接被占用的原因是代码层面导致的原因，于是把连接对象都由成员变量改成局部变量，同时调用平台的连接释放函数去释放资源，但是依然存在这个问题。

2、 分析了有可能是Netty框架开发的客户端和服务器端的程序导致的，仔细分析了编写的Netty代码，加上网上查找各种情况和案例，排除了是框架的原因。

3、 最后定位到数据库层面上，可能是触发器导致的。于是把两个税控发票表的删除触发器和插入触发器都删除掉了，各个客户端的发票竟然都同步成功了。

互联网的库向商密网同步发票数据时，删除发票触发器触发，插入触发器再接着触发，由于是跨库操作删除和插入，由于不在一个事务里，商密网的库里数据可能存在插入时，又要删除时，可能发票数据会同时出现争用，出现数据库操作的阻塞，互联网库的连接就一直没有被释放掉，占满了服务器端的所有线程资源。

改进后的方案：

      针对上面存在的问题，对方案做了进一步的改进，把触发器实现的实时同步改成了定时异步同步，把互联网库里的税控发票表的两个触发器都删除掉，对互联网库和商密网库里的税控发票表做了部分改进设计，添加了同步时间，同步标志，同步IP字段，方便追踪数据是否成功，在商密网库里建立了存储过程，同步oracle的dblink来连接互联网库，通过拉取模式来拉过来互联网符合要求同步的发票数据，定时的功能是通过操作系统的定时任务，定时执行oracle的存储过程。注意：在写存储过程的时候，一定要先全部删除后，在进行插入，不要放到一个循环里，因为是在一个事务里同时操作，会把插入的符合删除条件的数据删除，这样同步的逻辑就错啦。

如图所示：