不同场景下，用户的核心诉求是不一样的。因此，在产品方案的设计中，当我们充分理解用户的核心诉求，同、异步的处理方式，也就有了选择。
案例引入：
公司的运营同事每个月都需要给大批量的指定用户发送优惠券，数量以万为单位。
这些指定的用户因为没有共性条件而无法在运营平台直接筛选出来，只能将用户数据整理成Excel表格，然后将表格内的数据批量导入到运营平台中。
然而，运营平台的批量导入发送目标数据的功能仅支持单次导入最多1000条，假设运营需要给15万的指定用户发送优惠券，意味着他需要在运营平台批量导入分150次才能将所有发送目标导入完毕；
150次啊，运营同学，已疯。
批量导入支持单次最多导入1000条，为什么不能是1万，甚至是10万条？
从批量导入功能的操作中，请求的发起与响应过程来看：
我们可以发现一点，用户操作，前端会发起请求，要求后端即刻响应，并在“一定时间”内给出处理的结果。
这个“一定时间”是多长？
我再次向研发的同事们确认，目前运营平台的架构设计，支持一个请求的最大响应时长为8秒。如果8秒内，批量导入的数据未能完成响应的处理，那么请求将响应超时，即刻返回处理失败的结果。
这意味着，一批数据从上传，到数据校验（上传数据需与数据库的百万条数据逐一对比，避免上传了脏数据），到缓存在数据库中，这一系列的操作必须在8秒内完成。
所以，为了保证这一切都能在“一定时间内”完成后正常返回给前端处理结果，单次批量导入的数据量只能限制在1000条左右。
如何才能将批量导入1000条的限制解开呢？
1. 同步处理方式
显然，案例中批量导入的功能便是基于同步处理的逻辑进行设计的，用户操作时，前端会发送请求，后端必须处理完请求的内容，才会返回给前端结果。
在后端响应请求期间，用户如果关闭界面，处理就中断了，这个过程中用户只能被动的等待，如果请求的响应时间较长，用户就容易产生茫然感，甚至焦虑，这样的用户体验不够友好。
因此，同步处理往往对应着响应超时的判断机制，当请求的响应时间超出了设定的最大响应时长，即使请求并没有被处理完，后端也会即刻返回一个处理结果（操作失败等异常状态），避免用户长时间等待。
值得一提的是，当请求超时后，后端仍会继续处理前端请求时导入的数据，但是能否正常处理完是不确定的，而且此时用户也不再能知道他发起请求的实际处理结果了，因为在超时的那一刻，这个请求的处理结果已经被后端返回失败而定性了。
不过，我们考虑用户体验的前提，是功能已经满足了用户的核心诉求（能够更快的一次导入更多的数据量），因而批量导入这个功能，以同步处理的逻辑做处理就不太合适了。
2. 异步处理方式
什么是异步处理？当用户在前端操作时，前端发送请求，后端收到请求后即刻给前端反馈“兄弟，你拜托的事儿我知道了，会进行处理，你该干嘛干嘛去吧”。
所以在后端处理请求的过程中，用户通常可以关闭客户端或退出当前页面，去做其他的事情，无须在当前页面等待，后端也就不必在一定时间内返回给前端处理结果。
没有了“一定时间”的限制，1000条的限制问题自然迎刃而解。
事实上，采取异步处理逻辑设计的迭代方案，单次的批量导入数量可增加到5万条，直接翻了50倍！
虽然异步处理的过程中，用户发起请求后，即可退出当前页面去做其他的事情，但用户肯定是关注最终的结果的。因此，异步处理通常会搭配一个结果查询功能：它可能是一个刷新当前页的按钮，也可能是一个查询弹窗，便于用户去查询最后处理的结果，知晓请求的处理情况。
这样，一个真实的，切合用户使用场景的批量导入功能就完成了。
同步处理、异步处理这2种处理方式，从批量导入的案例来看，异步处理远胜于同步处理。
实际上，采用同步处理方式的产品方案也不在少数。
在我们常见的打车过程中，当到达目的地，司机会在app内滑动到达目的地，并确认附加费金额，然后司机端、乘客端APP便会自动展示出整段行程的费用，这个过程，便是采用同步处理的方式。
试想这个过程，采用异步处理的方式，这个场景会变成什么样子？
司机到达了目的地，确认附加费金额后，需要通过刷新或点击其他按钮，才能获取行程费用；乘客也需要通过刷新获取到行程费用，然后才能去支付。
这样的用户操作流程，将导致大批量的乘客不会在第一时间去支付行程费用，直接影响了公司的坏账率。
事实上，同步、异步的处理方式各有优劣，在合适的场景选择对应的处理方式才能达到更好的效果。
同、异步处理方式在什么场景下采用更为合适呢?
从上述2个案例中，我们可以发现，不同场景下，用户的核心诉求是不一样的，对于批量导入，用户更关注的是处理的性能，而行程费用的计算，用户更关注的是结果的处理效率。
