zookeeper_负载均衡

本文介绍zookeeper在集群负载均衡中的应用。

1、zookeeper的重要概念总结：

• zookeeper的数据是树形结构的，与linux目录结构是同样的，zeekeeper的每一个数据目录就是一个znode(节点)；
• zookeeper的全部服务器中的全部数据结构（树形结构）是彻底同样的，就是说我搭建一个zookeeper集群，集群里面全部的机器的数据同样的；
  
  

• zookeeper的做用：分布式，开源的分布式引用程序协调服务；

  也就是第三方，要你查数据的时候，能够返还给客户端，因此具体他是不知道干什么的
  （最重要的功能也就是替客户端保管数据，为客户提供数据的监听服务)

  内部本身设计了本身分布式内存数据库（用于保管数据）
• zookeeper底层其实就提供了两个功能：
• 一、管理（存储、读取）用户程序提交的数据； 二、为用户程序提交数据节点监听服务；
• zookeeper自己就是一个分布式程序（只要半数以上节点存活，Zookeeper就能正常服务）；                                                                                                                                                                                                                                                                      2、zookeeper在集群负载均衡中的应用
  
  
  上文中大体介绍了zookeeper的概念和应用，从上文中得知，zookeeper自己是不提供负载均衡的策略的，须要本身来实现，因此肯定的说：是在负载均衡中应用到了zookeeper作集群的协调；
  
  
  对于http请求的负载均衡，成熟的解决方案是Nginx(或者Haproxy)+keepalived。其中Niginx负责代理Http请求，经过某种负载均衡策略访问集群中的服务器，keepalived负责检测集群中的服务器运行状况（有故障的机器移除，机器回复工做后从新加入）；
  
  
  而对应TCP层的负载均衡，好比用Apache Mina作的网络通讯用用，上面这种方案明显不合适，由于网络通讯客户端和服务端要保持长链接， 因此针对这种长链接作的负载均衡，通常都是基于链接数这种均衡策略，也就是在第一次链接时，分配服务器ip,取当前链接数最少的那台服务器进行链接；
  
  
  集群中有几台服务器处于运行状态，每一台服务器链接的客户数量，最大链接数，等等这些信息都须要记录起来，而后每次作负载均衡时根据这些信息来作分配，通常首先想到的是将这些信息存放到数据库里。
  
  
  简单的作法就是
  
  
  服务器启动时，--------->把数据库里相应的状态改成运行;
  
  
  客户链接或者断开时----->把链接数作加数或者减数运算;
  
  
  可是，服务器关闭时，问题就出现了:
  
  
  一、服务器关闭，能够数据源也已经被关闭了，无法操做数据库，该机器在数据库里一直处于运行状态（数据库不能及时记录服务器状态。）
  
  
  二、服务器宕机，这种问题就很致命，这是链关闭的程序都没有执行，更不用说能操做数据库了。
  
  
  解决的方案就是用zookeeper保存服务器的链接信息：
  
  
  一、当服务器启动时，往zookeeper的节点里写入数据（节点的类型是临时节点）；
  
  
  二、当关闭服务器时，从zookeeper移除相应的节点数据；
  
  
  三、当服务器宕机，zookeeper由于没有检测到心跳，自动把该节点移除，并通知其余服务器，其余服务器得知该机器已宕机，在分配链接时，不会分配到这台机器上，这点也就是本文中所说，负载均衡中使用zookeeper的缘由。
  
  
  

对比了一下保存在数据库那种方式，zookeeper其实就是一个具备通知功能的数据库，也就是它底下节点数据有变化时，会通知它的全部客户端（这里的客户端指的链接到zookeeper的服务器）

更多技术资讯可关注：gzitcast