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