我们有大量的产品数据，分为几个MYSQL服务器。每个服务器包含每个类别的产品详细信息（让我们称这些类别DB），然后有一个服务器包含所有产品的高级元数据（让我们称之为全局数据库）。 UI节点位于不同的节点中。
类别DB中包含的信息更详细，就像与产品相关的所有信息一样。全局服务器中包含的信息是这些产品的非常高级别的信息，例如价格，标题和类别。此高级别信息也存在于类别DB中。
注意：我愿意使用任何类型的技术来保存这种高级全局数据，无论是NOSQL还是关系数据库。
前：
全球表：
类别数据库表将包含更多条目，如描述，位置，城市等，以及全局表中的条目。
因此，全局数据库中的数据已经存在于城市数据库中，需要将其保留在那里，以便在一个查询中搜索来自不同类别的产品时提供参考。可以将此全局DB视为DB类别中某些字段的缓存。
如果我对产品的价格进行更改，我应该更改类别和全局数据库。这是交易开始引起问题的地方。我不是XA交易的粉丝，听说过它有很多陷阱，而且很慢。
现在我很确定有很多人遇到与此问题非常类似的问题，其中涉及缓存。更新可能在类别DB中成功，但在更新缓存时失败。那些人如何管理这种情况，以及他们的已知问题是什么？此外，UI节点可能会继续上下，因此在UI节点本身上保留此类信息的状态可能会导致一些问题，因此我猜消息队列可用于存储一些状态数据，最终到达缓存，但我不确定这是否可行。
我对任何类型的解决方法持开放态度，这至少最终会使缓存+数据库达到一致状态。请建议。
我无法从类别DB中存在的条目中删除全局数据库中的条目。因此，更新类别DB时无效的全局数据库条目是不可接受的。参赛作品必须始终在那里。可能会用一些脏标法吗？
Global DB中的条目可以有一个脏标志，只要在类别DB级别进行更新，就可以设置该标志。但是，现在的问题是插入，即当条目可能不会插入这两个DB中的一个时。我建议我们可以通过使用类别DB中的另一个表来解决这个问题，该表存储要做的事情的命令。因此，如果在类别DB中进行插入，则在此表中添加一行，其中的命令表示必须将条目设置为全局DB。某些进程必须继续轮询此表并执行这些命令。这样，整个事情都是事务性的，并且稍有延迟，插入问题也会消失。
它变得太复杂了吗？