SaaS系统接口同步三方平台的优化方案

SaaS系统对第三方平台同步,因限流等原因导致的同步丢失问题解决方案。后端产品体系的旧功能出了问题,只能在技术协助下,慢慢摸索追溯旧逻辑,搞清楚才能谈得上优化。本文以一个SaaS模式的“后台发货系统”为例,分析它是如何做到库存同步到销售渠道的,希望对你有帮助。

SaaS系统接口同步三方平台的优化方案

本文主角是一个SaaS模式的“后台发货系统”,对接美团等O2O平台的订单。目的是将各销售渠道的订单统一管理,完成发货。

既然统一发货,就少不了做统一的库存同步到销售渠道的机制。这样才能确保各平台数据互通,良性运营。

本次案例就来自库存价格同步机制这块的优化。

01 产品模型

整个业务模型大概是这样的:

SaaS系统接口同步三方平台的优化方案

该图表自下往上,分别是:

  • 最下是“商户WMS”:作为真实的门店和门店商品库存、价格的来源。(因为是O2O,所以库存就来自实体门店)。
  • 图中间是SaaS系统的“商户商品后台”:生成平台+线上门店+商品维度的数据清单,以衔接下端WMS和上端平台后台的数据。
  • 最上面是O2O平台的后台:各渠道后台通过统一接口,统一在发货系统中对接,节约成本,数据互通。

需注意的是:由于是O2O,同一商品,在不同平台的不同门店,价格可能不同。所以若有n个实体店,m个商品的话,那么在每个平台,商户最多就要维护n*m条数据。

若w个销售渠道(平台),那么最多就要维护n*m*w条数据。这个客观现实就为本次事件埋下伏笔。

02 核心功能:同步库存、价格给第三方平台

功能基于模型,所以正向功能就是:库存价格变化,则同步到对应的各个平台。

触发条件除了WMS增量自动同步之外,还需要手动触发同步的机制。

比如,美团打折活动结束,就要触发同步WMS的价格进行恢复。若此时不具有触发增量的条件,就需要手动触发。

于是增加了批量、单个<同步到平台>的功能。

至此,触发同步的条件就确定了:单个同步、批量同步、增量自动同步。

功能流程如下图:

SaaS系统接口同步三方平台的优化方案

03 技术实现机制

总体机制:不同平台的商品,从WMS搜集待同步的数据,然后集中后发车完成同步。

第一期的方案是采用“同步池”,汇集所有的同步请求。即:将来自于WMS的定时增量推送、页面批量操作、单个操作的同步请求数据,集中在同步池中。

再按照各自的去向,寻找对应的平台接口,此时需服从各平台的限流规则。

限流规则:就是平台限制接口被请求的次数。比如美团限制每天只支持10万次的同步请求。

整理后的技术实现流程图:

SaaS系统接口同步三方平台的优化方案

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. 本次优化针对的是第三方数据同步的问题

问题的根源在于数据量大,且三方平台限流。

解决方案要点:

  1. 减少来源,重点是前端的操作入口分离,并限制操作频率。
  2. 对待处理数据进行清洗,去重、对比、改变存储方式等。
  3. 增加失败补偿机制和日志。

2. 解决思路模型

开源节流的思路:敲定场景、控制入口,清洗数据,处理并发,并输出结果。

  • 敲定场景:场景是无法无视的,场景确定,是做正确事的前提。当确定必须解决这个问题的时候,就可以静下心找方案。
  • 控制入口:因为数据量大,所以先从来源上做增益。
  • 清洗数据:同样是为了摆脱无效数据,尽可能降低冗余。
  • 处理并发:通过对比、时间戳等,滤掉无效数据。
  • 生成日志:让用户有迹可循,自行追溯。

3. 这类问题初期很难预测

调研需求的时候,很难估计到数据的真实生态,以及第三方接口的各种限制。

因此只能在生产中发现和敲定问题。

4. 产品经理需了解技术机制

这类问题属于性能问题,本质属于开发主导的范畴,但产品经理需了解这些机制。才能初期有所防备,后期及时处理。

本文由 新媒体之家 作者: 唧唧歪歪PM 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
1

发表评论