| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -1,6 +1,6 @@ | |||
| 1 | 1 | 张三丰教我的分布式太极拳,我全忘了 | |
| 2 | 2 | ||
| 3 | - > 背景:元朝赵敏郡主携带一帮高手围攻武当,武当派掌门张三丰被暗算,传了一套武功给张无忌用来对付赵敏。这套武功就是太极拳。 | ||
| 3 | + > 背景:元朝赵敏郡主携带一帮高手围攻武当,武当派掌门张三丰被暗算,传了一套武功给张无忌用来对付赵敏的手下。这套武功就是太极拳。 | ||
| 4 | 4 | > | |
| 5 | 5 | > 张三丰:无忌,你可记得多少招式? | |
| 6 | 6 | > | |
@@ -58,9 +58,32 @@ CAP 理论是对分布式系统的特性做了一个高度的抽象,变成了 | |||
| 58 | 58 | ||
| 59 | 59 | - 两个节点都更新成功后,客户端访问其中任意一个节点获取到的都是 A = 5。这个就叫做一致性。 | |
| 60 | 60 | ||
| 61 | -  | ||
| 61 | +  | ||
| 62 | 62 | ||
| 63 | - 一致性强调的是数据正确,每次读取节点中的数据都是最新写入的数据。但是 | ||
| 63 | + `一致性`强调的是数据正确,每次读取节点中的数据都是最新写入的数据。这个我称作`刚`。 | ||
| 64 | + | ||
| 65 | + 但是我们生产的集群环境下如果发生分区故障时(节点失联,节点无法响应,节点无法写入数据),客户端查询节点时,我们不能返回错误信息给客户端。比如说业务集群中的一些关键系统,如注册中心,不能因为某个节点失联了,就不响应最新的数据。那么相关的业务也获取不到正确的注册信息而导致系统瘫痪。 | ||
| 66 | + | ||
| 67 | + `可用性`就派上用场了,牺牲数据准确性,每个节点使用本地数据来响应客户端的请求。另外当节点不可用时,可以使用快速失败策略,至少不能让服务长时间不能响应可用性强调的是服务可用,不保证数据正确。这个我称作`柔`。 | ||
| 68 | + | ||
| 69 | + 如下图所示:节点 1 和节点 2 返回给客户端的值分别是 A = 5 和 A = 1,也就是节点 1 和 节点 2 并没有保证数据一致性,而是考虑了节点的可用性。 | ||
| 70 | + | ||
| 71 | + `分区容错性`的含义就是节点间出现任意数量的消息丢失或高延迟的时候,系统仍然在继续工作。分布式系统告诉客户端,我的内部不论出现什么样的数据同步问题,我会一直运行。强调的是集群堆分区故障的容错能力。 | ||
| 72 | + | ||
| 73 | +  | ||
| 74 | + | ||
| 75 | + | ||
| 76 | + | ||
| 77 | + ### CAP 三角 | ||
| 78 | + | ||
| 79 | + 那么这三个指标又有什么关系呢?这个就是我们经常听到的 `CAP` 理论。C 代表一致性(Consistency),A 代表可用性(Availability)、P 代表分区容错性(Partition Tolerance)。 | ||
| 80 | + | ||
| 81 | + 对于分布式系统,CAP 三个指标只能选择其中两个。 | ||
| 82 | + | ||
| 83 | + - CA:保证一致性和可用性。当分布式系统正常运行时(大部分时候所处的状态),这个时候不需要 P,那么 C 和 A 能够同时保证。只有在发生分区故障时,才需要 P,这个时候就只能在 C 和 A 之间做出选择。 | ||
| 84 | + | ||
| 85 | + - CP:保证数据的一致性和分区容错性,比如配置信息,必须保证每个节点存的都是最新的,正确的数据。 | ||
| 86 | + - AP:保证分布式系统的可用性和分区容错性。典型应用 | ||
| 64 | 87 | ||
| 65 | 88 | ## 刚柔并进 | |
| 66 | 89 | ||
| Back | FazBrowse Home | New Git URL |
0 commit comments