1.为什么用异步化处理

异步化的目的无非就是为了减少response响应时间, 提高用户体验, 提高资源(CPU, IO)利用率.

同步请求示意图

异步请求示意图

这里假设function1和service1都是比较耗时的操作, 调用时间如下:

• function1 = 2s
• service1 = 3s

那么最后的结果如下:

• 同步请求的request等待时间 = 2s + 3s = 5s
• 异步请求, 由于是请求立马得到相应的, 时间消耗应该在100ms之内.
  • 后续的获得结果()这个步骤不一定是每个场景都需要(就是需要的话, 这个步骤应该也是一个很快的操作, 控制在1s之内)

结论: 用异步化处理可以减少RT(响应时间), 优化用户体验.

2.哪些场景比较适合用异步化来处理呢 ?

异步化处理有它的好处, 但不是所有的请求都适合用异步化.

异步化的缺点:

1. 用户的交互次数可能会增加
2. 编码变得复杂(要考虑多线程问题)

下面列举一些比较适合用异步化来处理的场景.

2.1 弱依赖的事务

比如一条数据的修改, 需要发送通知.

这里的发送通知就是弱依赖的事务(一般来说是这样的), 那么这个发送通知就可以异步化.

2.2 长事务

比如导入, 导出.

这是一个非常耗时的事务, 有时候可能要几分钟甚至十几分钟的, 这样的事务没必要让用户一直等着.

直接提示一个"正在导入/正在导出", 然后后台慢慢执行就好了.

做的好一点的, 还可以监控一下整个进度, 在页面上显示出来.

2.3 非业务功能

比如说日志记录, 性能测试等.

特别是这些操作还需要操作数据库, 或者有一些网络请求的时候, 特别要注意异步化处理.

3.请求异步化处理要注意的问题

先看一下tomcat内部的Request请求流程:

注意上图的1.3.1和1.3.2, tomcat会在一个请求结束之后, 清理session和cookie中的信息.

结论:

由于异步化必然会产生一个新的线程, 然后这个新的线程对于request, response相关的操作(主要是针对cookie和session)是不能进行的, 因为cookie和session可能会被清除, request中的attribute估计也会被清理掉(待研究)

但是如果实在要依赖于request中的信息的话, 比如要获取登录用户的一些信息(一般放在session或cookie中), 也可以提前把request中需要的信息copy一份出来, 供异步线程使用.

水平有限, 如有错误, 欢迎拍砖.