背景
做过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算(实际比50ms还长),那1万条数据光处理耗时就需要 10000 * 50 / 1000 = 500秒,接近10分钟的样子,这个速度是无论如何都接受不了的。
所以,我一直在思考,有没有什么方法既可以缩减成本,又可以加快导入请求的处理速度,同时,还能营造良好的用户体验?
经过苦思冥想,还真被我想出来一种方案:独立出来一个导入服务,把它做成通用服务。
导入服务只负责接收请求,接收完请求直接告诉前端收到了请求,结果后面再通知。
然后,解析Excel,解析完一条不做其它处理直接就把它扔到Kafka中,下游的服务去消费,消费完了,再发一条消息给Kafka告诉导入服务这条数据的处理结果,导入服务检测到所有行数都收到了反馈,再通知前端这次导入完成了。(前端轮询)
如上图所示,我们以导入XXX为例描述下整个流程:
- 前端发起导入XXX的请求;
- 后端导入服务接收到请求之后立即返回,告诉前端收到了请求;
- 导入服务每解析一条数据就写入一行数据到数据库,同时发送该数据到Kafka的XXX_IMPORT分区;
- 处理服务的多个实例从XXX_IMPORT的不同分区拉取数据并处理,这里的处理可能涉及数据合规性检查,调用其他服务补齐数据,写数据库,写ES,写日志等;
- 待一条数据处理完成后给Kafka的IMPORT_RESULT发送消息说这条数据处理完了,或成功或失败,失败需要有失败原因;
- 导入服务的多个实例从IMPORT_RESULT中拉取数据,更新数据库中每条数据的处理结果;
- 前端轮询的接口在某一次请求的时候发现这次导入全部完成了,告诉用户导入成功;
- 用户可以在页面上查看导入失败的记录并下载;
这就是整个导入的过程,下面就开始了踩坑之旅,你准备好了吗?
聪明的同学会发现,(关注公号彤哥读源码一起学习一起浪)其实大批量导入跟电商中的秒杀是有些类似的,所以,整个过程引入Kafka来在削峰和异步。
初步测试
经过上面的设计,我们测试导入1万条数据只需要20秒,比之前预估的10分钟快了不止一星半点。
但是,我们发现一个很严重的问题,当我们导入数据的时候,查询界面卡到爆,需要等待10秒的样子查询界面才能刷出来,从表象来看,是导入影响了查询。
初步怀疑
因为我们查询只走了ES,所以,初步怀疑是ES的资源不够。
但是,当我们查看ES的监控时发现,ES的CPU和内存都还很充足,并没有什么问题。
然后,我们又仔细检查了代码,也没有发现明显的问题,而且服务本身的CPU、内存、带宽也没有发现明显的问题。
真的神奇了,完全没有了任何思路。
而且,我们的日志也是写ES的,日志的量比导入的量还更大,查日志的时候也没有发现卡过。
所以,我想,直接通过Kibana查询数据试试。
说干就干,在导入的同时,在Kibana上查询数据,并没有发现卡,结果显示只需要几毫秒数据就查出来了,更多的耗时是在网络传输上,但是整体也就1秒左右数据就刷出来了。
因此,可以排除是ES本身的问题,肯定还是我们的代码问题。
此时,我做了个简单的测试,我把查询和导入的处理服务分开,发现也不卡,秒级返回。
答案已经快要浮出水面了,一定是导入处理的时候把ES的连接池资源占用完了,导致查询的时候拿不到连接,所以,需要等待。
通过查看源码,最终发现ES的连接数是在RestClientBuilder类中写死的,DEFAULT_MAX_CONN_PER_ROUTE=10,DEFAULT_MAX_CONN_TOTAL=30,每个路由最大10,总连接数最大30,而且更操蛋的是,这两个配置是写死在代码里面的,没有参数可以配置,只能通过修改代码来实现了。
这里也可以做个简单的估算,我们的处理服务部署了4台机器,每台机器一共可以建立30条连接,4台机器就是120条连接,导入一万单如果平均分配,每条连接需要处理 10000 / 120 = 83条数据,每条数据处理100ms(上面用的50ms,都是估值)就是8.3秒,所以,查询的时候需要等待10秒左右,比较合理。
直接把这两个参数调大10倍到100和300,(关注公号彤哥读源码一起学习一起浪)再部署服务,测试发现导入的同时,查询也正常了。
接下来,我们又测试了50个用户同时导入1万单,也就是并发导入50万单,按1万单20秒来算,总共耗时应该在 50*20=1000秒/60=16分钟,但是,测试发现需要耗时30分钟以上,这次瓶颈又在哪里呢?
再次怀疑
我们之前的压测都是基于单用户1万单来测试的,当时的服务器配置是导入服务4台机器,处理服务4台机器,根据上面我们的架构图,按理说导入服务和处理服务都是可以无限扩展的,只要加机器,性能就能上去。
所以,首先,我们把处理服务的机器加到了25台(我们基于k8s,扩容非常方便,改个数字的事),跑一下50万单,发现没有任何效果,还是30分钟以上。
然后,我们把导入服务的机器也加到25台,跑了一下50万单,同样地,发现也没有任何效果,此时,有点怀疑人生了。
通过查看各组件的监控,发现,此时导入服务的数据库有个指标叫做IOPS,已经达到了5000,并且持续的在5000左右,IOPS是什么呢?
它表示一秒读写IO多少次,跟TPS/QPS差不多,说明MySQL一秒与磁盘的交互次数,一般来说,5000已经是非常高的了。
目前来看,瓶颈可能在这里,再次查看这个MySQL实例的配置,发现它使用的是超高IO,实际上还是普通的硬盘,想着如果换成SSD会不会好点呢。
说干就干,联系运维重新购买一个磁盘是SSD的MySQL实例。
切换配置,重新跑50万单,这次的时间果然降下来了,只需要16分钟了,接近降了一半。
所以,SSD还是要快不少的,查看监控,当我们导入50万单的时候,SSD的MySQL的IOPS能够达到12000左右,快了一倍多。
后面,我们把处理服务的MySQL磁盘也换成SSD,时间再次下降到了8分钟左右。
你以为到这里就结束了嘛(关注公号彤哥读源码一起学习一起浪)?
思考
上面我们说了,根据之前的架构图,导入服务和处理服务是可以无限扩展的,而且我们已经分别加到了25台机器,但是性能并没有达到理想的情况,让我们来计算一下。
假设瓶颈全部在MySQL,对于导入服务,我们一条数据大概要跟MySQL交互4次,整个Excel分成头表和行表,第一条数据是插入头表,后面的数据是更新头表、插入行表,等处理完了会更新头表、更新行表,所以按12000的IOPS来算的话,MySQL会消耗我们 500000 * 4 / 12000 / 60= 2.7分钟,同样地,处理服务也差不多,处理服务还会去写ES,但处理服务没有头表,所以时间也按2.7分钟算,但是这两个服务本质上是并行的,没有任何关系,所以总的时间应该可以控制在4分钟以内,因此,我们还有4分钟的优化空间。
再优化
经过一系列排查,我们发现Kafka有个参数叫做kafka.listener.concurrency,处理服务设置的是20,而这个Topic的分区是50,也就是说实际上我们25台机器只使用了2.5台机器来处理Kafka中的消息(猜测)。
找到了问题点,就很好办了,先把这个参数调整成2,保持分区数不变,再次测试,果然时间降下来了,到5分钟了,后面经过一系列调整测试,发现分区数是100,concurrency是4的时候效率是最高的,最快可以达到4分半的样子。
至此,整个优化过程告一段落。
总结
现在我们来总结一下一共优化了哪些地方:
- 导入Excel技术选型为EasyExcel,确实非常不错,从来没出现过OOM;
- 导入架构设计修改为异步方式处理,参考秒杀架构;
- Elasticsearch连接数调整为每个路由100,最大连接数300;
- MySQL磁盘更换为SSD;
- Kafka优化分区数和kafka.listener.concurrency参数;
另外,还有很多其它小问题,限于篇幅和记忆,无法一一讲出来。
后期规划
通过这次优化,我们也发现了当数据量足够大的时候,瓶颈还是在存储这块,所以,是不是优化存储这块,性能还可以进一步提升呢?
答案是肯定的,比如,有以下的一些思路:
- 导入服务和处理服务都修改为分库分表,不同的Excel落入不同的库中,减轻单库压力;
- 写MySQL修改为批量操作,减少IO次数;
- 导入服务使用Redis来记录,而不是MySQL;
但是,这次要不要把这些都试一遍呢,其实没有必要,通过这次压测,我们至少能做到心里有数就可以了,真的等到量达到了那个级别,再去优化也不迟。
好了,今天的文章就到这里了,另外,彤哥的文章已经全部分类汇总好了,关注彤哥读源码来领取吧。