zookeeper 负载均衡 概念笔记

(一)http://blog.csdn.net/zhangyu_ad/article/details/68942158


负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。常见互联网分布式架构如上,分为客户端层、反向代理nginx层、站点层、服务层、数据层。

现在使用最多的基于软件的负载均衡是Nginx和ZooKeeper: 
Nginx是著名的反向代理服务器,也被广泛的作为负载均衡服务器 
ZooKeeper是分布式协调服务框架,有时也被用来做负载均衡

那么它们有什么区别?我们还怎么选择

Nginx 
这里写图片描述

Nginx的负载均衡配置 
(1)把多个web server配置到nginx中,用户访问Nginx时,就会自动被分配到某个web server。 
(2)当网站规模变大,通常会进行
服务拆分,各个服务独立部署,通过远程调用方式协同工作。 
(3)为了保证稳定性,每个服务不会只使用一台服务器,也会作为一个集群存在,那么子集群也可以使用Nginx负载均衡。

ZooKeeper 
这里写图片描述

ZooKeeper的负载均衡模式 
(1)ZooKeeper作为一个服务的注册中心,每个服务在其注册中心登记,每台服务器知道自己是属于哪个服务,在服务器启动时,自己向所属服务进行登记 
(2)服务的调用者到注册中心里面查找:能提供所需服务的服务器列表,然后
自己根据负载均衡算法,从中选取一台服务器进行连接。 
(3)调用者取到服务器列表后,就可以缓存到自己内部,省得下次再取,当服务器列表发生变化,例如某台服务器宕机下线,或者新加了服务器,ZooKeeper会自动通知调用者重新获取服务器列表

使用场景

使用Nginx,随着整个系统的演进, 服务 的数量会 增加 、每个服务集群中的 服务器 数量会 增加 
这时就会有一些小麻烦,例如 
(1)配置维护的成本变高,因为节点太多 
(2)
单点故障的风险增加了,因为热点服务的访问量很高,如果这个服务集群内的负载均衡服务出现问题,这个服务将失效 
第一个问题,可以通过自己开发程序解决,但只是降低复杂度,并没有实际解决 
第二个问题,可以通过双机高可用部署方案,使用另一台nginx负载均衡服务器随时待命,只是成本较高

而ZooKeeper作为服务的注册和变更通知中心,解决了Nginx负载均衡方案带来的问题。 
但是ZooKeeper并
没有内置负载均衡策略,需要调用者自己实现,这个方案只是利用了ZooKeeper的树形数据结构、watcher机制等特性。



(二)http://www.cnblogs.com/zhangxh20/p/5456778.html

zookeeper本身是不提供负载均衡的策略,需要自己来实现,所以这里确切的说,是在负载均衡中应用到了zookeeper做集群的协调。

对于HTTP请求的负载均衡,成熟的解决方案是Nginx(或Haproxy) +keepalived。其中Niginx负责代理HTTP请求,通过某种均衡策略访问集群中的服务器,keepalived负责检测集群中的服务器运行情况(有故障的机器移除,机器恢复工作后重新加入)

而对于TCP层的负载均衡,比如用Apache Mina做的网络通信应用,上面那种方案明显不适合,因为网络通信客户端和服务端要保持长连接

所以要针对这种长连接做负载均衡,一般都是基于连接数这种均衡策略,也就是在第一次连接时,分配服务器IP时,取当前连接数最少的那台

集群中有几台服务器处于运行状态,每一台服务器当前连接的客户数量,最大连接数量,等等这些信息需要记录起来,然后每次做负载均衡时根据这些信息来做分配,一般首先想到的是把这些信息存放在数据库里

简单的做法就是服务器启动时,把数据库里相应的状态改为运行,有客户连接或断开时,把连接数做加数或减数运算。

当服务器关闭时,问题就来了:

1、服务器关闭,可能数据源也已经被关闭,没法操作数据库,该机器在数据库里一直处于运行状态

2、服务器宕机,这种问题就很致命,这是连关闭的程序都没有执行,更不用说能操作数据库了

解决的方式就是用zookeeper保存服务器的连接信息

1、当服务器启动时,往zookeeper的节点里写入数据(节点类型是临时节点)

2、当服务器关闭时,从zookeeper移除相应的节点数据

3、当服务器宕机,zookeeper因为没有检测到心跳,自动把该节点移除,并通知其他服务器,其他服务器得知该机器已宕机,在分配连接时,不会分配到这台机器上,这点也是标题说的在负载均衡中用到zookeeper的原因。

对比了一下保存在数据库那种方式,zookeeper其实就是一个具有通知功能的数据库,也就是它底下节点数据有变化时,会通知它的所有客户端(这里的客户端指的连接到zookeeper的服务器)。


  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
什么是Zookeeper Zookeeper是一个分布式开源框架,提供了协调分布式应用的基本服务,它向外部应用暴露一组通用服务——分布式同步(Distributed Synchronization)、命名服务(Naming Service)、集群维护(Group Maintenance)等,简化分布式应用协调及其管理的难度,提供高性能的分布式服务。ZooKeeper本身可以以单机模式安装运行,不过它的长处在于通过分布式ZooKeeper集群(一个Leader,多个Follower),基于一定的策略来保证ZooKeeper集群的稳定性和可用性,从而实现分布式应用的可靠性。 1、Zookeeper是为别的分布式程序服务的 2、Zookeeper本身就是一个分布式程序(只要有半数以上节点存活,zk就能正常服务) 3、Zookeeper所提供的服务涵盖:主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁、统> 一名称服务等 4、虽然说可以提供各种服务,但是zookeeper在底层其实只提供了两个功能: 管理(存储,读取)用户程序提交的数据(类似namenode中存放的metadata);  并为用户程序提供数据节点监听服务; Zookeeper集群机制 Zookeeper集群的角色: Leader 和 follower  只要集群中有半数以上节点存活,集群就能提供服务 Zookeeper特性 1、Zookeeper:一个leader,多个follower组成的集群 2、全局数据一致:每个server保存一份相同的数据副本,client无论连接到哪个server,数据都是一致的 3、分布式读写,更新请求转发,由leader实施 4、更新请求顺序进行,来自同一个client的更新请求按其发送顺序依次执行 5、数据更新原子性,一次数据更新要么成功,要么失败 6、实时性,在一定时间范围内,client能读到最新数据 Zookeeper数据结构 1、层次化的目录结构,命名符合常规文件系统规范(类似文件系统)    2、每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识  3、节点Znode可以包含数据和子节点(但是EPHEMERAL类型的节点不能有子节点) 节点类型  a、Znode有两种类型: 短暂(ephemeral)(create -e /app1/test1 “test1” 客户端断开连接zk删除ephemeral类型节点)  持久(persistent) (create -s /app1/test2 “test2” 客户端断开连接zk不删除persistent类型节点) b、Znode有四种形式的目录节点(默认是persistent ) PERSISTENT  PERSISTENT_SEQUENTIAL(持久序列/test0000000019 )  EPHEMERAL  EPHEMERAL_SEQUENTIAL c、创建znode时设置顺序标识,znode名称后会附加一个值,顺序号是一个单调递增的计数器,由父节点维护          d、在分布式系统中,顺序号可以被用于为所有的事件进行全局排序,这样客户端可以通过顺序号推断事件的顺序 Zookeeper应用场景 数据发布与订阅(配置中心) 发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到ZK节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新。例如全局的配置信息,服务式服务框架的服务地址列表等就非常适合使用。 负载均衡 这里说的负载均衡是指软负载均衡。在分布式环境中,为了保证高可用性,通常同一个应用或同一个服务的提供方都会部署多份,达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑,其中比较典型的是消息中间件中的生产者,消费者负载均衡。 消息中间件中发布者和订阅者的负载均衡,linkedin开源的KafkaMQ和阿里开源的 metaq都是通过zookeeper来做到生产者、消费者的负载均衡。这里以metaq为例如讲下: 生产者负载均衡:metaq发送消息的时候,生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息,因此metaq在运行过程中,会把所有broker和对应的分区信息全部注册到ZK指定节点上,默认的策略是一个依次轮询的过程,生产者在通过ZK获取分区列表之后,会按照brokerId和partition的顺序排列组织成一个有序的分区列表,发送的时候按照从头到尾循环往复的方式选择一个分区来发送消息。 消费负载均衡: 在消费过程中,一个消费者会消费一个或多个分区
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值