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的调度。

https://www.cnblogs.com/xiaofei1208/p/7077733.html

http://colobu.com/2016/09/05/benchmarks-of-popular-rpc-frameworks/

https://blog.csdn.net/houshaolin/article/details/76408399

https://blog.csdn.net/oMaverick1/article/details/50767166

https://blog.csdn.net/mayp1/article/details/52026797

相关文章
相关标签/搜索