今天来看一个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管理的增删改查。首先来看下数据库:
移除点击此处添加图片说明文字然后建库。
移除点击此处添加图片说明文字