书店已经采用电子商务进行扩张但面临着可扩展性问题这可能会减慢它们的发展速度。他们需要能够跟踪其库存中的数千本图书（无论是在其主仓库还是在分支机构）但由于许多图书具有相同的标识符因此它们通常无法追踪。 ALEF 书店主页的屏幕截图。 一些背景 ALEF 书店使用的 ERP 系统托管着超过 34,000 种产品该系统构建在著名的Opentaps（开源 ERP 系统）之上。主要要求是使用 ERP 系统作为输入产品的单一界面因此商务网站必须同步这两个数据。 同步模型最初设计为每天同步四次所有数据以便产品数据在网站上与系统上显示相同。ERP 配置为以 XML 文件形式导出自上次导出以来所有更新的产品数据。最初它包含所有产品。 和 该网站是使用 和创建的。同步部分最初是作为 WordPress 插件创建的它解析 XML 并使用 WordPress 功能插入产品并更新其数据。插入的产品有类别、标签、价格、描述、照片、重量和尺寸以及其他自定义属性例如书籍作者等。 对于 功能我们使用函数能够在插入的产品上应用产品的功能例如设置库存。
同步插件最初是为了处理所有多个产
品而编写的最初花了 18 个小时。 提高持续时间并解决记忆问题 通过关闭术语计数该持续时间减少到三分之一。这是在开始将产品插入数据库（对于新产品）并随后将其打开之前使用函数完成的。完成后 多个所有详细信息的同步花了六个小时。 提出了一个问题。当我们同时处理 个 伊朗手机号码列表 产品时服务器有时会出现内存不足的情况。因此被分成更小的 （每个 100 个产品）。这稍微解决了内存问题。 然而六个小时并不是可接受的时间。我们必须优化同步本身的逻辑。为了识别产品我们必须使用 系统和网站上常见的唯一标识符。我们使用 系统的 并将其作为元值保存在我们的数据库中。 该 用于检测我们的数据库中是否已存在该产品。对于网站的新产品我们将其插入并获取帖子 以供随后使用。对于现有产品我们直接获取其帖子 ID。这通常是使用查询执行的：这是一个非常繁重的查询需要立即执行无需对数据库本身进行任何修改。
我们必须对列建立索引以减少所花费的时间
此外所有插入和更新都是批量完成的（在使用任何插入和更新之前我们关闭 并提交每 个产品完成后再次打开） 通过这样做同步时间减半只需要三个小时——这对我们来说是可以接受的持续时间但我们没有进一步优化因为我们需要在代码中保留 和 的使用。 必须处理 多个产品同步案例以便在 系统上对所有产品（即使很少）进行批量更改。此场景每天仅运行一 邮寄线索 次以避免服务器超载并且因为产品数据（数量除外）不会频繁更改可以等到第二天再应用而不会给电子商务流程带来任何问题。 库存数量 不断更新的一项属性是库存数量。书店的所有分店均使用 系统当发生线下销售时中的库存会发生变化。这需要在网站上反映出来以避免任何产品的过度销售。 不幸的是我们无法从 系统获取仅包含更新属性的导出 。如果产品自上次同步以来已更新我们将获得该产品的所有详细信息。因此必须创建另一个同步场景来更新数量。 首先我们从 系统导出 并使用 功能为每种产品设置其库存。
