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

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. 增加补推机制 在同步给平台失败的场景比较多。 若是数据本身不具备同步的条件，例如缺少默写必须信息。或者不满足平台的约束条件，比如平台无此数据。那么只能返回原因，告诉用户处理后再试。 若是上述两种条件都满足，