zookeeper+dubbo知识点记录

day01

1.分布式概述

早期我们使用单体架构，即所有服务部署在一台服务器的一个进程中，随着互联网的发展，逐步演进为分布式架构，多个服务分别部署在不同机器的不同进程中。

2.zookeeper概述

zookeeper是一个开源的分布式协调服务，提供分布式数据一致性解决方案，分布式应用程序可以实现数据发布订阅、负载均衡、命名服务、集群管理和分布式锁、分布式队列等功能。

数据一致性分为强一致性和最终一致性。强一致性指的是如果数据不一致，就不对外提供数据服务，保证用户读取的数据始终是一致的，数据强一致性只需要通过锁机制即可解决。而最终一致性仅要求数据最终同步即可，没有实时性要求。

3.CAP原则

CAP在分布式系统中主要指的是一致性、可用性和分区容错性。
一致性：指的是强一致性
可用性：系统提供的服务一直处于可用状态，用户的操作请求在指定的响应时间内响应请求，超出时间范围，认为系统不可用。
分区容错性：分布式系统在遇到任何网络分区故障的时候，仍需要能够保证对外提供一致性和可用性服务，除非是整个网络都发生故障。

在一个分布式系统中不可能同时满足一致性、可用性、分区容错性，最多满足两个，对于分布式互联网应用而言，必须保证P，所以要么满足AP模型，要么满足CP模型。

4.一致性协议

事务需要跨多个分布式节点时，为了保证事务的ACID特性，需要选举一个协调者来协调分布式各个节点的调度，基于这个思想衍生了多种一致性协议。

1）2PC两阶段提交

阶段1，提交事务请求：

1. 协调者向所有的参与者节点发送事务内容，询问是否可以执行事务操作，并等待其他参与者节点的反馈
2. 各参与者节点执行事务操作
3. 各参与者节点反馈给协调者，事务是否可以执行

阶段2，事务提交
根据一阶段各个参与者节点反馈的ack，如果所有参与者节点反馈ack，则执行事务提交，否则中断事务

事务提交：

1. 协调者向各个参与者节点发送commit请求
2. 参与者节点接收到commit请求后，执行事务的提交操作
3. 各参与者节点完成事务提交后，向协调者返送提交commit成功确认消息
4. 协调者接收各个参与者节点的ack后，完成事务commit

---

中断事务：

1. 发送回滚请求
2. 各个参与者节点回滚事务
3. 反馈给协调者事务回滚结果
4. 协调者接受各参与者节点ack后回滚事务

两阶段提交存在的问题：

1. 同步阻塞
   两阶段提交过程中，所有参与事务操作的节点处于同步阻塞状态，无法进行其他的操作
2. 单点问题
   一旦协调者出现单点故障，无法保证事务的一致性操作
3. 脑裂导致数据不一致
   如果分布式节点出现网络分区，某些参与者未收到commit提交命令，则出现部分参与者完成数据提交。未收到commit命令的参与者则无法进行事务提交，整个分布式系统便出现了数据不一致现象。

2）3PC三阶段提交

3PC是2PC的改进版，实质是将2PC中提交事务请求拆分为两步，形成了CanCommit、PreCommit、doCommit三个阶段的事务一致性协议

阶段一：CanCommit

1.事务询问
2.各参与者节点像协调者反馈事务询问的响应

阶段二：PreCommit

根据阶段一的反馈结果分为两种情况。

1、执行事务预提交

1.发送预提交请求
协调者向所有参与者节点发送PreCommit请求，进入prepared阶段
2.事务预提交
各参与者节点收到preCommit请求后，执行事务操作
3.各参与者向协调者反馈事务执行

2、中断事务

任意一个参与者节点反馈给协调者响应No时，或者在等待超时后，协调者还未收到参与者的反馈就中断服务，中断事务分为两步：
1.协调者向各个参与者节点发送abort请求
2.参与者收到abort请求，或者在等待超时时间后，就中断事务

阶段三：doCommit

1、执行提交

1.发送提交请求
协调者向所有参与者节点发送doCommit请求
2.事务提交
各参与者节点接收到doCommit请求后，执行事务提交操作
3.反馈事务提交结果
各参与者节点完成事务提交后，向协调者发送ack
4.事务完成
协调者接收各个参与者反馈的ack后，完成事务

2、中断事务

1.参与者接收到abort请求后，执行事务回滚
2.参与者完成事务回滚后，向协调者发送ack
3.协调者接收回滚ack后，回滚事务

3PC相较于2PC而言，解决了协调者挂点后参与者无限阻塞和单点问题，但是仍然无法解决网络分区问题。

3）paxos算法

基于消息传递且具有高度容错性的一种算法，是目前公认的解决分布式一致性问题最有效的算法。

解决问题：在分布式系统中，如果产生宕机或者网络异常情况，快速的正确的在集群内部对某个数据的值达成一致，并且不发生任何异常，都不会破坏整个系统的一致性。

重要概念：半数原则，少数服从多数。

paxos中的4个角色：

1.Client：产生提案者
2.proposer：提案者==
3.acceptor：决策者==
4.learner：学习者

paxos分为两个阶段：

1.prepare阶段：准备阶段
2.accept阶段：同意阶段

4)ZAB协议

由于paxos算法实现起来较难，存在活锁和全序问题，所有zookeeper并没有使用paxos作为一致性协议，而是使用了ZAB协议。

ZAB协议是一种支持崩溃恢复的原子广播协议，基于Fast paxos实现。

zookeeper的三种角色：

为了避免zk的单点问题，zk采用集群方式保证zk高可用
leader：leader负责处理集群的写请求，并发起投票，只有超过半数的节点同意后才会提交该写请求。
follower：处理读请求，响应结果。转发写请求到leader，在选举leader过程中参与投票。
observer：可以理解为没有投票权的follower，主要职责是协助follower处理读请求。那么当集群读请求负载很高时，为什么不增加follower节点呢？因为增加follower节点会让leader在提出写请求提案时，需要半数以上的follower投票节点同意，这样会增加leader和follower的通信压力，降低写操作效率、

zookeeper的两种模式：

1.恢复模式
当服务启动或领导崩溃后，zk进入恢复状态，选举leader，leader选举出来后，将完成leader和其他机器的数据同步，当大多数server完成和leader的数据同步后，恢复模式结束。
2.广播模式
一旦Leader已经和多数的Follower进行了状态的同步之后，进入广播模式。进入广播模式后，如果有新加入的服务器，会自动从Leader中同步数据。Leader在接收客户端请求后，会生成事务提案广播给其他机器，有超过半数以上的Follower同意该提议后，再提交事务。
注意在ZAB的事务的二阶段提交中，移除了事务中断的逻辑，Follower要么ack，要么放弃，Leader无需等待所有的Follower的ack。

Leader选举算法：

三个核心选举原则：

1.zookeeper集群中只要超过半数以上的服务器启动，集群才能正常工作
2.在集群正常工作之前，myid小的服务器会给myid大的服务器进行投票，持续到集群正常工作，选出leader
3.选择Leader之后，之前的服务器状态由looking改变为following，以后的服务器都是Follower

启动过程：

每一个server发出一个投票给集群中其他节点
收到各个服务的投票后，判断该投票有效性，比如是否是本轮投票，是否是looking状态
处理投票，pk别人的投票和自己的投票，比较投票规则xid>myid"取大原则"
统计是否超过半数的接受相同的选票
确认Leader，改变服务器状态
添加新server，Leader已经选举出来，只能以Follower身份加入到集群中。

崩溃恢复过程：

Leader挂掉后，集群中其他Follower会将状态从Follower变为looking，重新进入Leader选举
同上启动过程

day02

1.dubbo

apache dubbo是一款高性能的java RPC框架，提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

RPC

远程过程调用。比如两台服务器A和B，A服务器上部署一个应用，B服务器上部署一个应用，A服务器上的应用想调用B服务器上的应用提供的方法，由于两个应用不在一个内存空间，不能直接调用，所以需要通过网络来表达调用的语义和传达调用的数据。RPC不是一个具体的技术，而是指整个网络远程调用过程。

2.手写RPC框架

provider服务提供
cosumer服务消费
registry注册
protocol协议

day03

1.dubbo高可用

1）集群容错

服务路由

服务路由包含一条路由规则，路由规则决定了服务消费者的调用目标，即规定了服务消费者可调用哪些服务提供者。dubbo提供三种服务路由实现，分别为条件路由、脚本路由、标签路由。
条件路由的格式：
[服务消费者匹配条件]=>[服务提供者匹配条件]
host=10.20.153.10=>host=10.20.153.11
该条规则表示IP为10.20.153.10的服务消费者只可调用IP为10.20.153.11机器上的服务，不可调用其他机器上的服务。
如果服务消费者匹配条件为空，表示不对服务消费者进行限制。如果服务提供者匹配条件为空，表示对某些服务消费者禁用服务。

集群容错

1.Failover Cluster失败自动切换，重试其他服务器。通常用于读操作，但重试会带来更长延迟。通常可以设置retries="2"来设置重试次数(不包含第一次)。
2.Failfast Cluster快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
3.Failsafe Cluster失败安全，出现异常时，直接忽略。通常用于写日志等操作。
4.Failback Cluster失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
5.Forking Cluster并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多资源，可通过设置forks=“2”来设置最大并行数。
6.Broadcast Cluster广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

负载均衡

Random LoadBalance：按照权重设置随机概率，无状态
RoundRobin LoadBalance：轮询，有状态
LeastActive LoadBalance：最少活跃数随机，方法维度的统计服务调用数
ConsistentHash LoadBalance：一致性hash

2）服务治理

2.dubbo线程IO模型

BIO

每个客户端连接过来后，服务端都会启动一个线程去处理该客户端的请求。

NIO

也叫做new-IO或者non-blocking-IO，可理解为非阻塞IO。NIO编程模型中，新来一个连接不再创建一个新的线程，而是可以把这条连接直接绑定到某个固定的线程，然后这条线程所有的读写都由这个线程来负责。