内部一致性与外部一致性的区分决定了从编程问题到架构问题的转变

事务的目的是保证数据一致性，但”一致性”在单数据源和多数据源场景下的实现 难度天差地别。当一个服务只用一个数据源时，并发事务的读写冲突和最终执行 顺序都由这一个数据源自己感知和裁决，靠原子性/隔离性/持久性（A/I/D）就能 获得一致性，这被称为”内部一致性”，是相对容易的经典做法。一旦一个服务用到 多个数据源，甚至多个服务同时涉及多个数据源，情况就变得棘手——此时事务的 执行顺序不再由任何单一数据源决定，这类跨数据源的一致性被称为”外部一致性”， 用A/I/D几乎无法解决，或者代价大到不现实。这个区分带来一个关键的观念转变： 一致性不再是”是或否”的二元判断，而要被拆成可以按不同强度分开讨论的多元 属性，在代价可承受的前提下追求尽可能高的一致性保障——这正是事务处理从 一个具体的”编程问题”（调API开关事务）升级为需要全局权衡的”架构问题”（选 哪种一致性策略）的分水岭。