From d14744c08879e78387cab1170cad271e53a0c41c Mon Sep 17 00:00:00 2001 From: guide Date: Tue, 24 Nov 2020 22:14:57 +0800 Subject: [PATCH 1/5] =?UTF-8?q?CAP=20=E5=92=8C=20BASE=20=E7=90=86=E8=AE=BA?= =?UTF-8?q?=E9=87=8D=E6=9E=84?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../BASE\347\220\206\350\256\272.md" | 26 +++++++---- .../CAP\347\220\206\350\256\272.md" | 46 ++++++++++++++----- 2 files changed, 51 insertions(+), 21 deletions(-) diff --git "a/docs/system-design/high-availability/BASE\347\220\206\350\256\272.md" "b/docs/system-design/high-availability/BASE\347\220\206\350\256\272.md" index 770ffd62a90..61bc81c717c 100644 --- "a/docs/system-design/high-availability/BASE\347\220\206\350\256\272.md" +++ "b/docs/system-design/high-availability/BASE\347\220\206\350\256\272.md" @@ -1,10 +1,16 @@ -## 简介 +## BASE 理论 + +[BASE 理论](https://dl.acm.org/doi/10.1145/1394127.1394128)起源于 2008 年， 由eBay的架构师Dan Pritchett在ACM上发表。 + +### 简介 **BASE** 是 **Basically Available（基本可用）** 、**Soft-state（软状态）** 和 **Eventually Consistent（最终一致性）** 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。 -## BASE 理论的核心思想 +### BASE 理论的核心思想 + +即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。 -即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。 +> 也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。 **BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。** @@ -16,11 +22,11 @@ CAP 理论这节我们也说过了： 因此，AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。 -## BASE 理论三要素 +### BASE 理论三要素 ![BASE理论三要素](https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAxOC81LzI0LzE2MzkxNDgwNmQ5ZTE1YzY?x-oss-process=image/format,png) -### 1. 基本可用 +#### 1. 基本可用 基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。 @@ -29,22 +35,24 @@ CAP 理论这节我们也说过了： - **响应时间上的损失**: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。 - **系统功能上的损失**：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。 -### 2. 软状态 +#### 2. 软状态 软状态指允许系统中的数据存在中间状态（**CAP 理论中的数据不一致**），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。 -### 3. 最终一致性 +#### 3. 最终一致性 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。 > 分布式一致性的 3 种级别： > > 1. **强一致性** ：系统写入了什么，读出来的就是什么。 +> > 2. **弱一致性** ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。 +> > 3. **最终一致性** ：弱一致性的升级版。，系统会保证在一定时间内达到数据一致的状态， > -> 业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。 +> **业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。** -## 总结 +### 总结 **ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。** \ No newline at end of file diff --git "a/docs/system-design/high-availability/CAP\347\220\206\350\256\272.md" "b/docs/system-design/high-availability/CAP\347\220\206\350\256\272.md" index 0b9df28e474..045581b916a 100644 --- "a/docs/system-design/high-availability/CAP\347\220\206\350\256\272.md" +++ "b/docs/system-design/high-availability/CAP\347\220\206\350\256\272.md" @@ -1,26 +1,44 @@ -![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-11/cap.png) +经历过技术面试的小伙伴想必对这个两个概念已经再熟悉不过了！ + +Guide哥当年参加面试的时候，不夸张地说，只要问到分布式相关的内容，面试官几乎是必定会问这两个分布式相关的理论。 + +并且，这两个理论也可以说是小伙伴们学习分布式相关内容的基础了！ + +因此，小伙伴们非常非常有必要将这理论搞懂，并且能够用自己的理解给别人讲出来。 + +这篇文章我会站在自己的角度对这两个概念进行解读！ + +*个人能力有限。如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！——爱你们的Guide哥* + +## CAP理论 + +[CAP 理论/定理](https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86)起源于 2000年，由加州大学伯克利分校的Eric Brewer教授在分布式计算原理研讨会（PODC）上提出，因此 CAP定理又被称作 **布鲁尔定理（Brewer’s theorem）** -## 简介 +2年后，麻省理工学院的Seth Gilbert和Nancy Lynch 发表了布鲁尔猜想的证明，CAP理论正式成为分布式领域的定理。 + +### 简介 **CAP** 也就是 **Consistency（一致性）**、**Availability（可用性）**、**Partition Tolerance（分区容错性）** 这三个单词首字母组合。 -CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细定义 Consistency、Availability、Partition Tolerance 三个单词的明确定义。 +![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-11/cap.png) + +CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候，并没有详细定义 **Consistency**、**Availability**、**Partition Tolerance** 三个单词的明确定义。 因此，对于 CAP 的民间解读有很多，一般比较被大家推荐的是下面 👇 这种版本的解。 -在理论计算机科学中，CAP 定理（CAP theorem），又被称作 **布鲁尔定理（Brewer’s theorem）**，它指出对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个： +在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个： - **一致性（Consistence）** : 所有节点访问同一份最新的数据副本 -- **可用性（Availability）**: 非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。 +- **可用性（Availability）**: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。 - **分区容错性（Partition tolerance）** : 分布式系统出现网络分区的时候，仍然能够对外提供服务。 -CAP 仅适用于原子读写的 NOSQL 场景中，并不适合数据库系统。现在的分布式系统具有更多特性比如扩展性、可用性等等，在进行系统设计和开发时，我们不应该仅仅局限在 CAP 问题上。 - **什么是网络分区？** > 分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区。 -## 不是所谓的“3 选 2” +![partition-tolerance](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/2020-11/partition-tolerance.png) + +### 不是所谓的“3 选 2” 大部分人解释这一定律时，常常简单的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个非常具有误导性质的说法，而且在 CAP 理论诞生 12 年之后，CAP 之父也在 2012 年重写了之前的论文。 @@ -36,7 +54,7 @@ CAP 仅适用于原子读写的 NOSQL 场景中，并不适合数据库系统。 **选择的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证 CP 。** -## CAP 实际应用案例 +### CAP 实际应用案例 我这里以注册中心来探讨一下 CAP 的实际应用。考虑到很多小伙伴不知道注册中心是干嘛的，这里简单以 Dubbo 为例说一说。 @@ -52,13 +70,17 @@ CAP 仅适用于原子读写的 NOSQL 场景中，并不适合数据库系统。 2. **Eureka 保证的则是 AP。** Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。 Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。 3. **Nacos 不仅支持 CP 也支持 AP。** -## 总结 +### 总结 + +在进行分布式系统设计和开发时，我们不应该仅仅局限在 CAP 问题上，还要关注系统的扩展性、可用性等等 在系统发生“分区”的情况下，CAP 理论只能满足 CP 或者 AP。要注意的是，这里的前提是系统发生了“分区” -如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。因此，**如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。** +如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。 + +总结：**如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。** -## 推荐阅读 +### 推荐阅读 1. [CAP 定理简化](https://medium.com/@ravindraprasad/cap-theorem-simplified-28499a67eab4) （英文，有趣的案例） 2. [神一样的 CAP 理论被应用在何方](https://juejin.im/post/6844903936718012430) （中文，列举了很多实际的例子） From 847482736db1dca622842f3478096e30d99140ef Mon Sep 17 00:00:00 2001 From: guide Date: Tue, 24 Nov 2020 22:39:09 +0800 Subject: [PATCH 2/5] =?UTF-8?q?=E5=88=86=E5=B8=83=E5=BC=8F=E9=83=A8?= =?UTF-8?q?=E5=88=86=E5=86=85=E5=AE=B9=E6=9B=B4=E6=96=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 37 +++++++++++------- .../BASE\347\220\206\350\256\272.md" | 0 .../CAP\347\220\206\350\256\272.md" | 0 .../\345\210\206\345\270\203\345\274\217.md" | 39 ------------------- 4 files changed, 22 insertions(+), 54 deletions(-) rename "docs/system-design/high-availability/BASE\347\220\206\350\256\272.md" => "docs/system-design/distributed-system/BASE\347\220\206\350\256\272.md" (100%) rename "docs/system-design/high-availability/CAP\347\220\206\350\256\272.md" => "docs/system-design/distributed-system/CAP\347\220\206\350\256\272.md" (100%) delete mode 100644 "docs/system-design/distributed-system/\345\210\206\345\270\203\345\274\217.md" diff --git a/README.md b/README.md index 21e6fcc1738..745bb42c239 100644 --- a/README.md +++ b/README.md @@ -70,6 +70,9 @@ - [JWT](#jwt) - [SSO(单点登录)](#sso单点登录) - [分布式](#分布式) + - [CAP 理论](#cap-理论) + - [BASE 理论](#base-理论) + - [Paxos 算法和 Raft 算法](#paxos-算法和-raft-算法) - [搜索引擎](#搜索引擎) - [RPC](#rpc) - [API 网关](#api-网关) @@ -82,8 +85,6 @@ - [分库分表](#分库分表) - [负载均衡](#负载均衡) - [高可用](#高可用) - - [CAP 理论](#cap-理论) - - [BASE 理论](#base-理论) - [限流](#限流) - [降级](#降级) - [熔断](#熔断) @@ -263,7 +264,21 @@ ### 分布式 -[分布式相关概念入门](docs/system-design/distributed-system/分布式.md) +#### CAP 理论 + +CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。 + +关于 CAP 的详细解读请看：[《CAP理论解读》](docs/system-design/distributed-system/CAP理论.md)。 + +#### BASE 理论 + +**BASE** 是 **Basically Available（基本可用）** 、**Soft-state（软状态）** 和 **Eventually Consistent（最终一致性）** 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。 + +关于 CAP 的详细解读请看：[《BASE理论解读》](docs/system-design/distributed-system/BASE理论.md)。 + +#### Paxos 算法和 Raft 算法 + +**Paxos 算法** 诞生于 1900 年，是一种解决分布式系统一致性的经典算法 。但是，由于 Paxos 算法非常难以理解和实现，不断有人尝试简化这一算法。到了2013年才诞生了一个比 Paxos 算法更易理解和实现的分布式一致性算法—**Raft 算法**。 #### 搜索引擎 @@ -287,6 +302,10 @@ RPC 让调用远程服务调用像调用本地方法那样简单。 在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。比如数据量太大之后，往往需要对进行对数据进行分库分表，分库分表后需要有一个唯一 ID 来标识一条数据或消息，数据库的自增 ID 显然不能满足需求。相关阅读：[为什么要分布式 id ？分布式 id 生成方案有哪些？](docs/system-design/micro-service/分布式id生成方案总结.md) +#### 分布式事务 + +分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 + #### ZooKeeper > 前两篇文章可能有内容重合部分，推荐都看一遍。 @@ -338,18 +357,6 @@ RPC 让调用远程服务调用像调用本地方法那样简单。 相关阅读： **《[如何设计一个高可用系统？要考虑哪些地方？](docs/system-design/high-availability/如何设计一个高可用系统要考虑哪些地方.md)》** 。 -#### CAP 理论 - -CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。 - -关于 CAP 的详细解读请看：[《CAP理论解读》](docs/system-design/high-availability/CAP理论.md)。 - -#### BASE 理论 - -**BASE** 是 **Basically Available（基本可用）** 、**Soft-state（软状态）** 和 **Eventually Consistent（最终一致性）** 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。 - -关于 CAP 的详细解读请看：[《BASE理论解读》](docs/system-design/high-availability/BASE理论.md)。 - #### 限流 限流是从用户访问压力的角度来考虑如何应对系统故障。 diff --git "a/docs/system-design/high-availability/BASE\347\220\206\350\256\272.md" "b/docs/system-design/distributed-system/BASE\347\220\206\350\256\272.md" similarity index 100% rename from "docs/system-design/high-availability/BASE\347\220\206\350\256\272.md" rename to "docs/system-design/distributed-system/BASE\347\220\206\350\256\272.md" diff --git "a/docs/system-design/high-availability/CAP\347\220\206\350\256\272.md" "b/docs/system-design/distributed-system/CAP\347\220\206\350\256\272.md" similarity index 100% rename from "docs/system-design/high-availability/CAP\347\220\206\350\256\272.md" rename to "docs/system-design/distributed-system/CAP\347\220\206\350\256\272.md" diff --git "a/docs/system-design/distributed-system/\345\210\206\345\270\203\345\274\217.md" "b/docs/system-design/distributed-system/\345\210\206\345\270\203\345\274\217.md" deleted file mode 100644 index 52a9d9f6665..00000000000 --- "a/docs/system-design/distributed-system/\345\210\206\345\270\203\345\274\217.md" +++ /dev/null @@ -1,39 +0,0 @@ -### 一　分布式系统的经典基础理论 - -[分布式系统的经典基础理论](https://blog.csdn.net/qq_34337272/article/details/80444032) -本文主要是简单的介绍了三个常见的概念： **分布式系统设计理念** 、 **CAP定理** 、 **BASE理论** ，关于分布式系统的还有很多很多东西。 - -![分布式系统的经典基础理论总结](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/1639234237ec9805.png) - -### 二　分布式事务 - -分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 -- [深入理解分布式事务](http://www.codeceo.com/article/distributed-transaction.html) -- [聊聊分布式事务，再说说解决方案](https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html) - - -### 三　分布式系统一致性 - -[分布式服务化系统一致性的“最佳实干”](https://www.jianshu.com/p/1156151e20c8) - -### 四　一致性协议/算法 - -早在1900年就诞生了著名的 **Paxos经典算法** （**Zookeeper就采用了Paxos算法的近亲兄弟Zab算法**），但由于Paxos算法非常难以理解、实现、排错。所以不断有人尝试简化这一算法，直到2013年才有了重大突破：斯坦福的Diego Ongaro、John Ousterhout以易懂性为目标设计了新的一致性算法—— **Raft算法** ，并发布了对应的论文《In Search of an Understandable Consensus Algorithm》，到现在有十多种语言实现的Raft算法框架，较为出名的有以Go语言实现的Etcd，它的功能类似于Zookeeper，但采用了更为主流的Rest接口。 - -* [图解 Paxos 一致性协议](https://mp.weixin.qq.com/s?__biz=MzI0NDI0MTgyOA==&mid=2652037784&idx=1&sn=d8c4f31a9cfb49ee91d05bb374e5cdd5&chksm=f2868653c5f10f45fc4a64d15a5f4163c3e66c00ed2ad334fa93edb46671f42db6752001f6c0#rd) -* [图解分布式协议-RAFT](http://ifeve.com/raft/) -* [Zookeeper ZAB 协议分析](https://dbaplus.cn/news-141-1875-1.html) - -### 五　分布式存储 - -**分布式存储系统将数据分散存储在多台独立的设备上**。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。 - -* [分布式存储系统概要](http://witchiman.top/2017/05/05/distributed-system/) - -### 六　分布式计算 - -**所谓分布式计算是一门计算机科学，它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给许多计算机进行处理，最后把这些计算结果综合起来得到最终的结果。** -分布式网络存储技术是将数据分散的存储于多台独立的机器设备上。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，不但解决了传统集中式存储系统中单存储服务器的瓶颈问题，还提高了系统的可靠性、可用性和扩展性。 - -* [关于分布式计算的一些概念](https://blog.csdn.net/qq_34337272/article/details/80549020) - From 1a439ffe65d58982179cc784c46b77f6dd2f58cc Mon Sep 17 00:00:00 2001 From: guide Date: Tue, 24 Nov 2020 22:40:57 +0800 Subject: [PATCH 3/5] =?UTF-8?q?[docs]=E6=89=8B=E5=86=99=20RPC=20=E6=A1=86?= =?UTF-8?q?=E6=9E=B6?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 745bb42c239..f6e973556de 100644 --- a/README.md +++ b/README.md @@ -290,6 +290,7 @@ RPC 让调用远程服务调用像调用本地方法那样简单。 1. [Dubbo 总结：关于 Dubbo 的重要知识点](docs/system-design/distributed-system/rpc/关于Dubbo的重要知识点.md) 2. [服务之间的调用为啥不直接用 HTTP 而用 RPC？](docs/system-design/distributed-system/rpc/服务之间的调用为啥不直接用HTTP而用RPC.md) +3. [一款基于 Netty+Kyro+Zookeeper 实现的自定义 RPC 框架](https://github.com/Snailclimb/guide-rpc-framework) #### API 网关 From 01907b95a9786ffe45c18a3b23640c2fe4d26960 Mon Sep 17 00:00:00 2001 From: guide Date: Tue, 24 Nov 2020 22:49:35 +0800 Subject: [PATCH 4/5] Update README.md --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index f6e973556de..bc02e68a4fb 100644 --- a/README.md +++ b/README.md @@ -278,7 +278,7 @@ CAP 也就是 Consistency（一致性）、Availability（可用性）、Partiti #### Paxos 算法和 Raft 算法 -**Paxos 算法** 诞生于 1900 年，是一种解决分布式系统一致性的经典算法 。但是，由于 Paxos 算法非常难以理解和实现，不断有人尝试简化这一算法。到了2013年才诞生了一个比 Paxos 算法更易理解和实现的分布式一致性算法—**Raft 算法**。 +**Paxos 算法**诞生于 1900 年，这是一种解决分布式系统一致性的经典算法 。但是，由于 Paxos 算法非常难以理解和实现，不断有人尝试简化这一算法。到了2013 年才诞生了一个比 Paxos 算法更易理解和实现的分布式一致性算法—**Raft 算法**。 #### 搜索引擎 @@ -305,7 +305,9 @@ RPC 让调用远程服务调用像调用本地方法那样简单。 #### 分布式事务 -分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 +**分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。** + +简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 #### ZooKeeper From 2bf7bcf940d628bbd47256abecf9cc4145a8bfbe Mon Sep 17 00:00:00 2001 From: guide Date: Tue, 24 Nov 2020 22:54:40 +0800 Subject: [PATCH 5/5] Update README.md --- README.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index bc02e68a4fb..40c4729d2e4 100644 --- a/README.md +++ b/README.md @@ -66,6 +66,7 @@ - [Spring/SpringBoot](#springspringboot) - [MyBatis](#mybatis) - [Netty (必看 :+1:)](#netty-必看-1) + - [ZooKeeper](#zookeeper) - [认证授权](#认证授权) - [JWT](#jwt) - [SSO(单点登录)](#sso单点登录) @@ -77,7 +78,6 @@ - [RPC](#rpc) - [API 网关](#api-网关) - [分布式 id](#分布式-id) - - [ZooKeeper](#zookeeper) - [微服务](#微服务) - [高并发](#高并发) - [消息队列](#消息队列) @@ -249,6 +249,14 @@ 1. [剖析面试最常见问题之 Netty（上）](https://xiaozhuanlan.com/topic/4028536971) 2. [剖析面试最常见问题之 Netty（下）](https://xiaozhuanlan.com/topic/3985146207) +#### ZooKeeper + +> 前两篇文章可能有内容重合部分，推荐都看一遍。 + +1. [【入门】ZooKeeper 相关概念总结](docs/system-design/distributed-system/zookeeper/zookeeper-intro.md) +2. [【进阶】ZooKeeper 相关概念总结](docs/system-design/distributed-system/zookeeper/zookeeper-plus.md) +3. [【实战】ZooKeeper 实战](docs/system-design/distributed-system/zookeeper/zookeeper-in-action.md) + ### 认证授权 **[《认证授权基础》](docs/system-design/authority-certification/basis-of-authority-certification.md)** 这篇文章中我会介绍认证授权常见概念： **Authentication**,**Authorization** 以及 **Cookie**、**Session**、Token、**OAuth 2**、**SSO** 。如果你不清楚这些概念的话，建议好好阅读一下这篇文章。 @@ -309,14 +317,6 @@ RPC 让调用远程服务调用像调用本地方法那样简单。 简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 -#### ZooKeeper - -> 前两篇文章可能有内容重合部分，推荐都看一遍。 - -1. [【入门】ZooKeeper 相关概念总结](docs/system-design/distributed-system/zookeeper/zookeeper-intro.md) -2. [【进阶】ZooKeeper 相关概念总结](docs/system-design/distributed-system/zookeeper/zookeeper-plus.md) -3. [【实战】ZooKeeper 实战](docs/system-design/distributed-system/zookeeper/zookeeper-in-action.md) - ### 微服务 1. [ 大白话入门 Spring Cloud](docs/system-design/micro-service/spring-cloud.md)