ZooKeeper场景实践:(2)集中式配置管理

1. 基本介绍

在分布式的环境中,可能会有多个对等的程序读取同样的配置文件,程序可以部署在多台机器上,如果配置采用文件的话,则需要为部署该程序的机器也部署一个配置文件,一旦要修改配置的时候就会非常麻烦,需要修改多个配置文件,而且容易产生不一致。

集中式配置管理的思路是,将配置数据集中发布到ZooKeeper的节点上,供订阅者动态获取数据。实现配置的集中式管理和动态更新。可以简单的理解为配置数据与程序分离。

2. 场景分析

(1).集中式配置管理

通常来说,大部分项目里面都有约定的配置文件格式,如ini,xml等。一般都会有对应的解析库类。这种解析库类的基本工作模式为:

  1. 读取文件(open)
  2. 解析文件(parse)
  3. 对外提供参数(get)

如果我们将文件的内容全部放到ZooKeeper的某个节点上.解析类将配置数据全部下载到本地,在完成解析的话,则可以用很小的改动就完成集中式配置管理的需求。

  1. 读取Zookeeper上对应路径的数据(read)
  2. 解析文件(parse)
  3. 对外提供参数(get)

(2).动态更新

动态更新是希望不重启程序就能够实时获取更新的配置。在单机环境中,这种配置数据通常会放在数据库中,修改配置只需要update数据库就可以了。

使用ZooKeeper的话,需要节点注册一个watcher,监视配置数据的是否有变化,一定出现变化,则调用新的解析类来重新解析配置数据。

个人认为这个特征使用Zookeeper可以实现,但是并不是所有配置都需要这个功能,这种比较适合对配置敏感,需要实时更新配置的情况。

3. 动手实践

这里我只实现了集中式配置管理的功能,没有实现动态更新,有需要的话你可以尝试自己实现。

由于之前曾经做个一个ini文件的库类解析,这里就直接拿过来改了。根据场景的分析,只需要修改open这个函数就ok了。

看下原来的open函数

/*读取文件名要改为地址和路径*/
int IniFile::open(const string &filename)
{
    release();
    fname_ = filename;
    IniSection *section = NULL;
    /*读取数据的方式需要修改*/
    FILE *fp = fopen(filename.c_str(),"r");

    if(fp == NULL ){
        return -1;
    }

    string line;
    string comment;

    //增加默认段
    section = new IniSection();
    sections_[""] = section;
    /*获取行的方式需要修改*/
    while(getline(line,fp) > 0){

        ...//省略单行的解析

    }

    fclose(fp);

    return 0;
}

我们有三个主要需要修改的地方,分别是是入参,fopen和getline。下面是修改后的open函数

/*修改入参,host为Zookeeper的ip及端口地址,filepath为配置数据的路径*/
int IniFile::open2(const string &host,const string &filepath)
{
    release();
    fname_ = filepath;
    IniSection *section = NULL;
    char fp[2048]={0};
    /*ZooKeeper来读取*/
    zkopen(host,filepath,fp,sizeof(fp));

    if(fp[0] == 0){
        return -1;
    }

    string line;
    string comment;

    //增加默认段
    section = new IniSection();
    sections_[""] = section;

    char *p = fp;
    /*调整getline的入参*/
    while(getline2(line,p) > 0){
          ...//省略单行的解析

    }

    return 0;
}

zkopen从Zookeeper的节点上读取数据,并保存到fp中。代码如下:

string zkopen(const string &host,const string &filepath,char *fp,int len)
{
    int timeout = 30000;
    char path_buffer[512];
    int bufferlen=sizeof(path_buffer);
    char conf_data[2048];
    int conf_len=sizeof(conf_data); 

    zoo_set_debug_level(ZOO_LOG_LEVEL_WARN); //设置日志级别,避免出现一些其他信息  

    zhandle_t* zkhandle = zookeeper_init(host.c_str(),NULL, timeout, 0, (char *)"Monitor Test", 0);  

    if (zkhandle ==NULL)
    {
        fprintf(stderr, "Error when connecting to zookeeper servers...\n");
        exit(EXIT_FAILURE);
    }  

    int ret = zoo_get(zkhandle,filepath.c_str(),0,conf_data,&conf_len,NULL);
    if(ret != ZOK){
        fprintf(stderr,"failed to get the data of path %s!\n",filepath.c_str());
        conf_data[0] = 0;
    }

    zookeeper_close(zkhandle); 

    strncpy(fp,conf_data,len);
    return conf_data;
}

接下来在对比下调用的变化。

原来的调用方式:

  /** read test **/
    IniFile ini;
    ini.open(g_filepath);

    //获取指定段的指定项的值
    int ret = 0;
    string db_name = ini.getStringValue("COMMON","DB",ret);
    string db_passwd = ini.getStringValue("COMMON","PASSWD",ret);

现在的调用方式:

  /** read test **/
    IniFile ini;
    ini.open2(g_host,g_filepath);/*仅此处有变化*/

    //获取指定段的指定项的值
    int ret = 0;
    string db_name = ini.getStringValue("COMMON","DB",ret);
    string db_passwd = ini.getStringValue("COMMON","PASSWD",ret);

由上可见,配置的改造还是很容易的,而且对程序的改动很小。

代码详见https://github.com/Winnerhust/ZooKeeper-Exam/tree/master/Config

5.小提示

需要注意一点,配置文件中通常有很多换行,而ZooKeeper的客户端命令行工作不支持字符转义。比如你要将一个配置文件test.ini的内容保存到Zookeeper上,文件内容如下。

[COMMON]

DB=mysql

PASSWD=root

你可能会在Zookeeper客户端上输入:

[zk: 172.17.0.36:2181(CONNECTED) 39] create /Conf/test.ini [COMMON]\nDB=mysql\nPASSWD=root\n

结果与我们希望的并不一样:

[zk: 172.17.0.36:2181(CONNECTED) 43] get /Conf/test.ini3[COMMON]\nDB=mysql\nPASSWD=root\n

Zookeeper并没有将字符串进行转义,所以不能用ZooKeeper客户端直接上传配置文件。因此在代码里我还增加了一个上传配置的功能。只需要将上一个参数-r就可以了。如将test.ini文件的内容上传到ZooKeeper:

cat test.ini | testcase -r -p/Conf/test.ini -s172.17.0.36:2181

时间: 2024-12-21 00:41:28

ZooKeeper场景实践:(2)集中式配置管理的相关文章

Zookeeper场景实践:(4)命名服务

1.基本介绍 命名服务是指通过指定的名字来获取资源或者服务的地址,提供者的信息.利用Zookeeper很容易创建一个全局的路径,而这个路径就可以作为一个名字,它可以指向集群中的集群,提供的服务的地址,远程对象等.简单来说使用Zookeeper做命名服务就是用路径作为名字,路径上的数据就是其名字指向的实体. 阿里巴巴集团开源的分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务,维护全局的服务地址列表.在Dubbo实现中: 服务提供者在启动的时候,向ZK上的指定节点/dubbo/${s

Zookeeper场景实践:(5)分布式通知/协调

1.基本介绍 通知/协调机制通常有两种方式. 系统调度模式:操作人员发送通知实际是通过控制台改变某个节点的状态,然后Zookeeper将这些变化发送给注册了这个节点的Watcher的所有客户端. 工作汇报模式:这个情况是每个工作进程都在某个目录下创建一个临时节点,并携带工作的进度数据.这样汇总的进程可以监控目录子节点的变化获得工作进度的实时的全局情况. 总的来说,利用Zookeeper的watcher注册和异步通知功能,通知的发送者创建一个节点,并将通知的数据写入的该节点:通知的接受者则对该节点

ZooKeeper场景实践:(7) 分布式锁

1.基本介绍 分布式锁是控制分布式系统之间同步访问共享资源的一种方式,需要互斥来防止彼此干扰来保证一致性.利用Zookeeper的强一致性可以完成锁服务.Zookeeper的官方文档是列举了两种锁,独占锁和共享锁.独占锁保证任何时候都只有一个进程能或者资源的读写权限.共享锁可以同时有多个读,但是同一时刻最多只能有一个写,读和写是互斥的. 2.场景分析 我们准备来实现互斥的锁,按照官网的思路,给定一个锁的路径,如/Lock,所有要申请这个锁的进程都在/Lock目录下创建一个/Lock/lock-的

ZooKeeper场景实践:(6)集群监控和Master选举

1. 集群机器监控 这通常用于那种对集群中机器状态,机器在线率有较高要求的场景,能够快速对集群中机器变化作出响应.这样的场景中,往往有一个监控系统,实时检测集群机器是否存活. 利用ZooKeeper有两个特性(读可监控,临时节点),就可以实现一种集群机器存活性监控系统: 1. 客户端在节点 x 上注册一个Watcher,那么如果x的子节点变化了,会通知该客户端 2. 创建EPHEMERAL类型的节点,一旦客户端和服务器的会话结束或过期,那么该节点就会消失 利用这两个特性,可以分别实现对客服端的状

1.分布式与集中式(ZooKeeper手记)

1. 集中式 特点由一台或多台主计算机组成的中心节点,数据集中存储在这个中间节点上,并且整个系统的所有业务单元都集中部署在这个中心节点上,系统所有功能均有其集中处理.简言之:终端或客户端只负责数据的输入输出,数据的存储和控制由主机来完成. 优点部署结构简单 缺点主机价格昂贵 2.分布式 特点一个硬件或软件的组件分布在不同的网络计算机上,彼此之间通过消息传递进行通信和协调. 特征 分布性分布式系统中的多台计算机都会在空间上随意分布,随时可以变化. 对等性多台计算机没有主从之分,都可以提供数据和服务

zookeeper场景

ZooKeeper典型应用场景一览 数据发布与订阅(配置中心) 发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到ZK节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新.例如全局的配置信息,服务式服务框架的服务地址列表等就非常适合使用.     1. 应用中用到的一些配置信息放到ZK上进行集中管理.这类场景通常是这样:应用在启动的时候会主动来获取一次配置,同时,在节点上注册一个Watcher,这样一来,以后每次配置有更新的时候,都会实时通知到订阅的客户端,从来达到获取

[hadoop][基本原理]zookeeper场景使用

1. 简介 zookeeper的特性决定他适用到某些场景非常合适,比如典型的应用场景: 1.集群管理(Group Membership) 2.统一命名服务(Name Service) 3.配置管理(Configuration Management) 4.共享锁(Locks) 5.队列管理 2.集群管理 在hadoop中主备节点的概念大家都应该不默认,比如HBase中,我们可以启动多个master节点,但是在某时刻只有一个主master,当这个主master节点退出后 其他的背master将会去争

LTE下行物理层传输机制(9)-集中式和分布式资源映射

LTE系统里,RB资源的动态调度是在eNB侧实现的,这里的"RB资源"实际上是特指虚拟RB(Virtual RB)而不是物理RB(Physical RB).VRB是MAC层在调度的时候使用的,属于逻辑上的概念,而PRB是物理层在实际映射RE资源的时候需要使用的,属于实际物理意义上的概念.VRB和PRB之间,存在着不同的映射关系:最简单的映射关系就是VRB的位置和PRB的位置是相同的,它们之间是一一对应的:另外一种复杂点的关系就是VRB和PRB并不是一一对应的,但是可以依赖某种特定的映射

生产环境ehcache迁移到集中式redis集群

原先项目中使用的ehcache分布式缓存,缺点是浪费内存,并且ehcache使用的是jvm进程的内存,因此内存使用很受限制. 还有就是业务中有时希望更新一个业务实体来使对应的缓存失效的场景,这种情况下如果对应业务实体缓存有多台机子那更新实体后更新缓存只能是其中一台,无法全部更新. 基于以上几点,项目希望切换成集中式缓存. 集中式缓存服务端架构是:网易LBS+Twemproxy+redis集群. 缓存客户端使用的是spring Data Redis. 由于Twemproxy代理本身不支持multi