背景
做过2B类系统的同学都知道,2B系统最恶心的操作就是什么都喜欢批量,这不,我最近就遇到了一个恶心的需求——50个用户同时每人导入1万条单据,每个单据七八十个字段,请给我优化。
Excel导入技术选型
说起Excel导入的需求,很多同学都做过,也很熟悉,这里面用到的技术就是POI系列了。
但是,原生的POI很难用,需要自己去调用POI的API解析Excel,每换一个模板,你都要写一堆重复而又无意义的代码。
所以,后面出现了EasyPOI,它基于原生POI做了一层封装,使用注解即可帮助你自动解析Excel到你的Java对象。
EasyPOI虽然好用,但是数据量特别大之后呢,会时不时地来个内存溢出,甚是烦恼。
所以,后面某里又做了一些封装,搞出来个EasyExcel,它可以配置成不会内存溢出,但是解析速度会有所下降。
如果要扣技术细节的话,就是DOM解析和SAX解析的区别,DOM解析是把整个Excel加载到内存一次性解析出所有数据,针对大Excel内存不够用就OOM了,而SAX解析可以支持逐行解析,所以SAX解析操作得当的话是不会出现内存溢出的。
因此,经过评估,我们系统的目标是每天500万单量,这里面导入的需求非常大,为了稳定性考虑,我们最后选择使用EasyExcel来作为Excel导入的技术选型。
导入设计
我们以前也做过一些系统,它们都是把导入的需求跟正常的业务需求耦合在一起的,这样就会出现一个非常严重的问题:一损俱损,当大导入来临的时候,往往系统特别卡。
导入请求同其它的请求一样只能打到一台机器上处理,这个导入请求打到哪台机器哪台机器倒霉,其它同样打到这台机器的请求就会受到影响,因为导入占用了大量的资源,不管是CPU还是内存,通常是内存。
还有一个很操蛋的问题,一旦业务受到影响,往往只能通过加内存来解决,4G不行上8G,8G不行上16G,而且,是所有的机器都要同步调大内存,而实际上导入请求可能也就几个请求,导致浪费了大量的资源,大量的机器成本。
另外,我们导入的每条数据有七八十个字段,且在处理的过程中需要写数据库、写ES、写日志等多项操作,所以每条数据的处理速度是比较慢的,我们按50ms算(实际比50