我有一个基于MySQL数据库的商店系统,我可以完全控制它。在这个系统上运行我的同步插件。然后是一个具有固定API的外部CRM系统。此API允许对客户进行读写。阅读时,我可以指定一个UTC时间戳,它将为我提供所有自该时间戳以来已更改的客户。
现在可能是客户自己在商店里改变自己的数据,也可能是CRM系统中的工作人员在客户联系时支持的。我知道双向同步会带来一些问题,所以我希望保持简单,并使用更新的记录(假设服务器的时间是合理同步的)。
例如,我的同步进程每30分钟运行一次。它首先确定自上次同步以来该商店的所有更改的本地客户,并通过API确定所有更改的CRM客户。然后比较客户是否出现在这两个数据包中。如果是这样,则使用较新的数据记录。如果没有,则首先将记录放入队列中,以便在本地或CRM系统中更新/插入。
我现在唯一的问题是同步过程的结束。现在为同步的下一次调用保存哪个时间戳。如果使用当前时间戳,则有可能在来自客户或CRM用户的同步数据期间进行更新,然后再也不会同步这些数据。因此,我只能保存客户配置文件(本地或CRM)上一次更新的时间戳。但是,在下一次运行时,我将再次显示所有由同步本身更改的客户配置文件,并将产生一个update循环。
不幸的是,在同步期间无法锁定CRM。我也不能在CRM-系统中比较两个日期字段(选择.其中updated_timestamp > last_sync_timestamp)。我可以将每个CRM记录的修改时间戳(在上一次同步期间)本地存储在商店数据库中,并将其与之进行比较,或者我是否遗漏了什么?
你们怎么解决这个问题?
发布于 2021-03-28 10:59:48
如果CRM系统不提供安全并发更新机制,则无法安全地进行并发更新。句号。
尽管如此,你的选择基本上是决定一个单一的真实来源,或双向同步与非常短的窗口,不同的数据在这两个系统。
在你的案例中,唯一的真相来源就是商店系统。工作人员需要在该系统中发挥专门作用,以更新客户数据,并需要意识到客户关系管理系统中对客户数据所做的任何更改都可能被改写。
如果您决定系统应该双向同步,您可能仍然会发现,某些数据字段通常由客户更改,而其他数据字段(如信用等级)只能由工作人员更改。这可能有助于减少冲突的风险,因为每个数据字段都有一个单一的真相来源。另一种策略可能是在一个严格的读-修改-更新操作中更新CRM数据,该操作可以检测正在更新的数据在编辑操作的开始和提交之间是否发生了变化,因此它避免了同时更改的数据。如果您在商店数据库中保存CRM客户记录的镜像副本,并将其用作合并决策的基础,那么合并独立的更改可能是最简单的。如果客户关系管理记录和商店记录在上次同步之后都发生了变化,那么就需要一些合并策略。在这里,您可以通过触发商店数据库编辑操作的同步来减少冲突发生的可能性,从而减少可能出现合并冲突的时间窗口。
https://softwareengineering.stackexchange.com/questions/424863
复制相似问题