不用异步队列实现异步处理较大数量级导入的开发记录20190612140700

简介: 能异步别同步,毕竟对于性能、响应都是好的。最近在做基于老系统拓展批量导入的功能,简单做一下记录,虽然初级但是至少培养记录总结的习惯吧。

能站别躺,为什么?因为能减肥呀。一样的,能异步别同步,毕竟对于性能、响应都是好的。最近在做基于老系统拓展批量导入的功能,与老系统的交互就用DUBBO RPC了,不接MQ了。
如果是走RPC同步业务处理接口,就不能简单粗暴地直接:
1
从上面的交互可以看出,如果这样实现,数据量一大的话肯定各种问题:
1.数据量大的话rpc执行时间长,有可能HTTP请求会超时;
2.中间各个网络节点IO流压力大;
3.文件处理有可能内存溢出;
4.发生运行时异常概率非常高,分布式事务导致结果不一致:RPC那边已经提交了,但是调用方后面发生异常导致两边不一致;
5.客户端响应久,交互差...
那这样肯定要用异步了,不走异步队列的话,用定时任务把。处理数据冗余在数据库,定时任务定时去拿数据处理,维护处理结果:
2
这样执行速度优化了很多,前端响应也快。但是又怕定时器并发问题,虽然是一个服务,但是单个任务执行慢的话怕下一次触发定时任务同步造成脏读,错误并发处理。所以了解了下Spring的定时任务,发现Spring的定时任务默认是单线程的,那这样就不用担心,不然要加锁防止并发了。既然涉及到定时任务的并发控制,顺便记录一下比较简单的设置定时器并发:
一、在定时器上使用@Async注解实现异步任务,并需在启动类配合加上 @EnableAsync才会生效;
二、 手动设置定时任务的线程池大小:不使用@Async注解,新增启动代码配置类:
3
好了,简单做一下记录,虽然初级但是至少培养记录总结的习惯吧。

目录
相关文章
|
5月前
|
监控 网络协议 API
Typhoeus库在处理大量并发请求时的优化技巧
Typhoeus库在处理大量并发请求时的优化技巧
|
3月前
|
数据采集 存储 NoSQL
提高爬虫性能的 5 个关键技巧:从并发到异步执行
本文介绍了提高网络爬虫性能的五个关键技巧:并发请求、异步执行、使用代理IP、限制请求频率与休眠时间、优化数据提取与存储。结合拼多多的实际案例,展示了如何通过这些技术优化爬虫效率,确保数据采集的高效性和稳定性。
317 0
|
6月前
|
存储 缓存 NoSQL
架构设计篇问题之在数据割接过程中,多线程处理会导致数据错乱和重复问题如何解决
架构设计篇问题之在数据割接过程中,多线程处理会导致数据错乱和重复问题如何解决
|
6月前
|
消息中间件 缓存 并行计算
每秒钟承载600万订单级别的无锁并行计算框架 Disruptor学习
每秒钟承载600万订单级别的无锁并行计算框架 Disruptor学习
|
8月前
|
前端开发 UED
面试官:【后端一次性返回10万条数据怎么处理/后端发送大数据量的数据如何处理】
面试官:【后端一次性返回10万条数据怎么处理/后端发送大数据量的数据如何处理】
162 0
|
XML 缓存 API
百万级 Excel导入数据库 效率太低? 基于 SAX 的事件模型 导入,将会解决 效率问题
百万级 Excel导入数据库 效率太低? 基于 SAX 的事件模型 导入,将会解决 效率问题
105 0
|
设计模式 算法 安全
并发 并行 同步 异步 你分清了吗
并发 并行 同步 异步 你分清了吗
|
数据处理 Go
让消费数据处理更快版本2(有并发控制)-一次性并发获取或者初始化任务最快有效方式
让消费数据处理更快版本2(有并发控制)-一次性并发获取或者初始化任务最快有效方式
|
SQL 消息中间件 JavaScript
效率加倍,高并发场景下的接口请求合并方案
效率加倍,高并发场景下的接口请求合并方案
|
SQL NoSQL 安全
只改了五行代码接口吞吐量提升了10多倍
首先,提升日志打印级别到DEBUG。emm... 提升不大,好像增加了10左右。 然后,拆线程 @Async 注解使用线程池,控制代码线程池数量(之前存在3个线程池,统一配置的核心线程数为100)结合业务,服务总核心线程数控制在50以内,同步增加阻塞最大大小。结果还可以,提升了50,接近200了。
178 0

相关实验场景

更多