zk和db

ZK：

选举原理：leader 选举存在与两个阶段中，一个是服务器启动时的 leader 选举。 另
一个是运行过程中 leader 节点宕机导致的 leader 选举 .

参数：myid：比如有三台服务器，编号分别是 1,2,3。编号越高权重越大。

           zxid：事务id，或者可以说是偏移量。

           逻辑时钟。epoch – logicalclock 。也可以叫朝代或者投票的轮数。

启动选举步骤：

1、a/b 投票。第一次都是都自己。带上必须要信息myid 和 ZXID、epoch，使用(myid, ZXID,epoch)来表示.

2、集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票（epoch）、是否来自LOOKING 状态的服务器。

3、针对每一个投票，服务器都需要将别人的投票和自己的投票进行 PK，先比epoch，再比zxid，再比myid。 由此可见。b的myid大于a。这个时候，a会将自己的票变更为b。b自己则不用改变票据。则而且此时没有大于半数的机器选出。

4、再次投票，两人都会投b。则leader选举完成(准leader)

运行过程中的 leader 选举：

与启动时流程一样。但整个集群在选举期间是不可用的。

ZAP协议数据一致性：消息广播模式；崩溃恢复模式

广播模式：

leader中队每一个follow都维护了一个FIFO队列，有请求事务提交后，会都会分配一个zxid放到队列中，异步线程则从队列中拉取数据到follower。

1. 客户端发起一个写操作请求 
2. Leader服务器将客户端的request请求转化为事物proposql，同时为每个proposal分配一个全局唯一的ID，即ZXID。 
3. leader服务器与每个follower之间都有一个队列，leader将消息发送到该队列 
4. follower机器从队列中取出消息处理完(写入本地事物日志中)毕后，向leader服务器发送ACK确认。 
5. leader服务器收到半数以上的follower的ACK后，即认为可以发送commit 
6. leader向所有的follower服务器发送commit消息。

 崩溃恢复模式：

当leader挂了以后。我们必须选出新的master节点。新的节点必须满足：

1. 确保已经被leader提交的proposal必须最终被所有的follower服务器提交
2. 确保丢弃已经被leader发出的但是没有被提交的proposal 

即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时，新选举的leader节点中含有最高的ZXID。leader服务器发生崩溃时分为如下场景:

1. leader在提出proposal时未提交之前崩溃，则经过崩溃恢复之后，新选举的leader一定不能是刚才的leader。因为这个leader存在未提交的proposal。 恢复后它再次提交之前未提交成功的数据就会有问题，因为此时客户端是认为失败了。
2. leader在发送commit消息之后，崩溃。即消息已经发送到队列中。经过崩溃恢复之后，参与选举的follower服务器(刚才崩溃的leader有可能已经恢复运行，也属于follower节点范畴)中有的节点已经是消费了队列中所有的commit消息。即该follower节点将会被选举为最新的leader。剩下动作就是数据同步过程

3. Follower 和 Observer 同步数据的方式一共有三种：DIFF、SNAP、TRUNC

   DIFF 需要 Follower 或 Observer 和 Leader 的数据相差在 min 和 max 范围内，或者配置了允许从 log 文件中恢复

   TRUNC 是当 Follower 或 Observer 的 zxid 比 Leader 还要大的时候，该节点需要主动删除多余 zxid 相关的数据，降级至 Leader 一致

   SNAP 作为最后的数据同步手段，由 Leader 直接将内存数据整个序列化完并发送给 Follower 或 Observer，以达到恢复数据的目的

4. 当半数以上follow完成同步，此时准leader成为新leader。

当leader节点选出来之后。新leader将自己的zxid发给其他follow。进行数据同步。ZXID是一个长度64位的数字，其中低32位是按照数字递增，即每次客户端发起一个proposal,低32位的数字简单加1。高32位是leader周期的epoch编号，至于这个编号如何产生，每当选举出一个新的leader时，新的leader就从本地事物日志中取出ZXID,然后解析出高32位的epoch编号，进行加1，再将低32位的全部设置为0。

ZAB协议要求每个leader都要经历三个阶段，即发现，同步，广播。

1. 发现选举：即要求zookeeper集群必须选择出一个leader进程，同时leader会维护一个follower可用列表。将来客户端可以这follower中的节点进行通信。
2. 同步恢复：leader要负责将本身的数据与follower完成同步，做到多副本存储。这样也是体现了CAP中高可用和分区容错。follower将队列中未处理完的请求消费完成后，写入本地事物日志中。
3. 广播：leader可以接受客户端新的proposal请求，将新的proposal请求广播给所有的follower。

时间顺序一致性：zookeeper并不是强时间顺序一致性，其实现是通过全家zxid实现。当请求的proposal服务端的zxid小于自身的zxid将无法查询到结果，也可以先要求follow节点先同步再查询。

ZK 会持久化到磁盘的文件有两种：log 和 snapshotlog 负责记录每一个写请求snapshot 负责对当前整个内存数据进行快照恢复数据的时候，会先读取最新的 snapshot 文件然后再根据 snapshot 最大的 zxid 去搜索符合条件的 log 文件，再通过逐条读取写请求来恢复剩余的数据

Dobbo：

服务暴露：

1、根据检测的配置创建URL,根据URL创建代理类invoker，在根据传输协议创建exporter

2、如果只在本地内暴露，则将exporter在本地注册表注册。

3、远程暴露，先在exporter创建好之后，获取 注册中心地址，向注册中心注册后，设置本地注册表ProvideConsumerRegtable里注册标志。其是个CHMap。key是类全限定名，value是封装的invoker的set集合。暴露erporter之后，调用nettserver监听。

服务发现：

1、向注册中心注册自己，并订阅providers

2、根据拿到的providers，cluster将多个服务提供者封装成一个invoker

3、通过url构建一个invoker的map，通过返回的invoker构建一个代理对象，之后consumer调用这个代理对象。

 消费者调用时，cluster根据均衡策略来选择其中的一invoker发起远程调用，服务端通过之前暴露的exporter找到实现类返回执行结果并且带上请求的id标识，消费者通过id找到之前的请求id放到请求的响应，唤起等待的线程得到响应。

容错机制：

失败自动切换，默认方案，默认重试1次

失败自动返回空结果，定时重试

快速失败，失败后直接抛出异常

安全失败，失败后不抛异常，返回空

并行调用，每次调用都会向服务列表的每一个发送请求，第一个返回即返回

广播：全部调用，一个报错就算报错。