fix typo

distributed-transaction/ACID.md

@@ -13,6 +13,6 @@
 
 这也就是常说的事务的“ACID 特性”。值得一提的是，**对于一致性而言，更多的是指数据在应用层的外部表现。应用程序借助数据库提供的原子性、隔离性和持久性，来实现一致性目标。也就是说，A、I、D 是手段，C 是 3 者协作的目标，弄到一块完全是为了读起来更顺口。**
 
-当事务仅涉及本地操作时，一致性通常可以通过代码实现起来水到渠成。但倘若事务的操作对象扩展到外部系统，例如跨越多个微服务、数据源甚至数据中心时，再依赖传统的 A、I、D 手段来解决一致性问题变得非常困难。但是，一致性又是在分布式系统中不可回避且必须解决的核心问题。这种情况下，我们就需要转变观念，将一致性视为一个多维度的问题，而非简单的“是或否”的二元问题。根据不同场景的需求，对一致性的强度进行分级，在确保代价可承受的前提下，尽可能保障系统的一致性。
+当事务仅涉及本地操作时，一致性通过代码实现起来水到渠成。但倘若事务的操作对象扩展到外部系统，例如跨越多个微服务、数据源甚至数据中心时，再依赖传统的 A、I、D 手段来解决一致性问题变得非常困难。但是，一致性又是在分布式系统中不可回避且必须解决的核心问题。这种情况下，我们就需要转变观念，将一致性视为一个多维度的问题，而非简单的“是或否”的二元问题。根据不同场景的需求，对一致性的强度进行分级，在确保代价可承受的前提下，尽可能保障系统的一致性。
 
 一致性的强弱程度直接影响系统设计权衡。由此，事务从一个具体操作层面的“编程问题”转变成一个需要全局视角的“架构问题”。在探索这些架构设计的过程中，出现了许多思路和理论，其中最著名的便是一致性与可用性之间的权衡 —— 即 CAP 定理。