知识收集9【原创】

账套间大数据量同步的解决方案

    在忙于其他项目的开发过程中，突然有一家客户反馈一个大数据量问题，当物品基础数据等大数据同步到另一个账套时，系统就卡死，崩溃啦。

    我拿到用户的数据环境，用Visual GC监测工具，监测了一看：

    整个的伊甸园内存区和旧时代内存区都爆满，jvm直接卡死，tomcat直接崩溃

在同步的时候，瞬间内存快速爆满，当时把我吓了一跳。

    开始的时候，想当然的认为加大内存就可以解决此问题，于是jvm的最大内存由原来的1024M，扩到

1500M，内存还是直接爆满。

    最好用Visual VM监测到，在同步的时候，产生了大量的实例对象，GC来不及回收，直接耗尽整个内存。

于是确定，可能是程序出了问题。

    于是，开始从程序一步一步的查找，开始的第一个方法，就是查询物品的数据量比较大4.7W多条，直接耗尽了可怜的本身就不大的内存。通过在群里，开发人员的讨论和建议，对于大数据量的查询，我做了分页形式的批量查询，然后批量处理数据，批量同步数据。

     但是，再同步的过程中，会产生逻辑问题，为了不改变现有的业务逻辑和数据问题，我把处理后的数据，一次同步过去，监控了下同步的过程中，系统还是可以承受的。

      可是，同步的过程中，时间问题产生了，同步一次，大约要至少3个小时，这是多么可怕的事情，我又遇到了同步的时间问题，我在思考究竟哪里消耗这么长的时间，于是又重新回归程序的定位，查找，看了一遍代码后，看到代码中很多不足之处，进行了一一优化，最终发现了有个xml文件读取，解析放到了循环里面，导致耗费大部分时间。设置了一个全局变量，值解析一次xml文件，然后循环过程中，都从这个变量里去取相应的配置信息。

     通过测试以后，时间终于降下来了，现在时间大约10分钟左右，这令我相当的振奋不已。

     不过在最后同步完数据的后处理时代，内存很快增高不少，于是定位到更新处理代码段的查询，也做了分页查询处理。

     另外，进行同步的过程中，发现JVM内存还是不是很稳定，总是升高，不往下降，为了保持内存跟趋于稳定，我每2W条的数据处理，就做一下 system.gc()垃圾回收，虽然会占用一点时间，但是对整体时间效率上还是可以接受的，这样做保证了系统趋于稳定。

     在往数据库同步的过程中，也做了基本的垃圾回收处理。

     优化后的处理结果如下图：

     由于同步的业务逻辑校验，处理等都要耗费时间，在时间效率上还是稍微差点，但是整体上应该还是满足客户使用的。

     为了不使当前的页面卡死，把原来的同步提交，改成了异步提交处理。

     为了使同步的日志，加载到页面不至于卡死，改成了页面下载的模式，下载下来直接在txt文件里查看。

     以上，就是我做得一些基本优化。