Zookeper+Dubbox

分布式概述

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

zookeeper概述

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

数据一致性

用户从银行账号取钱，取钱的操作请求落到db1上，账户总共1000，取完100，更新余额还剩900。此时用户再去查询余额，查询请求落到DB2上，此时正好，db1的数据还没来得及和db2之间做个数据同步，所以就会产生明明取出100，但是余额还是1000的数据不一致的情况。

• 强一致性
  如果数据不一致，就不对外提供数据服务，保证用户读取的数据始终是一致的。就是在db2没有和db1同步数据之前上锁。不让其他线程读取数据，直到数据同步完成，才释放锁。
• 最终一致性
  最终数据同步即可，不要求实时性。

CAP原则

cap分布式系统中主要指一致性（consistency）,可用性（availability）和分区容错性（Partition tolerance）

一致性：系统的强一致性。
可用性：系统提供的服务一直处于可用状态，用户的操作请求在指定的时间内响应请求，超出时间范围，认为系统不可用。
分区容错性：
分布式系统在遇到任何网络分区故障的时候，仍需要保证对外提供一致性和可用性服务，除非是整个网络系统都发生故障。
在一个分布式系统中不可能同时满足一致性，可用性，分区容错性，最多满足2个，一般保证p(分区容错性)，要么满足AP模型，要么满足CP模型。

一致性协议

1.二阶段提交

阶段1事务提交:
协调者向所有的参与者发送事务内容，询问是否可以执行事务操作，并等待相关参与者的ack。
参与者预执行事务，执行完毕后向协调者发送ack,告诉参与者是否可以执行事务。
阶段2事务提交

根据第一阶段所有参与者提交的ack，如果都返回ack，则进行真的事务提交
事务提交
1.协调者向各个参与者节点发送commit请求。
2.参与者接收到来自协调者的commit请求后，执行事务的提交操作。
3.各参与者在完成事务提交后，向协调者发送事务提交成功的消息。
4.协调者在收到所有参与者节点的提交成功ack的消息后，完成最终的事务commit.
中断事务
如果有部分参与者节点没有给协调者发送事务提交成功的ack,

• 1.协调者发送回滚请求给各个参与者节点
• 2.各个参与者就会进行事务回滚。
• 3.参与者节点回滚完成后反馈给协调者，协调者再去进行最终的事务回滚。

二阶段提交的问题：

• 1.协调者同步阻塞的问题。
• 2.单点问题，协调者出现故障，无法保证其他参与者之间的一致性。
• 3.脑裂导致的数据不一致。某一个参与者与协调者因为网络原因失去连接，这时候如果协调者向参与者节点发送commit消息请求，就会导致断开的参与者节点收不到这个请求，不能完成事务的提交，从而导致，参与者节点之间的数据不一致。

2.三阶段提交

阶段1: canCommit:
其实是测试协调者和参与者之间是否能够正常通信。
1.协调者向参与者的事务询问。
2.参与者向协调者反馈事务询问的响应。
阶段2：preCommit
1.协调者会向各个参与者，发送事务预提交请求。
2.参与者接到preCommit请求后会执行事务操作。执行完后向协调者发送ack消息。
如果在阶段一中，有部分参与者没有给协调者及时响应，这时候就会执行事务中断的操作。
中断事务：
1.协调者向所有的参与者发送abort请求。参与者收到abort请求后，或者等待超时后，中断事务。
阶段3：doCommit
如果各个参与者都进行了预备提交，协调者会发送doCommit操作。
所有参与者执行doCommit操作后，发送ack给协调者。这时候协调者会执行最终的事务。
如果在此阶段，有参与者在收到doCommit的请求后，没有返回ack的操作，这时候也会执行事务的中断操作。

paxos算法

我们了解了2PC和3PC之后，我们可以发现，无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题以及无法解决太过保守及容错性不好。Google Chubby的作者Mike Burrows说过，世上只有一种一致性算法，Paxos，所有其他一致性算法都是Paxos算法的不完整版。Paxos算法是公认的晦涩，很难可能讲清楚，但是工程上也很难实现，所以有很多Paxos算法的工程实现，如Chubby， Raft，ZAB，微信的PhxPaxos等。这一篇会介绍这个公认为难于理解但是行之有效的Paxos算法。Paxos算法是莱斯利·兰伯特(Leslie Lamport)1990年提出的一种基于消息传递的一致性算法，它曾就此发表了《The Part-Time Parliament》，《Paxos Made Simple》，由于采用故事的方式来解释此算法，感觉还是很难理解。

Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一，其解决的问题就是在分布式系统中如何就某个值（决议）达成一致

paxos prepare和accept执行流程图，
详情图参考

Zookeeper使用的ZAB协议

全称叫做zookeeper atomic broadcast:是一种支持崩溃恢复的原子广播协议。基于Fast paxos实现。使用单一进程leader用于处理客户端所有事务请求，即写请求。当服务器数据发生变更时，集群采用ZAB原子广播协议，以事务提交的proposal的形式广播到所有的副进程，每一个事务分配一个全局的递增事务编号xid；假如客户端提交的请求为读请求时，则接受请求节点根据自己保存的数据响应。若是写请求，且节点不是leader，那么该节点会将请求转发给leader,leader会以提案的方式广播此写请求，如果超过半数的节点同意写请求，则该请求就会被提交。leader会通知所有的订阅者同步数据。

Zookeeper的三种角色

1.leader:负责处理集群的写请求，并发起投票，只要超过半数的节点同意后才会提交该请求。
2.follower：处理读请求，响应结果。转发写请求到leader,在选举过程中参与投票。
3.observer：可以理解为没有投票权的follower,主要时协助followerv处理读请求。当整个zk集群负载很高时，为深恶么不增加follower节点呢？因为增加follower节点会让leader在提出写请求提案时，需要半数以上的follower投票节点同意，这样会增加leader和follower的通信压力，降低写的操作效率。

Zookeeper的两种模式

恢复模式

• 当服务启动或领导崩溃后，zk进入恢复状态，选举leader，leader选出后，将完成leader和其他机器的同步，当大多数server完成和leader的同步后，恢复模式结束。

广播模式

• 一旦leader和多数的follower进行状态同步后，进入广播模式，进入广播模式后，如果有新加入的服务器，会自动从leader中同步数据。leader在接收客户端请求后，会生成事务提案广播给其他机器，有超过半数的follower同意该提议后在提交事务。
  注意在ZAB的事务二阶段提交中，移除了中断事务的逻辑。follower要么ack,要么放弃。leader无需等待所有的follower的ack。

zxid

zxid是64为长度的Long类型，其中高32位表示纪元epoch，低32位表示事务标识xid，即zxid由两部分组成，epoch和xid。
每个leader都会具有不同的epoch值，表示一个纪元，每一个新的选举开启都会生成一个新的epoch，新的leader产生，会更新所有的zkServer的zxid的epoch，xid是一个依次递增的事务编号。

zookeeper中leader选举机制

三个核心原则：
1.zookeeper集群中只有超过半数以上的服务器启动，集群才能正常工作。
2.集群正常工作前。myid小的服务器会给myid大的服务器进行投票，持续到集群正常工作，选出leader。
3.选出leader之后，之前的服务器状态由looking改为following,以后的服务器都是follower。
启动过程:
1.每一个server发出一个投票给集群中其他结点。
2.收到各个服务器的投票后，判断该投票的有效性，比如是否是本轮投票，是否是looking状态。
3.处理投票，pk自己的投票和别人的投票，比较规则：xid大的优先，如果相同比较myid。
4.统计是否超过半数服务器接受相同投票。
5.确认leader，改变服务器状态。添加新server，leader已经选举出来，以follower身份加入集群。

崩溃恢复过程：
leader挂掉后，集群中其他follower会将状态从following改为looking，重新进入leader选举，过程同上。

消息广播算法

一旦进入广播模式，集群中非leader节点接收到事务请求，首先会将事务请求转发leader，leader为其生成对应的事务提案proposal并发送给集群中其他结点，如果过半则事务提交。

1.leader接收到消息后，消息通过全局唯一的64位自增事务id，Zxid标识。

2.leader发送给follower的提案是有序的，leader会创建一个FIFO队列，将提案顺序写入队列中发送。

3.follower接收到提案后会比较提案Zxid和本地事务日志最大Zxid，若提案Zxid大则将提案记录到本地日志反馈ack给leader，否则拒绝。

4.leader接收到半数ack后，向所有follower发送commit，通知每个follower执行本地事务。

zookeeper集群搭建

集群搭建我就不细说了，下面是搭建zk集群的一些步骤。
1.准备三台虚拟机：

2.下载安装zk，我用的是zk版本是3.4.6。

3.进入zookeeper -3.4.6目录，创建data文件夹，新建myid文件。


myid：表示当前服务器编号，集群采用1，2，3区分

4.进入conf目录，将配置文件名修改zoo.cfg,然后修改配置文件中的内容。

4.启动zk ./zkServer.sh start

5.查看zk状态./zkServer.sh status



如果启动不成功，需要关闭防火墙。

zookeeper命令行使用

输入命令 ./zkCli.sh


help查看所有命令

ls / :查看当前zk下的所有结点

ls2 /test :查看当前zk下的test结点详细内容。

ls /test :仅仅查看当前zk下的test结点值

创建测试节点 create /ceshi 001，并赋予值001

获取测试节点的值 get./ceshi

修改节点的值 set /ceshi 002

删除ceshi节点 delete /ceshi

watch 监视test节点路径变化,在test 节点下新建了一个abc节点。 ls /test watch

watch 监视test节点下abc节点值的变化 get /test/abc watch