编辑导读：不同部门、不同系统间要想做到信息共享就要建立同步机制，这样才能确保数据互通，良性运营。本文以一个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. 本次优化针对的是第三方数据同步的问题

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

解决方案要点：

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

2. 解决思路模型

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

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

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

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

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

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

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

#专栏作家#

唧唧歪歪PM，公众号：唧唧歪歪PM（ID：jjyypm），人人都是产品经理专栏作家，2019年年度作者。《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交APP。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议