在设计商业模式时，我应该考虑短期的不一致吗？

Question

删除架构元素后，架构更改过程为：public - ＆gt;只写 - ＆gt;仅删除 - ＆gt;重组 - ＆gt;缺席。

如果要删除的元素是table，则此过程仅对表的架构信息进行操作，并且不会影响数据。因此，数据是一致的。

然而，似乎从“公共”改为“只写”的过程不是原子的。在此过程中，您无法先在某些节点上查询此表，然后无法在所有节点上查询此表。同样，在将“只写”切换为“仅删除”的过程中，您无法将数据插入到节点的一部分，并且逐渐无法将数据插入到所有节点。两种情况都存在短暂的不一致。

如果是这种情况，在设计基于TiDB的业务模型时，是否应该考虑短暂的不一致性？

Answer 1

没有必要考虑不一致问题。

在群集中执行DDL时，某个时间点的不同TiDB节点之间最多有两个架构状态。因此，在从“公共”到“仅写入”的更改过程完成之前，集群中的某些节点仍然是公共的，有些节点已经是只写的。