Dubbo+Zoopkeeper

Dubbo和Springcloud都是分布式服务中常用的框架。dubbo与cloud不同，dubbo基于RPC协议。它提供了三大核心功能: 面向接口的远程方法调用,智能容错和负载均衡, 以及服务自动注册和发现。

Dubbo按照分层的方式来架构，可以最大限度地松耦合。Dubbo采用一种非常简单的模型, 要么提供方提供服务, 要么是消费方消费服务, 所以基于这一点可以抽象出服务提供方和服务消费方两个角色。

Zookeeper

分布式服务框架，解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

zookeeper=文件系统+监听通知机制

应用场景

分布式协调

　　这个其实是 zookeeper 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。那 A 系统
如何知道 B 系统的处理结果？用 zookeeper 就可以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zookeeper 上对某个节点
的值注册个监听器，一旦 B 系统处理完了就修改 zookeeper 那个节点的值，A 系统立马就可以收到通知，完美解决。

 

分布式锁

 

　　举个栗子。对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行完另外一个机器再执行。那么此时就
可以使用 zookeeper 分布式锁，一个机器接收到了请求之后先获取 zookeeper 上的一把分布式锁，就是可以去创建一个 znode，接着执行
操作；然后另外一个机器也尝试去创建那个 znode，结果发现自己创建不了，因为被别人创建了，那只能等着，等第一个机器执行完了自己再执行。

 

元数据/配置信息管理

 

　　zookeeper 可以用作很多系统的配置信息的管理，比如 kafka、storm 等等很多分布式系统都会选用 zookeeper 来做一些元数据、
配置信息的管理，包括 dubbo 注册中心不也支持 zookeeper 么？

 

HA高可用性

 

　　这个应该是很常见的，比如 hadoop、hdfs、yarn 等很多大数据系统，都选择基于 zookeeper 来开发 HA 高可用机制，就是一个
重要进程一般会做主备两个，主进程挂了立马通过 zookeeper 感知到切换到备用进程。

 

Zookeeper 假死脑裂

 

该问题就是服务集群因为网络震荡导致的多主多从问题，解决方案就是设置服务切换的超时时间，但也同时会导致无法达到高可用的要求。

 

 

 

 

Eureka和zookeeper的区别？

 

首先他们都是服务注册和发现的功能，cloud一般选择eureka作为注册中心，dubbo一般选择zookeeper作为注册中心。基于CAP原则，eureka是AP原则，即可用性和分区容错性，zookeeper是CP原则，即强一致性和分区容错性。

 

CAP理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

 

Eureka是AP原则，高可用，分区容错，各个节点平等，一个挂掉其他正常保证服务

Zookeeper是CP原则 强一致 分区容错，故障时重新选择主节点，这期间服务不可用