【思考点滴】
作者 : 杨考 微信号 : 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，给出一个合理的规则更重要。
致亲爱的研发人员，可以看看自己曾经入过那个坑