zookeeper+dubbo框架开发

今天来看一个zookeeper框架开发，以及增删改查的开发

也因为时间关系，没有写全，后期会找到时间，将其补充上来。

先看下效果吧。

首先我们启动zookeeper，分布式协调一致性处理，

  移除点击此处添加图片说明文字

​2181端口启动，即可。然后我们注册服务，启动service层的main，向zookeeper注册provider

  移除点击此处添加图片说明文字

​接着启动consumer消费者，这个我们发布在tomcat容器中的。

  移除点击此处添加图片说明文字

​启动后我们看下这个，

  移除点击此处添加图片说明文字

​这是界面。然后我们登录。

  移除点击此处添加图片说明文字

​呐，效果展示我们就写到这么多，这个比较成熟的在于，许多开发入库可配置，所以，今天拿出来说一下流程。

ZooKeeper是以Fast Paxos算法为基础的，Paxos 算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader (领导者)，只有leader才能提交proposer，具体算法可见Fast Paxos。因此，要想弄懂ZooKeeper首先得对Fast Paxos有所了解。[3]

ZooKeeper的基本运转流程：

1、选举Leader。

2、同步数据。

3、选举Leader过程中算法有很多，但要达到的选举标准是一致的。

4、Leader要具有最高的执行ID，类似root权限。

5、集群中大多数的机器得到响应并follow选出的Leader。

那么关于dubbo 。

Dubbo是Alibaba开源的分布式服务框架，我们可以非常容易地通过Dubbo来构建分布式服务，并根据自己实际业务应用场景来选择合适的集群容错模式，这个对于很多应用都是迫切希望的，只需要通过简单的配置就能够实现分布式服务调用，也就是说服务提供方（Provider）发布的服务可以天然就是集群服务，比如，在实时性要求很高的应用场景下，可能希望来自消费方（Consumer）的调用响应时间最短，只需要选择Dubbo的Forking Cluster模式配置，就可以对一个调用请求并行发送到多台对等的提供方（Provider）服务所在的节点上，只选择最快一个返回响应的，然后将调用结果返回给服务消费方（Consumer），显然这种方式是以冗余服务为基础的，需要消耗更多的资源，但是能够满足高实时应用的需求。  

好了，接下来，我们记录一下开发步骤，开发一个关于offer管理的增删改查。首先来看下数据库：

  移除点击此处添加图片说明文字

​然后建库。

  移除点击此处添加图片说明文字