day01
1.分布式概述
早期我们使用单体架构，即所有服务部署在一台服务器的一个进程中，随着互联网的发展，逐步演进为分布式架构，多个服务分别部署在不同机器的不同进程中。
2.zookeeper概述
zookeeper是一个开源的分布式协调服务，提供分布式数据一致性解决方案，分布式应用程序可以实现数据发布订阅、负载均衡、命名服务、集群管理和分布式锁、分布式队列等功能。
数据一致性分为强一致性和最终一致性。强一致性指的是如果数据不一致，就不对外提供数据服务，保证用户读取的数据始终是一致的，数据强一致性只需要通过锁机制即可解决。而最终一致性仅要求数据最终同步即可，没有实时性要求。
3.CAP原则
CAP在分布式系统中主要指的是一致性、可用性和分区容错性。
一致性：指的是强一致性
可用性：系统提供的服务一直处于可用状态，用户的操作请求在指定的响应时间内响应请求，超出时间范围，认为系统不可用。
分区容错性：分布式系统在遇到任何网络分区故障的时候，仍需要能够保证对外提供一致性和可用性服务，除非是整个网络都发生故障。
在一个分布式系统中不可能同时满足一致性、可用性、分区容错性，最多满足两个，对于分布式互联网应用而言，必须保证P，所以要么满足AP模型，要么满足CP模型。
4.一致性协议
事务需要跨多个分布式节点时，为了保证事务的ACID特性，需要选举一个协调者来协调分布式各个节点的调度，基于这个思想衍生了多种一致性协议。
1）2PC两阶段提交
阶段1，提交事务请求：
- 协调者向所有的参与者节点发送事务内容，询问是否可以执行事务操作，并等待其他参与者节点的反馈
- 各参与者节点执行事务操作
- 各参与者节点反馈给协调者，事务是否可以执行
阶段2，事务提交
根据一阶段各个参与者节点反馈的ack，如果所有参与者节点反馈ack，则执行事务提交，否则中断事务
事务提交：
- 协调者向各个参与者节点发送commit请求
- 参与者节点接收到commit请求后，执行事务的提交操作
- 各参与者节点完成事务提交后，向协调者返送提交commit成功确认消息
- 协调者接收各个参与者节点的ack后，完成事务commit
中断事务：
- 发送回滚请求
- 各个参与者节点回滚事务
- 反馈给协调者事务回滚结果
- 协调者接受各参与者节点ack后回滚事务
两阶段提交存在的问题：
- 同步阻塞
两阶段提交过程中，所有参与事务操作的节点处于同步阻塞状态，无法进行其他的操作 - 单点问题
一旦协调者出现单点故障，无法保证事务的一致性操作 - 脑裂导致数据不一致
如果分布式节点出现网络分区，某些参与者未收到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编程模型中，新来一个连接不再创建一个新的线程，而是可以把这条连接直接绑定到某个固定的线程，然后这条线程所有的读写都由这个线程来负责。
