【手把手教你】服务端请求如何处理批量操作？【...... 省略了N张各种表情包】

【思考点滴】

作者 : 杨考  微信号 : devin_cn_hd_09_16

1、背景

产品经理:

产品经理过来唠嗑，说我们需要支持一下批量处理多条数据，看一下有什么难点?啥时候可以开发完成？【...... 省略了N张各种表情包】

服务端开发人员

单个处理很简单，批量处理就是加个循环处理，最多就是通过入参区分一下单个请求的差异。

2、开始接锅

第一阶段：批量处理相同的内容

后端研发 : 外侧一个循环就搞定了，一个请求照样能处理。

功能上线一段时间，线上报故障了

业务人员 : 某大KA通过批量处理，设置旗下商户的准入金门槛，发现有一部分设置成功，一部分还没更新成功，服务端人员快紧急处理一下！

后端开始定位，结论是 : "啊，这个大KA竟然有3千个商户，我们请求处理超时了"。

后端解决方案 : 同步请求开始入MQ等待异步处理..    逃过一劫

第二阶段：批量处理，每个请求可以处理不同的内容

异步处理，让服务端同学舒坦了一阵子。

业务人员 : 紧接着业务又报问题了，大KA刚批量修改了商户的A、C属性，接着又修改了部分B属性，为什么商户内容修改需要审核两次呢?看一下，相邻的两次修改能不能合并为一次修改。

后端开始定位，结论是:"大KA两次修改时差确实很小，因为在这个时间差内，我们MQ里又堆积了N多条其它的修改信息，所以这个大KA的两次修改的处理时差被放大了"。

服务端开始抓狂的时候到了，原本简单清晰的流程，自从接了批量修改之后，代码开始变的有些糟糕。但问题还是要解决。

后端解决方案 : 用数据库开始记录每个商户的修改参数，异步处理的时候，对商户内容的多次修改进行合并。

第三阶段 : 批量处理，存在结果依赖

业务人员 : 紧接着业务又报问题了，大KA刚批量修改了商户的A、C属性，紧接着又通过条件判断，对C属性值为101的商户进行批量修改，发现部分商户第二次批量修改失败。

后端开始定位，结论是:"大KA两次修改时差确实很小，而且我们也对批量修改进行了合并，但是因为第一次批量修改没有完成，导致第二次的被修改对象选择错误"。

后端解决方案 : 产品同学决定以下，毕竟这不是问题，我们加个延时，延时1分钟后才能进行第二次修改。又开始给自己埋坑中... ...【...... 省略了N张各种表情包】

总结 :

为了让大家快速认识问题，如上列举了部分欠合理的举子。但最终就是让大家明白一个道理:

1、开发人员拿到需求的时候，一定要考虑清楚，单个请求数量中最多能承受多少个请求处理、请求超时、异常处理、对其它交互对象的影响

2、需要澄清，后续是否存在交叉修改，依赖修改

问题不是在发生的时候进行补救，而是需求沟通的时候就要kill掉某些case，给出一个合理的规则更重要。

致亲爱的研发人员，可以看看自己曾经入过那个坑