之前讲到 eureka 可能有些同学 对这个没有了解那么 在这章做补充说明

1.Zookeeper:分布式应用程序的分布式协调服务

ZooKeeper是用于分布式应用程序的分布式，开放源代码协调服务。它公开了一组简单的原语，分布式应用程序可以基于这些原语来实现用于同步，配置维护以及
组和命名的更高级别的服务。他的设计易于编程，并使用了按照文件系统熟悉的目录数结构样式设置的数据模型。它以我们的java运行，并且具有java和c的绑定.

	在我们的服务设计中，协调服务很难做到。他们特别容易出现诸如比赛条件和死锁之类的错误。ZooKeeper背后的动机是减轻分布式应用程序从头开始实施协
调服务的责任.
	ZooKeeper允许分布式进程通过分享的分层命名空间相互协调，该命名空间的组织方式类似于标准文件系统。命名空间由数据寄存器（在ZooKeeper中
称为znodes）组成，他们类似于文件和目录。与设计用于存储的典型文件系统不同。ZooKeeper数据保留在内存中，这意味着ZooKeeper可以实现（高吞
吐量）和（低延迟数）.
ZooKeeper实施对高性能，高可用性，严格有序访问加以重视。ZooKeeper的性能方面意味着它可以在大型的分布式系统中使用.可靠性方面使它不会成为单
点故障。严格排序意味着可以在客户端上实现复杂的同步原语.
ZooKeeper已复制.像它协调的分布式进程一样，ZooKeeper本身也可以在称为集合的一组主机上进行复制.

组成ZooKeeper服务的服务器都必须彼此了解。他们维护内存的状态图像，以及持久存储中的事物日志和快照。只要大多数服务器可用，ZooKeeper服务将可用.
客户端连接到单个ZooKeeper服务器。客户端维护一个TCP连接，通过它发送请求，获取响应，获取监视事件并发送心跳.如果与服务器的TCP断开，则客户端将连
接到其他服务器.

ZooKeeper用一个反应所有ZooKeeper事务顺序的数字标记每个更新.后续操作可以使用该命令来实现高级别的抽象。
ZooKeeper在“读取为主”的工作负载中，它特别快.ZooKeeper应用程序可以在数千台计算机上运行，并且在读取比写入更为常见的情况下，其性能更佳，比例约为10：1；

数据模型和分层名称空间

ZooKeeper提供的名称空间与标准文件系统的名称空间非常相似.名称是由斜杠（/）分割的一系列路径元素.ZooKeeper名称空间中的每个节点都由路径标识.
ZooKeeper的层次命名空间

节点和短暂节点

与标准文件系统不同，ZooKeeper命名空间中的每个节点都可以具有与其关联的数据以及节点.就像拥有一个文件系统一样，该文件系统也允许文件成为目录。（ZooKeeper旨在存储协调数据：状态信息，配置，位置信息等，因此存储在每个节点上的数据通常很小，在字节到千字节范围内.）我们使用术语znode来明确表示在谈论ZooKeeper数据节点.
Znodes维护一个统计数据结构，其中包括用于数据更改，ACL更改和时间戳的版本号，以允许进行缓存验证和协调更新.znode的数据每次更改时，版本号都会增加.例如，每当客户端检索数据时，它也接收数据的版本.
原子地读取和写入存储在名称空间中每个znode上的数据。读取将获取与znode关联的所有数据字节，而写入将替换所有数据。每个节点都有一个访问控制列表（ACL），用于限制谁可以执行操作。

ZooKeeper还具有短暂节点的概念。只要创建znode的会话处于活动状态，这些znode就会存在。会话结束时，将删除znode。当您想实现[tbd]时，临时节点非常有用。

ZooKeeper支持监视的概念。客户端可以在znode上设置监视。znode更改时，将触发并删除监视。触发监视后，客户端会收到一个数据包，说明znode已更改。如果客户端与其中一个ZooKeeper服务器之间的连接断开，则客户端将收到本地通知。这些可以用于[tbd]。

ZooKeeper非常快速且非常简单。但是，由于其目标是作为构建更复杂的服务（例如同步）的基础，因此它提供了一组保证。这些是：

• 顺序一致性-来自客户端的更新将按照其发送顺序进行应用。
• 原子性-更新成功或失败。没有部分结果。
• 单个系统映像-无论客户端连接到哪个服务器，客户端都将看到相同的服务视图。
• 可靠性-应用更新后，此更新将一直持续到客户端覆盖更新为止。
• 及时性-确保系统的客户视图在特定时间范围内是最新的。

ZooKeeper的设计目标之一是提供一个非常简单的编程界面。因此，它仅支持以下操作：

• create：在树中的某个位置创建一个节点
• delete：删除节点
• ishave：测试某个位置是否存在节点
• getData：从节点读取数据
• setData：将数据写入节点
• getChildernNodeList：获取节点子节点的列表
• sync：等待数据传播
  复制的数据库是包含整个数据树的内存数据库。将更新记录到磁盘以确保可恢复性，并且将写入操作序列化到磁盘之后再将其应用于内存数据库。

每个ZooKeeper服务器都为客户端提供服务。客户端仅连接到一台服务器即可提交请求。读取请求从每个服务器数据库的本地副本提供服务。更改服务状态的请求（写请求）由协议协议处理。

作为协议协议的一部分，来自客户端的所有写请求都被转发到称为领导者的单个服务器。其余的ZooKeeper服务器（称为跟随者）从领导者接收消息建议并同意消息传递。消息传递层负责替换出现故障的领导者，并将跟随者与领导者同步。

ZooKeeper使用自定义的原子消息传递协议。由于消息传递层是原子层，因此ZooKeeper可以确保本地副本永远不会发散。当领导者收到写请求时，它将计算要应用写操作时系统的状态，并将其转换为捕获该新状态的事务。

用途

ZooKeeper的编程接口刻意简单。但是，有了它，您可以实现更高阶的操作，例如同步原语，组成员资格，所有权等。

性能

快照已写入OS驱动器。写请求是1K写，读是1K读。“服务器”指示ZooKeeper集合的大小，以及构成该服务的服务器的数量。大约还有30台其他服务器用于模拟客户端。ZooKeeper集成配置为使得领导者不允许来自客户端的连接。

可靠性

如果关注者失败并迅速恢复，则ZooKeeper能够在失败的情况下维持高吞吐量。但是，也许更重要的是，领导者选举算法允许系统恢复得足够快，以防止吞吐量大幅下降。根据我们的观察，ZooKeeper只需不到200毫秒即可选出新的领导者。第三，随着关注者的恢复，ZooKeeper能够在开始处理请求后再次提高吞吐量。

Dubbo 容错模式

Dubbo默认提供了6种容错模式，默认为Failover Cluster。如果这6种模式不能满足实际需求，还可以自行扩展。这也是Dubbo的强大之处，几乎所有的功能都提供了插拔式的扩展。

• Failover Cluster，失败自动切换。当服务调用失败后，会切换到集群中的其他机器进行重试，默认次数为2，通过属性retries=2可以修改次数，但是重试次数的增加会带来更长的延迟。这种容错模式通常用于读操作，因为事务型操作会带来数据重复性问题。
• Failfast Cluster, 快速失败，当服务调用失败后，立即报错，也就是只发起一次调用。通常用于一些幂等的读操作，比如新增数据，因为当服务调用失败时，很可能这个请求已经在服务器端处理成功，只是因为网络延迟导致响应失败，为了避免在结果不确定导致数据重复插入的问题，可以使用这种容错机制。
• Failsafe Cluster，失败安全。也就是出现异常时，直接忽略异常。
• Failback Cluster，失败后自动回复。服务调用出现异常时，在后台记录这条失败的请求时重发。这种模式适用于消息通知操作，保证这个请求一定发送成功。
• Forking Cluster，并行调用集群中的多个服务，只要其中一个成功就返回。可以通过forks=2来设置最大并行数。
• Broadcast Cluster，广播调用所有的服务提供者，任意一个服务报错则表示服务调用失败。这种机制通常用于通知所有的服务提供者更新缓存或者本地资源信息。

配置方式：@Service(cluster = “failfast”)

Dubbo 负载均衡

在Dubbo中提供了4种负载均衡策略，默认负载均衡策略是random

• Random LoadBalance,随机算法，可以针对性能较好的服务器设置较大的权重值，权重值越大，随机的概率也会越大。
• RoundRobin LoadBalance，轮询，按照公约后的权重设置轮询比例。
• LeastActive LoadBalance，最少活跃调用书，处理较慢的节点将会收到更少的请求。
• ConsistentHash LoadBalance，一致性hash。相同参数的请求总是发送到同一个服务提供者。
  配置方式：@Service(cluster = “failfast”,loadbalance = “roundrobin”)