案例引入
公司的运营同事每个月都需要给大批量的指定用户发送优惠券，数量以万为单位 。
这些指定的用户因为没有共性条件而无法在运营平台直接筛选出来，只能将用户数据整理成Excel表格，然后将表格内的数据批量导入到运营平台中；
然而，运营平台的批量导入发送目标数据的功能仅支持单次导入最多1000条，假设运营需要给15万的指定用户发送优惠券，意味着他需要在运营平台批量导入分150次才能将所有发送目标导入完毕；
150次啊，运营同学，已疯 。
批量导入支持单次最多导入1000条，为什么不能是1万，甚至是10万条？
从批量导入功能的操作中，请求的发起与响应过程来看：
文章插图
我们可以发现一点，用户操作，前端会发起请求，要求后端即刻响应，并在“一定时间”内给出处理的结果 。
这个“一定时间”是多长？
我再次向研发的同事们确认，目前运营平台的架构设计，支持一个请求的最大响应时长为8秒 。如果8秒内，批量导入的数据未能完成响应的处理，那么请求将响应超时，即刻返回处理失败的结果 。
这意味着，一批数据从上传，到数据校验（上传数据需与数据库的百万条数据逐一对比，避免上传了脏数据），到缓存在数据库中，这一系列的操作必须在8秒内完成 。
所以，为了保证这一切都能在“一定时间内”完成后正常返回给前端处理结果，单次批量导入的数据量只能限制在1000条左右 。
如何才能将批量导入1000条的限制解开呢？
同步处理方式
显然，案例中批量导入的功能便是基于同步处理的逻辑进行设计的，用户操作时，前端会发送请求，后端必须处理完请求的内容，才会返回给前端结果 。
在后端响应请求期间，用户如果关闭界面，处理就中断了，这个过程中用户只能被动的等待，如果请求的响应时间较长，用户就容易产生茫然感，甚至焦虑，这样的用户体验不够友好 。
因此，同步处理往往对应着响应超时的判断机制，当请求的响应时间超出了设定的最大响应时长，即使请求并没有被处理完，后端也会即刻返回一个处理结果（操作失败等异常状态），避免用户长时间等待 。
值得一提的是，当请求超时后，后端仍会继续处理前端请求时导入的数据，但是能否正常处理完是不确定的，而且此时用户也不再能知道他发起请求的实际处理结果了，因为在超时的那一刻，这个请求的处理结果已经被后端返回失败而定性了 。
不过，我们考虑用户体验的前提，是功能已经满足了用户的核心诉求（能够更快的一次导入更多的数据量），因而批量导入这个功能，以同步处理的逻辑做处理就不太合适了 。
异步处理方式
什么是异步处理？当用户在前端操作时，前端发送请求，后端收到请求后即刻给前端反馈“兄弟，你拜托的事儿我知道了，会进行处理，你该干嘛干嘛去吧” 。
所以在后端处理请求的过程中，用户通常可以关闭客户端或退出当前页面，去做其他的事情，无须在当前页面等待，后端也就不必在一定时间内返回给前端处理结果 。
没有了“一定时间”的限制，1000条的限制问题自然迎刃而解；
事实上，采取异步处理逻辑设计的迭代方案，单次的批量导入数量可增加到5万条，直接翻了50倍！
虽然异步处理的过程中，用户发起请求后，即可退出当前页面去做其他的事情，但用户肯定是关注最终的结果的 。因此，异步处理通常会搭配一个结果查询功能：它可能是一个刷新当前页的按钮，也可能是一个查询弹窗，便于用户去查询最后处理的结果，知晓请求的处理情况 。
这样，一个真实的，切合用户使用场景的批量导入功能就完成了 。
同步处理、异步处理这2种处理方式，从批量导入的案例来看，异步处理远胜于同步处理 。
但，异步处理总是优于同步处理吗？
实际上，采用同步处理方式的产品方案也不在少数；
在我们常见的打车过程中，当到达目的地，司机会在App内滑动到达目的地，并确认附加费金额，然后司机端、乘客端APP便会自动展示出整段行程的费用，这个过程，便是采用同步处理的方式 。
文章插图
推荐阅读
- AMD|时隔2年半 AMD悄悄更新Zen/Zen2处理器微代码：内容保密
- 香花茶与拌花茶的区别,花茶的茶胚处理
- 关于电动车上牌，你想知道的，都在这里了
- 多少温度冲泡合适,花茶的茶胚处理
- 难忘的中秋之夜 关于中秋节的文章
- 东和大益普洱茶价格,大益普洱茶最新价格价格表
- 3歩快速有效做好死链接和错误链接的处理
- 手机如何控制另一台手机同步
- 信用卡利息越来越高要怎么处理
- REST API是什么