SaaS系统接口同步三方平台的优化方案
后端产品体系的旧功能出了问题，只能在技术协助下，慢慢摸索追溯旧逻辑，搞清楚才能谈得上优化。
本文主角是一个SaaS模式的“后台发货系统”，对接美团等O2O平台的订单。目的是将各销售渠道的订单统一管理，完成发货。
既然统一发货，就少不了做统一的库存同步到销售渠道的机制。这样才能确保各平台数据互通，良性运营。
本次案例就来自库存价格同步机制这块的优化。
01 产品模型
整个业务模型大概是这样的：
该图表自下往上，分别是：
- 最下是“商户WMS”：作为真实的门店和门店商品库存、价格的来源。（因为是O2O，所以库存就来自实体门店）。
- 图中间是SaaS系统的“商户商品后台”：生成平台+线上门店+商品维度的数据清单，以衔接下端WMS和上端平台后台的数据。
- 最上面是O2O平台的后台：各渠道后台通过统一接口，统一在发货系统中对接，节约成本，数据互通。
需注意的是：由于是O2O，同一商品，在不同平台的不同门店，价格可能不同。所以若有n个实体店，m个商品的话，那么在每个平台，商户最多就要维护n*m条数据。
若w个销售渠道（平台），那么最多就要维护n*m*w条数据。这个客观现实就为本次事件埋下伏笔。
02 核心功能：同步库存、价格给第三方平台
功能基于模型，所以正向功能就是：库存价格变化，则同步到对应的各个平台。
触发条件除了WMS增量自动同步之外，还需要手动触发同步的机制。
比如，美团打折活动结束，就要触发同步WMS的价格进行恢复。若此时不具有触发增量的条件，就需要手动触发。
于是增加了批量、单个<同步到平台>的功能。
至此，触发同步的条件就确定了：单个同步、批量同步、增量自动同步。
功能流程如下图：
03 技术实现机制
总体机制：不同平台的商品，从WMS搜集待同步的数据，然后集中后发车完成同步。
第一期的方案是采用“同步池”，汇集所有的同步请求。即：将来自于WMS的定时增量推送、页面批量操作、单个操作的同步请求数据，集中在同步池中。
再按照各自的去向，寻找对应的平台接口，此时需服从各平台的限流规则。
限流规则：就是平台限制接口被请求的次数。比如美团限制每天只支持10万次的同步请求。
整理后的技术实现流程图：
04 出现的问题
主要有三个问题表现：同步池中的数据量会很大；经常量丢数据导致同步失败；用户等待时间过长。
1. 数量大的原因
1）基数大
由于各个平台和门店按照每个商户有200个连锁店，每个商户有2000个商品，那么就又有20万条基础数据。
若同时使用3个平台，最大就有60万基础数据。
2）触发次数多
假设不同平台和门店在正常销售，那么WMS的库存就会不停变化，于是就会不停地增量推送数据，请求同步到平台。
同时，商户又在单个或批量进行同步。商户为确保万无一失还会选择重复操作同步。
2. 丢数据的原因
- 三方平台限流，提交过多的数据就被限制不执行。若平台不反馈失败数据，那么失败后我们也不知道遗漏了哪些。
- 数据量过大，占用线程挤满，资源不够。
3. 执行时间太久的原因
目前平台的限流大致都是100条/秒，一个门店按照2000条商品，最快10秒完成，正常情况下20w商品数据需要近一小时。
总结以上，根源是数据量过大的问题。监控到2天有300w+的同步任务产生。
这就导致请求失败过多，用户继续重新同步，恶性循环，导致同步任务可能会很长一段时间无法降低，任务积压。不丢都难。
05 优化方案
1. 降低批量操作的频次
1）将同步库存和同步价格按钮分开
最初，同步库存和价格的按钮是在一起的，即<同步库存价格>。
这就导致每点击一下，就要同时同步库存和价格到三方平台的后台。
而事实上，价格的变更很少见，而库存的同步相对比较频繁（任何一个平台的任何一个门店产生订单，都会引发异动）。
如果不拆开，那么每次的请求都双份的（注：平台接口是支持拆开的）。
2）限制频繁操作同步按钮
同步库存货价格的按钮点击之后，若上个任务没执行完，则按钮不允许再次操作。
表面上看，若不做限制，貌似让用户随时用着爽，但实际上根本爽不起来。
2. 对同步池中的数据进行过滤
1）只取时间戳最新的执行
根据唯一键，对重复提交进来的数据进行去重。
比如手动点击同步，系统又自动增量同步，那么这两次请求只取最后这次的。
2）对比上次同步成功的数值，和本次提交的同步数值
如果数值没变化，那么同步过去也是无意义的，可以直接跳过这条任务。
比如上次已经同步过，且成功了，那么这次就算手动触发了同步，一旦对比到当前的价格和上次同步的价格是相同的，那就没必要再次同步了。
3. 增加补推机制
在同步给平台失败的场景比较多。
若是数据本身不具备同步的条件，例如缺少默写必须信息。或者不满足平台的约束条件，比如平台无此数据。那么只能返回原因，告诉用户处理后再试。
若是上述两种条件都满足，但是平台因为限流，导致部分数据遗留下来的话，理论上持续补推的话，总会完结的。
但是，考虑到后面还有很多数据在等待，所以这里不能一直补推。
最终的方案就是间隔1s重新插入补推2次。
补推还不成功的，就停止补推，并汇报原因，便用户自己再手动同步。
4. 将同步池去掉，改为缓存池
同步池其实是一张数据表。数据量攀升很快，需定期清理，也比较耗费时间。每次执行同步都调用池中数据，也耗性能。
现在改为从缓存中直接执行，动态线程。好处就是提升处理速度。
5. 增加同步状态的展示和同步日志
在页面对数据展示状态：正常、失败、异常
点击状态，展示同步日志。方便用户自行发现异常。
06 总结
1. 本次优化针对的是第三方数据同步的问题
问题的根源在于数据量大，且三方平台限流。
解决方案要点：
- 减少来源，重点是前端的操作入口分离，并限制操作频率。
- 对待处理数据进行清洗，去重、对比、改变存储方式等。
- 增加失败补偿机制和日志。
2. 解决思路模型
开源节流的思路：敲定场景、控制入口，清洗数据，处理并发，并输出结果。
- 敲定场景：场景是无法无视的，场景确定，是做正确事的前提。当确定必须解决这个问题的时候，就可以静下心找方案。
- 控制入口：因为数据量大，所以先从来源上做增益。
- 清洗数据：同样是为了摆脱无效数据，尽可能降低冗余。
- 处理并发：通过对比、时间戳等，滤掉无效数据。
- 生成日志：让用户有迹可循，自行追溯。
3. 这类问题初期很难预测
调研需求的时候，很难估计到数据的真实生态，以及第三方接口的各种限制。
因此只能在生产中发现和敲定问题。
4. 产品经理需了解技术机制
这类问题属于性能问题，本质属于开发主导的范畴，但产品经理需了解这些机制。才能初期有所防备，后期及时处理。
#作者#
唧唧歪歪PM，公众号：唧唧歪歪PM（ID：jjyypm），2019年年度作者。《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交APP。
本文
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
