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