mirror of
https://github.com/tiennm99/zfoo.git
synced 2026-05-19 17:29:39 +00:00
jaysunxiao
257 lines
17 KiB
Markdown
257 lines
17 KiB
Markdown
## 一.分布式系统
|
||
|
||
#### 分布式系统的定义：
|
||
|
||
- 分布式系统是一个硬件或软件组分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
|
||
|
||
#### 分布式系统的特点：
|
||
|
||
1. 分布性
|
||
分布式系统中的多台计算机在空间上随意分布，不同城市，不同机房，不同机柜
|
||
2. 对等性
|
||
没有主/从之分，没有控制整个系统的主机，也没有被控制的从机，分布式系统所有的计算机节点都是对等的
|
||
3. 并发性
|
||
银行转账A转B问题
|
||
|
||
#### 分布式系统的各种问题：
|
||
|
||
1. 通信异常
|
||
单机内存访问的延时在纳秒量级（通常10ns），而一次网络通信的延迟在0.1-1ms左右，相当于内存访问延时的100多倍
|
||
2. 网络分区
|
||
网络由于发生异常，导致分布式系统中部分节点之间的网络延时不断增大，最终导致分布式系统中只有部分节点能保持正常通行，将这个现象称为网络分区。
|
||
这时会出现小集群，在极端情况下，这些小集群需要完成整个分布式系统所要完成的工作。
|
||
3. 三态
|
||
分布式系统中每一次的请求与相应，都存在三态，成功，失败，超时。 出现超时现象无法确定当前请求是否被成功处理
|
||
4. 节点故障
|
||
每个节点都有可能会出现故障，并且每天都在发生
|
||
5. 缺乏全局时钟
|
||
很难定义两个时间谁先谁后
|
||
|
||
## 二.分布式一致性算法
|
||
|
||
#### 事务（Transaction）
|
||
|
||
- ACID
|
||
|
||
1. 原子性（Atomicity）[ˌætəˈmɪsɪti] 要么做要么不做
|
||
2. 一致性（Consistency）事务的执行不能破坏数据库的完整性和一致性
|
||
3. 隔离性（Isolation）[ˌaɪsəˈleʃən] 在标准的SQL规范中有4个事务隔离级别
|
||
未授权读取，授权读取，可重复读取，串行化。
|
||
|
||
4. 持久性（Durability）[djʊərə'bɪlətɪ] 事务一旦提交，它对数据库的状态变更就应该是永久性的。
|
||
|
||
#### CAP定理（CAP theorem /ˈθɪərəm/）
|
||
|
||
- C：一致性(Consistency)，所有节点在同一时间具有相同的数据
|
||
- A：可用性(Availability)，保证每个请求在一定时间内，不管成功或者失败都有响应
|
||
- P：分区容错性(Partition tolerance)，系统中任意信息的丢失或失败不会影响系统的继续运作，一般指增加删除节点导致网络分区，不同分区依然可用
|
||
|
||
```
|
||
CA：
|
||
CA要求在多个节点满足数据的严格一致性，且延迟较低。
|
||
如果要满足P，则可以容忍数据丢包，因为数据在跨节点传输时有可能会丢包，如果丢包就无法满足一致性。
|
||
所以CA一般单点集群，传统的数据库系统就是具有CA特征的数据库，所以在可扩展性上不强，水平扩展能力比较差。
|
||
|
||
CP：
|
||
满足一致性，分区容忍性的系统，因为P会导致系统的节点无线延长，也就无法在一定时间内保证可用性。
|
||
通常性能不是特别高。
|
||
|
||
AP：
|
||
满足可用性，分区容忍性的系统，就要放弃强一致性，保证最终一致性。因为为了保证可用性，有时候节点就会用自己的本地数据，导致数据不一致性。
|
||
|
||
因为是分布式系统，所以应用必然需要部署到不同的节点中，因此必然出现子网络，所以P是分布式系统首先需要满足的。
|
||
系统架构师往往把精力花在如何根据业务特点在C和A之间寻求平衡。
|
||
```
|
||
|
||
#### BASE理论：
|
||
|
||
```
|
||
Basically Available（基本可用），运行损失部分可用性，如响应时间加长，或者功能上的损失，如双11服务降级
|
||
Soft state（软状态），允许在不同节点的数据副本之间进行数据同步的过程中存在延时
|
||
Eventually consistency（最终一致性），系统中的副本，在经过一段时间的同步后，最终能够达到一个一致的状态
|
||
三个短语的简写即为BASE，BASE是对CAP中一致性和可用性权衡的结果，核心思想是即使无法做到强一致性（Strong consistency），但每个业务可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
|
||
```
|
||
|
||
#### 分布式一致性协议：
|
||
|
||
当一个事务需要跨多个分布式节点的时候，为了保持事务处理的ACID特性，就需要引入一个称为“协调者”的组件来统一调度所有分布式节点的执行逻辑，来保证一致性。
|
||
|
||
2PC：Two Phase Commit，二段提交协议，大多数关系型数据库都是采用的这个协议来完成分布式事务的
|
||
|
||
|
||
3PC：Three Phase Commit，三阶段提交协议
|
||
|
||
#### Paxos：分布式一致性算法
|
||
|
||
Proposer（提议者），Acceptor（决策者），Client（产生议题者），Learner（最终决策学习者）
|
||
现在通过一则故事来学习paxos的算法的流程(2阶段提交)，有2个Client(老板，老板之间是竞争关系)和3个Acceptor(政府官员)：
|
||
现在需要对一项议题来进行paxos过程，议题是“A项目我要中标！”，这里的“我”指每个带着他的秘书Proposer的Client老板。
|
||
Proposer当然听老板的话了，赶紧带着议题和现金去找Acceptor政府官员。作为政府官员，当然想谁给的钱多就把项目给谁。
|
||
Proposer-1小姐带着现金同时找到了Acceptor-1~Acceptor-3官员，1与2号官员分别收取了10比特币，找到第3号官员时，没想到遭到了3号官员的鄙视，3号官员告诉她，Proposer-2给了11比特币。
|
||
不过没关系，Proposer-1已经得到了1,2两个官员的认可，形成了多数派(如果没有形成多数派，Proposer-1会去银行提款在来找官员们给每人20比特币，这个过程一直重复每次+10比特币，直到多数派的形成)，
|
||
满意的找老板复命去了，但是此时Proposer-2保镖找到了1,2号官员，分别给了他们11比特币，1,2号官员的态度立刻转变，都说Proposer-2的老板懂事，这下子Proposer-2放心了，搞定了3个官员，
|
||
找老板复命去了，当然这个过程是第一阶段提交，只是官员们初步接受贿赂而已。故事中的比特币是编号，议题是value。
|
||
这个过程保证了在某一时刻，某一个proposer的议题会形成一个多数派进行初步支持。
|
||
===============华丽的分割线，第一阶段结束================ 现在进入第二阶段提交，现在proposer-1小姐使用分身术(多线程并发)
|
||
分了3个自己分别去找3位官员，最先找到了1号官员签合同，遭到了1号官员的鄙视，
|
||
1号官员告诉他proposer-2先生给了他11比特币，因为上一条规则的性质proposer-1小姐知道proposer-2第一阶段在她之后又形成了多数派(至少有2位官员的赃款被更新了);
|
||
此时她赶紧去提款准备重新贿赂这3个官员(重新进入第一阶段)，每人20比特币。刚给1号官员20比特币， 1号官员很高兴初步接受了议题，还没来得及见到2,3号官员的时候，
|
||
这时proposer-2先生也使用分身术分别找3位官员(注意这里是proposer-2的第二阶段)，被第1号官员拒绝了告诉他收到了20比特币，
|
||
第2,3号官员顺利签了合同，这时2，3号官员记录client-2老板用了11比特币中标，因为形成了多数派，所以最终接受了Client2老板中标这个议题，对于proposer-2先生已经出色的完成了工作；
|
||
|
||
这时proposer-1小姐找到了2号官员，官员告诉她合同已经签了，将合同给她看，proposer-1小姐是一个没有什么职业操守的聪明人，觉得跟Client1老板混没什么前途，
|
||
所以将自己的议题修改为“Client2老板中标”，并且给了2号官员20比特币，这样形成了一个多数派。顺利的再次进入第二阶段。由于此时没有人竞争了，顺利的找3位官员签合同，
|
||
3位官员看到议题与上次一次的合同是一致的，所以最终接受了，形成了多数派，proposer-1小姐跳槽到Client2老板的公司去了。
|
||
|
||
#### ZAB：原子消息广播协议算法
|
||
|
||
ZAB：Zookeeper Atomic Broadcast，原子消息广播协议，Zookeeper分布式一致性的核心算法。包括两部分：崩溃恢复和消息广播（类似二阶段的提交过程）。
|
||
具体一点可以分为三个阶段：发现（Leader选举），同步（Leader和Follower之间的同步），广播（接受客户端新的事务请求）。
|
||
每个节点都可能处在三种状态，looking：leader选举阶段，following：follower服务器和leader保持同步状态，leading：Leader服务器作为主进程领导状态。
|
||
|
||
Paxos和ZAB的本质区别在于两者的设计目标不太一样。前者用于构建一个分布式的一致性状态机系统，而后者用于构建一个高可用的分布式数据主备系统。
|
||
|
||
## 三.Zookeeper基本说明
|
||
|
||
#### Zookeeper的定义：
|
||
|
||
- Zookeeper是一个高可用的分布式数据管理与协调框架
|
||
|
||
#### Zookeeper应用范围：
|
||
|
||
分布式应用可以基于Zookeeper实现如分布式一致性特性，数据发布/订阅，负载均衡，命名服务，分布式协调/通知,集群管理，Master选举，分布式锁，分布式队列
|
||
|
||
#### Zookeeper特点
|
||
|
||
- 高性能：Zookeeper将全量数据存储在内存中，并直接服务于客户端的所有非事务请求，因此它尤其适用于以读操作为主的应用场景。Zookeeper性能压测在100%读请求的场景下可以达到12-13W的QPS。
|
||
- 顺序访问：对于每一个客户端的请求，Zookeeper都会生成一个全局唯一的递增序号，这个序号反映了所有事务操作的先后顺序，应用程序可以使用这个特性来实现更高层次的同步原语。
|
||
- Leader服务器在产生一个新的事务的时候，会生成一个序列号ZXID，Zookeeper Transaction ID，这个ID有64位，前32位代表事务编号，每个事务加1，后32位代表发给客户端的计数器，每发给客户端计数器加1。
|
||
|
||
|
||
#### Zookeeper的三种选举算法：LeaderElection，AuthFastLeaderElection，FastLeaderElection
|
||
|
||
默认的算法是FastLeaderElection：
|
||
启动时的选举算法如下：
|
||
|
||
1. 目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：
|
||
2. 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
|
||
3. 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
|
||
4. 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
|
||
5. 服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
|
||
6. 服务器5启动，后面的逻辑同服务器4成为小弟。
|
||
|
||
崩溃恢复时的选举算法：
|
||
|
||
|
||
|
||
|
||
## 四.Zookeeper的应用
|
||
|
||
#### 数据发布/订阅
|
||
|
||
- 发布/订阅一般有两种设计模式，Zookeeper采用推拉结合的方式，一旦节点数据发生变化，服务端就会向客户端发送Watcher事件通知，客户端自己拉取想要的数据
|
||
|
||
```
|
||
服务器主动推（Push）：服务器主动将数据更新发送给所有订阅的客户端，这种数据量在短时间可能会很大
|
||
客户端主动拉（Pull）：客户端主动发起请求获取最新的数据，通常采用定时轮询的方式，这种缺点就是空轮询，客户端开销大
|
||
```
|
||
|
||
- 试用的场合
|
||
|
||
```
|
||
数据量比较小
|
||
数据内容在运行时会发生动态变化
|
||
集群中各机器共享，配置一致
|
||
```
|
||
|
||
#### 负载均衡
|
||
|
||
- 可分为硬件负载均衡和软件负载均衡
|
||
|
||
四层通过虚拟IP+端口接收请求，然后再分配到真实的服务器，如四层的负载均衡，就是通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，
|
||
对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。 以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN
|
||
请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。
|
||
TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。
|
||
在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
|
||
|
||
七层通过虚拟的URL或主机名接收请求，然后再分配到真实的服务器，七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征。
|
||
比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。
|
||
举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
|
||
以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，
|
||
然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。
|
||
负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。
|
||
|
||
负载均衡器通常称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP层，实现四层流量负载均衡。七层交换机除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息。
|
||
|
||
1、负载均衡分为L4 switch（四层交换），即在OSI第4层工作，就是TCP层啦。此种Load Balance不理解应用协议（如HTTP/FTP/MySQL等等）。例子：LVS，F5。
|
||
2、另一种叫做L7 switch（七层交换），OSI的最高层，应用层。此时，该Load Balancer能理解应用协议。例子： haproxy，MySQL Proxy。
|
||
|
||
|
||
|
||
#### 命名服务
|
||
|
||
- 集群中全局唯一ID的生成，用Java自带的UUID生成的是一长串没有意义的ID，在Zookeeper中创建一个顺序生成节点可以方便的生成全局唯一ID
|
||
|
||
#### 分布式协调/通知
|
||
|
||
- 在绝大多数的分布式系统中，系统机器间的通讯无外乎心跳检测，工作进度汇报和系统调度这三种类型
|
||
|
||
1. 心跳检测
|
||
|
||
```
|
||
传统的方案是一段时间A通ping到B，来判断A和B是否相连。
|
||
基于Zookeeper的心跳检测，A可以在Zookeeper注册一个临时节点，B监听这个节点的变化判断是否相连，这样可以极大的解耦合
|
||
```
|
||
|
||
2. 工作进度汇报
|
||
|
||
```
|
||
注册一个临时节点，节点的内容为自己的任务
|
||
```
|
||
|
||
3. 系统调度
|
||
|
||
```
|
||
通过临时节点的数据变化，控制其它监听该节点的系统
|
||
```
|
||
|
||
#### 集群管理
|
||
|
||
- 机器的上下线，机器监控
|
||
|
||
#### Master选举
|
||
|
||
- 集群中所有的节点同事注册一个/master的临时节点，哪个注册成功哪个就是master节点
|
||
|
||
#### 分布式锁
|
||
|
||
- 排它锁
|
||
|
||
```
|
||
获取锁：所有的客户端同事创建一个/lock临时节点，Zookeeper保证所有的客户端只有一个能创建成功，就认为这个客户端获取了锁，其它客户端注册监听，以便释放锁的时候重新获取锁
|
||
释放锁：获取锁的节点宕机，临时节点就会被移除；正常的执行业务逻辑后，主动释放锁，即删除这个临时节点
|
||
```
|
||
|
||
- 共享锁，又称为读锁
|
||
|
||
```
|
||
加上共享锁的对象，只能对锁中的内容进行读取操作，其它的事物也只能对该对象加共享锁
|
||
```
|
||
|
||
#### 分布式队列
|
||
|
||
- FIFO分布式队列
|
||
- Barrier分布式屏障
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|