zookeeper、dubbo、kafka简单了解

1 zookeeper如何实现高可用
1 zookeeper 多台构成集群实现高可用，有三种角色群首（leader），追随者（follower），观察者（observer）。
Leader作为整个ZooKeeper集群的主节点，负责响应所有对ZooKeeper状态变更的请求。它会将每个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的FIFO
Follower的逻辑就比较简单了。除了响应本服务器上的读请求外，follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交。，leader和follower构成ZooKeeper集群的法定人数，也就是说，只有他们才参与新leader的选举、响应leader的提议。
如果ZooKeeper集群的读取负载很高，或者客户端多到跨机房，可以设置一些observer服务器，以提高读取的吞吐量。Observer和Follower比较相似，只有一些小区别：首先observer不属于法定人数，即不参加选举也不响应提议；其次是observer不需要将事务持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间。

2 zookeeper如何实现负载均衡？
以前接触的负载均衡是通过VIP调度到各个节点。如：nginx+keepalived实现负载均衡和高可用。这个是直接在nginx配置文件中配置好了下面节点的IP：PORT，由nginx实现转发
zookeeper不是这样的，如三台服务构成zookeeper集群，是在服务生产者和服务消费的服务器上，
基本流程:
1) 服务提供者B启动到Zookeeper服务器处进行注册;
2) 服务消费者A启动时，请求Zookeeper服务器获取最新的B服务存活列表，并保存到本地缓存中;
3)A请求B服务器时，根据缓存中的B服务器列表，随机选取一个进行请求。

服务变动:
1) 当B出现异常或人工关闭不能提供服务时，Zookeeper服务器某个节点会探测到B节点的变化，更新本节点B服务器列表；
2) Zookeeper内部节点进行数据同步；
3) 服务消费者A监听到B服务列表的变化，更新本地缓存。

自动重发机制:
B服务挂掉到A缓存更新大约需要3-5s的时间（根据网络环境不同还需仔细测试）。为了保证服务的实时可用，A请求B发生异常时，需要根据服务消费报错信息，处理特定异常进行自动重发。

存在风险和问题
1) 服务发现速度慢的问题，上述描述服务延迟问题。
2) Zookeeper 作为服务发现存在的问题
在分布式系统领域有个著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）。
ZooKeeper是个CP的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。但是别忘了，ZooKeeper是分布式协调服务，它的职责是保证数据（注：配置数据，状态数据）在其管辖下的所有服务之间保持同步、一致；所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了，如果是AP的，那么将会带来恐怖的后果（注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗？）。而且，作为ZooKeeper的核心实现算法Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。
保存草稿

3 dubbo
Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。
dubbo能做什么？

1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

1. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

4 dubbo与zookeeper的关系

Dubbo建议使用Zookeeper作为服务的注册中心。
Dbbo是一个框架，用于服务间的调度，服务程序编写使用dubbo做接口，利用dubbo是实现服务服务之间还有zookeeper之间的通讯。

1） Zookeeper的作用：

    zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。当然也可以 通过硬编码的方式把这种对应关系在调用方业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。 zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码 的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了。

2） dubbo：

  是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。

  注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。

3）zookeeper和dubbo的关系：
Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。
引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。 其他特性还有Mast选举，分布式锁等。

5 kafka与zookeeper

1）Kafka把它的meta数据都存储在ZK上，所以说ZK是必要存在的，没有ZK没法运行Kafka；在老版本（0.8.1以前）里面消费段（consumer）也是依赖ZK的，在新版本中移除了客户端对ZK的依赖，但是broker依然依赖于ZK。

2）kafka是消息队列，zookeeper是服务的控制中心；消费者要访问服务，需要知道现在哪些生产者（对于消费者而言，kafka就是生产者）是可用的，就需要zk的调度。

http://blog.51cto.com/10676568/2133456