Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit 19319b2

Browse files
committed
modify distributed mds
1 parent d32b48d commit 19319b2

18 files changed

+177
-116
lines changed

‎ReadMe.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -317,7 +317,7 @@ todo
317317
* [分布式系统理论进阶:Paxos变种和优化 ](docs/distributed/basic/分布式系统理论进阶:Paxos变种和优化.md)
318318
* [分布式系统理论基础:zookeeper分布式协调服务 ](docs/distributed/basic/分布式系统理论基础:zookeeper分布式协调服务.md)
319319

320-
* [分布式技术实践总结](docs/distributed/分布式理论总结.md)
320+
* [分布式技术实践总结](docs/distributed/practice/分布式理论总结.md)
321321

322322
### 技术
323323
* [搞懂分布式技术:分布式系统的一些基本概念](docs/distributed/practice/搞懂分布式技术:分布式系统的一些基本概念.md )

‎docs/cs/operating-system/Linux内核与基础命令学习总结.md‎

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -309,7 +309,7 @@ linux使用inode来标识任意一个文件。inode存储除了文件名以外
309309

310310

311311

312-
<pre>#include <unistd> ssize_t write(int filedes, void *buf, size_t nbytes); // 返回:若成功则返回写入的字节数,若出错则返回-1 // filedes:文件描述符 // buf:待写入数据缓存区 // nbytes:要写入的字节数</pre>
312+
#include <unistd> ssize_t write(int filedes, void *buf, size_t nbytes); // 返回:若成功则返回写入的字节数,若出错则返回-1 // filedes:文件描述符 // buf:待写入数据缓存区 // nbytes:要写入的字节数目录
313313

314314

315315

@@ -321,7 +321,7 @@ linux使用inode来标识任意一个文件。inode存储除了文件名以外
321321

322322
![复制代码](http://common.cnblogs.com/images/copycode.gif)
323323

324-
<pre> 1 ssize_t /* Write "n" bytes to a descriptor. */
324+
1 ssize_t /* Write "n" bytes to a descriptor. */
325325
2 writen(int fd, const void *vptr, size_t n)
326326
3 {
327327
4 size_t nleft;
@@ -335,7 +335,7 @@ linux使用inode来标识任意一个文件。inode存储除了文件名以外
335335
18 nleft -= nwritten; 19 ptr += nwritten; 20 } 21 return(n); 22 } 23 /* end writen */
336336
24
337337
25 void
338-
26 Writen(int fd, void *ptr, size_t nbytes) 27 { 28 if (writen(fd, ptr, nbytes) != nbytes) 29 err_sys("writen error"); 30 }</pre>
338+
26 Writen(int fd, void *ptr, size_t nbytes) 27 { 28 if (writen(fd, ptr, nbytes) != nbytes) 29 err_sys("writen error"); 30 }目录
339339

340340
![复制代码](http://common.cnblogs.com/images/copycode.gif)
341341

@@ -349,7 +349,7 @@ linux使用inode来标识任意一个文件。inode存储除了文件名以外
349349

350350

351351

352-
<pre>#include <unistd> ssize_t read(int filedes, void *buf, size_t nbytes); // 返回:若成功则返回读到的字节数,若已到文件末尾则返回0,若出错则返回-1 // filedes:文件描述符 // buf:读取数据缓存区 // nbytes:要读取的字节数</pre>
352+
#include <unistd> ssize_t read(int filedes, void *buf, size_t nbytes); // 返回:若成功则返回读到的字节数,若已到文件末尾则返回0,若出错则返回-1 // filedes:文件描述符 // buf:读取数据缓存区 // nbytes:要读取的字节数目录
353353

354354

355355

@@ -375,7 +375,7 @@ linux使用inode来标识任意一个文件。inode存储除了文件名以外
375375

376376
![复制代码](http://common.cnblogs.com/images/copycode.gif)
377377

378-
<pre> 1 ssize_t /* Read "n" bytes from a descriptor. */
378+
1 ssize_t /* Read "n" bytes from a descriptor. */
379379
2 readn(int fd, void *vptr, size_t n)
380380
3 {
381381
4 size_t nleft;
@@ -390,7 +390,7 @@ linux使用inode来标识任意一个文件。inode存储除了文件名以外
390390
23 } 24 /* end readn */
391391
25
392392
26 ssize_t 27 Readn(int fd, void *ptr, size_t nbytes) 28 { 29 ssize_t n; 30
393-
31 if ( (n = readn(fd, ptr, nbytes)) < 0) 32 err_sys("readn error"); 33 return(n); 34 }</pre>
393+
31 if ( (n = readn(fd, ptr, nbytes)) < 0) 32 err_sys("readn error"); 33 return(n); 34 }目录
394394

395395
![复制代码](http://common.cnblogs.com/images/copycode.gif)
396396

@@ -406,7 +406,7 @@ linux使用inode来标识任意一个文件。inode存储除了文件名以外
406406

407407

408408

409-
<pre>#include <unistd.h> ssize_t write(int fd, const void *buf, size_t count);</pre>
409+
#include <unistd.h> ssize_t write(int fd, const void *buf, size_t count);目录
410410

411411

412412

@@ -416,10 +416,10 @@ linux使用inode来标识任意一个文件。inode存储除了文件名以外
416416

417417

418418

419-
<pre># 获取socket的发送/接受缓冲区的大小:(后面的值是在Linux 2.6.38 x86_64上测试的结果)</pre>
419+
# 获取socket的发送/接受缓冲区的大小:(后面的值是在Linux 2.6.38 x86_64上测试的结果)目录
420420

421-
<pre>sysctl net.core.wmem_default #126976
422-
sysctl net.core.wmem_max #131071</pre>
421+
sysctl net.core.wmem_default #126976
422+
sysctl net.core.wmem_max #131071目录
423423

424424

425425

‎docs/distributed/basic/分布式系统理论基础 :CAP.md‎

Lines changed: 19 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,14 @@
1+
# Table of Contents
2+
3+
* [**引言**](#引言)
4+
* [**CAP定理**](#cap定理)
5+
* [**CAP的工程启示**](#cap的工程启示)
6+
* [**1、关于 P 的理解**](#1、关于-p-的理解)
7+
* [**2、CA非0/1的选择**](#2、ca非01的选择)
8+
* [**3、跳出CAP**](#3、跳出cap)
9+
* [**小结**](#小结)
10+
11+
112
本文转自:https://www.cnblogs.com/bangerlee/p/5328888.html
213

314
本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到我的仓库里查看
@@ -17,11 +28,11 @@
1728
如果对本系列文章有什么建议,或者是有什么疑问的话,也可以关注公众号【Java技术江湖】联系作者,欢迎你参与本系列博文的创作和修订。
1829

1930
<!-- more -->
20-
**引言**
31+
## **引言**
2132

2233
CAP是分布式系统、特别是分布式存储领域中被讨论最多的理论,"[什么是CAP定理?](https://www.quora.com/What-Is-CAP-Theorem-1)"在Quora 分布式系统分类下排名 FAQ 的 No.1。CAP在程序员中也有较广的普及,它不仅仅是"C、A、P不能同时满足,最多只能3选2",以下尝试综合各方观点,从发展历史、工程实践等角度讲述CAP理论。希望大家透过本文对CAP理论有更多地了解和认识。
2334

24-
**CAP定理**
35+
## **CAP定理**
2536

2637
CAP由[Eric Brewer](https://en.wikipedia.org/wiki/Eric_Brewer_(scientist))在2000年PODC会议上提出<sup>[1][2]</sup>,是Eric Brewer在Inktomi<sup>[3]</sup>期间研发搜索引擎、分布式web缓存时得出的关于数据一致性(consistency)、服务可用性(availability)、分区容错性(partition-tolerance)的猜想:
2738

@@ -38,13 +49,13 @@ C、A、P三者最多只能满足其中两个,和FLP定理一样,CAP定理
3849

3950
![](https://java-tutorial.oss-cn-shanghai.aliyuncs.com/20230407204500.png)
4051

41-
**CAP的工程启示**
52+
## **CAP的工程启示**
4253

4354
CAP理论提出7、8年后,NoSql圈将CAP理论当作对抗传统关系型数据库的依据、阐明自己放宽对数据一致性(consistency)要求的正确性<sup>[6]</sup>,随后引起了大范围关于CAP理论的讨论。
4455

4556
CAP理论看似给我们出了一道3选2的选择题,但在工程实践中存在很多现实限制条件,需要我们做更多地考量与权衡,避免进入CAP认识误区<sup>[7]</sup>。
4657

47-
**1、关于 P 的理解**
58+
### **1、关于 P 的理解**
4859

4960
Partition字面意思是网络分区,即因网络因素将系统分隔为多个单独的部分,有人可能会说,网络分区的情况发生概率非常小啊,是不是不用考虑P,保证CA就好<sup>[8]</sup>。要理解P,我们看回CAP证明<sup>[4]</sup>中P的定义:
5061

@@ -56,7 +67,7 @@ Partition字面意思是网络分区,即因网络因素将系统分隔为多
5667

5768
> In a network subject to communication failures, it is impossible for any web service to implement an atomic read/write shared memory that guarantees a response to every request.
5869
59-
**2、CA非0/1的选择**
70+
### **2、CA非0/1的选择**
6071

6172
P 是必选项,那3选2的选择题不就变成数据一致性(consistency)、服务可用性(availability) 2选1?工程实践中一致性有不同程度,可用性也有不同等级,在保证分区容错性的前提下,放宽约束后可以兼顾一致性和可用性,两者不是非此即彼<sup>[12]</sup>。
6273

@@ -71,15 +82,15 @@ CAP定理证明中的一致性指强一致性,强一致性要求多节点组
7182

7283
工程实践中,较常见的做法是通过异步拷贝副本(asynchronous replication)、quorum/NRW,实现在调用端看来数据强一致、被调端最终一致,在调用端看来服务可用、被调端允许部分节点不可用(或被网络分隔)的效果<sup>[15]</sup>。
7384

74-
**3、跳出CAP**
85+
### **3、跳出CAP**
7586

7687
CAP理论对实现分布式系统具有指导意义,但CAP理论并没有涵盖分布式工程实践中的所有重要因素。
7788

7889
例如延时(latency),它是衡量系统可用性、与用户体验直接相关的一项重要指标<sup>[16]</sup>。CAP理论中的可用性要求操作能终止、不无休止地进行,除此之外,我们还关心到底需要多长时间能结束操作,这就是延时,它值得我们设计、实现分布式系统时单列出来考虑。
7990

8091
延时与数据一致性也是一对"冤家",如果要达到强一致性、多个副本数据一致,必然增加延时。加上延时的考量,我们得到一个CAP理论的修改版本PACELC<sup>[17]</sup>:如果出现P(网络分区),如何在A(服务可用性)、C(数据一致性)之间选择;否则,如何在L(延时)、C(数据一致性)之间选择。
8192

82-
**小结**
93+
### **小结**
8394

8495
以上介绍了CAP理论的源起和发展,介绍了CAP理论给分布式系统工程实践带来的启示。
8596

@@ -125,4 +136,4 @@ CAP理论对分布式系统实现有非常重大的影响,我们可以根据
125136

126137
[19] [How to beat the CAP theorem](http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html), nathanmarz , 2011
127138

128-
[20] [The CAP FAQ](https://github.com/henryr/cap-faq), Henry Robinson
139+
[20] [The CAP FAQ](https://github.com/henryr/cap-faq), Henry Robinson

‎docs/distributed/basic/分布式系统理论基础: 一致性、PC和PC.md‎

Lines changed: 16 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,12 @@
1+
# Table of Contents
2+
3+
* [**引言**](#引言)
4+
* [**一致性(consensus)**](#一致性consensus)
5+
* [**2PC**](#2pc)
6+
* [**3PC**](#3pc)
7+
* [**小结**](#小结)
8+
9+
110
本文转自 https://www.cnblogs.com/bangerlee/p/5268485.html
211

312
本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到我的仓库里查看
@@ -31,7 +40,7 @@
3140
3241
一致性是分布式理论中的根本性问题,近半个世纪以来,科学家们围绕着一致性问题提出了很多理论模型,依据这些理论模型,业界也出现了很多工程实践投影。下面我们从一致性问题、特定条件下解决一致性问题的两种方法(2PC、3PC)入门,了解最基础的分布式系统理论。
3342

34-
**一致性(consensus)**
43+
### **一致性(consensus)**
3544

3645
何为一致性问题?简单而言,一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中,进行数据库事务提交(commit transaction)、Leader选举、序列号生成等都会遇到一致性问题。这个问题在我们的日常生活中也很常见,比如牌友怎么商定几点在哪打几圈麻将:
3746

@@ -60,7 +69,7 @@ _《赌圣》,1990_
6069

6170

6271

63-
<pre>我: 老王,今晚7点老地方,搓够48圈不见不散!
72+
我: 老王,今晚7点老地方,搓够48圈不见不散!
6473
......
6574
(第二天凌晨3点) 隔壁老王: 没问题! // 消息延迟
6675
我: ......
@@ -71,7 +80,7 @@ _《赌圣》,1990_
7180
我: ......
7281
-----------------------------------------------
7382
我: 老李头,今晚7点老地方,搓够48圈不见不散!
74-
老李: 必须的,大保健走起! // 拜占庭将军 (这是要打麻将呢?还是要大保健?还是一边打麻将一边大保健......)</pre>
83+
老李: 必须的,大保健走起! // 拜占庭将军 (这是要打麻将呢?还是要大保健?还是一边打麻将一边大保健......)目录
7584

7685

7786

@@ -94,7 +103,7 @@ FLP定理是分布式系统理论中的基础理论,正如物理学中的能
94103
_《怦然心动 (Flipped)》,2010_
95104
工程实践上根据具体的业务场景,或保证强一致(safety),或在节点宕机、网络分化的时候保证可用(liveness)。2PC、3PC是相对简单的解决一致性问题的协议,下面我们就来了解2PC和3PC。
96105

97-
**2PC**
106+
### **2PC**
98107

99108
2PC(tow phase commit)两阶段提交<sup>[5]</sup>顾名思义它分成两个阶段,先由一方进行提议(propose)并收集其他节点的反馈(vote),再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator),其他参与决议节点称为参与者(participants, 或cohorts):
100109

@@ -116,7 +125,7 @@ coordinator如果在发起提议后宕机,那么participant将进入阻塞(blo
116125

117126
从coordinator接收到一次事务请求、发起提议到事务完成,经过2PC协议后增加了2次RTT(propose+commit),带来的时延(latency)增加相对较少。
118127

119-
**3PC**
128+
### **3PC**
120129

121130
3PC(three phase commit)即三阶段提交<sup>[6][7]</sup>,既然2PC可以在异步网络+节点宕机恢复的模型下实现一致性,那还需要3PC做什么,3PC是什么鬼?
122131

@@ -141,7 +150,7 @@ participant如果在不同阶段宕机,我们来看看3PC如何应对:
141150

142151
因为有了准备提交(prepare to commit)阶段,3PC的事务处理延时也增加了1个RTT,变为3个RTT(propose+precommit+commit),但是它防止participant宕机后整个系统进入阻塞态,增强了系统的可用性,对一些现实业务场景是非常值得的。
143152

144-
**小结**
153+
### **小结**
145154

146155
以上介绍了分布式系统理论中的部分基础知识,阐述了一致性(consensus)的定义和实现一致性所要面临的问题,最后讨论在异步网络(asynchronous)、节点宕机恢复(fail-recover)模型下2PC、3PC怎么解决一致性问题。
147156

@@ -159,4 +168,4 @@ participant如果在不同阶段宕机,我们来看看3PC如何应对:
159168

160169
[6][Consensus Protocols: Three-phase Commit](http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/),Henry Robinson, 2008
161170

162-
[7][Three-phase commit protocol](https://en.wikipedia.org/wiki/Three-phase_commit_protocol),Wikipedia
171+
[7][Three-phase commit protocol](https://en.wikipedia.org/wiki/Three-phase_commit_protocol),Wikipedia

‎docs/distributed/basic/分布式系统理论基础: 时间、时钟和事件顺序.md‎

Lines changed: 15 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,12 @@
1+
# Table of Contents
2+
3+
* [**物理时钟 vs 逻辑时钟**](#物理时钟-vs-逻辑时钟)
4+
* [**Lamport timestamps**](#lamport-timestamps)
5+
* [**Vector clock**](#vector-clock)
6+
* [**Version vector**](#version-vector)
7+
* [**小结**](#小结)
8+
9+
110
转自:https://www.cnblogs.com/bangerlee/p/5448766.html
211

312
本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到我的仓库里查看
@@ -21,15 +30,15 @@
2130
2231
现实生活中时间是很重要的概念,时间可以记录事情发生的时刻、比较事情发生的先后顺序。分布式系统的一些场景也需要记录和比较不同节点间事件发生的顺序,但不同于日常生活使用物理时钟记录时间,分布式系统使用逻辑时钟记录事件顺序关系,下面我们来看分布式系统中几种常见的逻辑时钟。
2332

24-
**物理时钟 vs 逻辑时钟**
33+
## **物理时钟 vs 逻辑时钟**
2534

2635
可能有人会问,为什么分布式系统不使用物理时钟(physical clock)记录事件?每个事件对应打上一个时间戳,当需要比较顺序的时候比较相应时间戳就好了。
2736

2837
这是因为现实生活中物理时间有统一的标准,而分布式系统中每个节点记录的时间并不一样,即使设置了[NTP](http://www.zhihu.com/question/24960940)时间同步节点间也存在毫秒级别的偏差<sup>[1][2]</sup>。因而分布式系统需要有另外的方法记录事件顺序关系,这就是逻辑时钟(logical clock)。
2938

3039
![](https://java-tutorial.oss-cn-shanghai.aliyuncs.com/116770-20160501132311347-349996615.jpg)
3140

32-
**Lamport timestamps**
41+
## **Lamport timestamps**
3342

3443
[Leslie](https://en.wikipedia.org/wiki/Leslie_Cheung)[Lamport](https://en.wikipedia.org/wiki/Leslie_Lamport)在1978年提出逻辑时钟的概念,并描述了一种逻辑时钟的表示方法,这个方法被称为Lamport时间戳(Lamport timestamps)<sup>[3]</sup>。
3544

@@ -50,7 +59,7 @@ _图1: Lamport timestamps space time (图片来源: wikipedia)_
5059

5160
通过以上定义,我们可以对所有事件排序、获得事件的[全序关系](https://en.wikipedia.org/wiki/Total_order)(total order)。上图例子,我们可以从C1到A4进行排序。
5261

53-
**Vector clock**
62+
## **Vector clock**
5463

5564
Lamport时间戳帮助我们得到事件顺序关系,但还有一种顺序关系不能用Lamport时间戳很好地表示出来,那就是同时发生关系(concurrent)<sup>[4]</sup>。例如图1中事件B4和事件C3没有因果关系,属于同时发生事件,但Lamport时间戳定义两者有先后顺序。
5665

@@ -64,7 +73,7 @@ _图2: Vector clock space time (_图片来源: wikipedia)__
6473

6574
如果T<sub>b</sub>[Q] > T<sub>a</sub>[Q] 并且 T<sub>b</sub>[P] < T<sub>a</sub>[P],则认为a、b同时发生,记作 a <-> b。例如图2中节点B上的第4个事件 (A:2,B:4,C:1) 与节点C上的第2个事件 (B:3,C:2) 没有因果关系、属于同时发生事件。
6675

67-
**Version vector**
76+
## **Version vector**
6877

6978
基于Vector clock我们可以获得任意两个事件的顺序关系,结果或为先后顺序或为同时发生,识别事件顺序在工程实践中有很重要的引申应用,最常见的应用是发现数据冲突(detect conflict)。
7079

@@ -85,7 +94,7 @@ Vector clock只用于发现数据冲突,不能解决数据冲突。如何解
8594

8695
解决该问题的方法是使用server id取代client id创建vector (因为server的数量相对client稳定),或设定最大的size、如果超过该size值则淘汰最旧的vector信息<sup>[10][13]</sup>。
8796

88-
**小结**
97+
## **小结**
8998

9099
以上介绍了分布式系统里逻辑时钟的表示方法,通过Lamport timestamps可以建立事件的全序关系,通过Vector clock可以比较任意两个事件的顺序关系并且能表示无因果关系的事件,将Vector clock的方法用于发现数据版本冲突,于是有了Version vector。
91100

@@ -113,4 +122,4 @@ Vector clock只用于发现数据冲突,不能解决数据冲突。如何解
113122

114123
[12][Why Vector Clocks Are Hard](http://basho.com/posts/technical/why-vector-clocks-are-hard/), Justin Sheehy, 2010
115124

116-
[13][Causality Is Expensive (and What To Do About It)](http://www.bailis.org/blog/causality-is-expensive-and-what-to-do-about-it/), Peter Bailis ,2014
125+
[13][Causality Is Expensive (and What To Do About It)](http://www.bailis.org/blog/causality-is-expensive-and-what-to-do-about-it/), Peter Bailis ,2014

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /