disconf redis Zookeeper统一配置管理

disconf redis Zookeeper统一配置管理

1、杨旆概述 的介绍与部署使用 的配置管理场景与解决方案 百度的介绍与部署使用 关于配置管理的细节讨论 示例程序的演示介绍简介 是一个开放源代码的分布式协调服务，由知名互联网公司雅虎创建，是 的开源实现，由 的子项目发展而来，与2010年11月从项目中分离，正式成为的顶级项目。为分布式应用提供了高效且可靠的分布式协调服务，提供了诸如数据发布/订阅、负载均衡、分布式协调/通知、集群管理、统一命名服务、分布式锁和分

2、布式队列等分布式的基础服务。的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。介绍总体结构 服务自身组成一个集群(2n+1个服务允许n个失效)。服务有两个角色，一个是，负责写服务和数据同步，剩下的是，提供读服务，失效后会在中重新选举新的。客户端可以连接到每个，每个的数据完全相同。每个都和有连接，接受的

3、数据更新操作。记录事务日志和快照到持久存储。大多数可用，整体服务就可用。介绍数据结构 表现为一个分层的文件系统目录树结构，不同于文件系统的是，节点可以有自己的数据，而文件系统中的目录节点只有子节点。每个节点称为znode。介绍通知机制 支持一种Watch操作，可以在某个ZNode上设置一个来注册监听它关心的目录节点，并且Watch该ZNode上的变化。如果该ZNode上有相应的变化（数据改变、被删除、子目录节点增加删除），就会触发这个，把相应的事件通知给设置W

4、的。需要注意的是，中的是一次性的，即触发一次就会被取消，如果想继续Watch的话，需要客户端重新设置。介绍一致性保证顺序一致性：按照客户端发送请求的顺序更新数据。原子性：更新要么成功，要么失败，不会出现部分更新。单一性 ：无论客户端连接哪个，都会看到同一个视图。可靠性：一旦数据更新成功，将一直保持，直到新的更新。及时性：客户端会在一个确定的时间内得到最新的数据。介绍运用场景 应用配置集中到节点上，应用启动时主动获取，并在节点上注册一个，每次配置更新都会通知到应用。

5、分布式命名服务，创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用。不同的系统都监听同一个节点，一旦有了更新，另一个系统能够收到通知。介绍能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁。每个加入集群的机器都创建一个节点，写入自己的状态。监控父节点的用户会受到通知，进行相应的处理。离开时删除节点，监控父节点的用户同样会收到通知。（还有临时节点的概念，这些节点的生命周期依赖于创

6、建它们的是否活跃。结束时节点即被销毁。也由于这种特性，临时节点不允许有子节点。）部署和使用单节点安装模式wget http:/ xvf -3.4.7.tar.gzvi conf/zoo.====/home/xxx/=部署和使用bin/.sh查看运行状态bin/.sh by

7、sing :/home/xxx/-3.4.7/conf/zoo.: /.sh 部署和使用伪分布式集群安装 所谓伪分布式集群，就是在，在一台PC中，启动多个的实例。“完全分布式集群” 是每台PC，启动一个实例。这里在一台PC中，启动3个的实例。mkdir /home/xxx/zk1 mkdir /home/xxx/zk2 mkdir /home/xxx/zk3并在三个目录下新建myid文件，分别为“1”、“2”、“

8、3”。在conf目录下新建3个cfg文件，分别为zk1.cfg、zk2.cfg、zk3.部署和使用====/home/xxx/=.1=:2888:.2=:2889:.3=:2890:/.sh start zk1./.sh start zk2./.sh start zk3

9、.部署和使用客户端的使用bin/zkCli.sh – :2181查看/目录内容 ls /创建一个znode节点 /node、查看/node的数据信息 get /node修改数据 set /node xxxxx删除节点 /node退出客户端连接 部署和使用提供了java的开发包，客户端要连接 服务器可以通过创建 org… 的一个实例对象，然后调用这个类提供的接口来和服务器交互。创建一个与服务器的连

10、接( ,int , )创建节点 ( path, byte data, List acl, )判断是否存在节点Stat ( path, watch)删除节点void ( path, int )设置节点数据Stat ( path, byte data, int )配置管理简介

11、配置管理在某些场合称“数据发布与订阅”，顾名思义就是将数据发布到节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。场景描述 配置的管理在分布式应用环境中很常见，一个带配置的服务程序，部署在若干台机器上，如果配置发生了变化，接下去要进行的操作是停止所有机器上的该程序，修改每一台机器上该程序对应的配置文件。这个情景会有两个问题：第一，机器多了，逐个修改配置是一件不合理的运维；第二，配置一般是程序启动时读入的，所以配置修改后，程序应该重启。配置管理技术原理 服务器集群存储配置信息,在服

12、务器上创建一个保存数据的节点(创建节点操作);配置管理程序提供一个配置管理的UI界面或者命令行方式,用户通过配置界面修改服务器节点上配置信息(设置节点数据操作);分布式应用连接到集群上(创建客户端操作),监听配置信息的变化(使用获取节点数据操作,并注册一个)。当节点中的配置信息发生变化，所有监听该节点的客户端会收到的通知，然后从 获取新的配置信息动态加载到系统中。配置管理配置管理优势简单。配置统一管理，方便运维；用户只要修改配置,无需进行其他任何操作,配

13、置自动生效。可靠。服务集群具有无单点失效的特性,使整个系统更加可靠，即使 集群中的一台机器失效,也不会影响整体服务,更不会影响分布式应用配置信息的更新。实时。的数据更新通知机制,可以在数据发生变化后,立即通知给分布式应用程序,具有很强的变化响应能力。劣势最终一致性。配置的更新并不能做到强一致性，因为网络延迟等原因，只能做到最终一致性。介绍20简介 （ ）是百度前端技术部研发的基于的分布式配置管理平台，它是专

14、注于各种系统的配置管理的通用组件/通用平台。 使用，可以对所有业务系统的配置进行统一管理，远程对配置进行动态更新，免去重复发布的各种问题。 目前项目放在上，并开放源代码。介绍重要功能特点配置发布、更新统一化（云端存储、发布）:配置存储在云端系统，用户统一在平台上进行发布、更新配置。配置更新自动化：用户在平台更新配置，使用该配置的系统会自动发现该情况，并应用新配置。特殊地，如果用户为此配置定义了回调函数类，则此函数类会被自动调用。支持方式编程支持注解式编程，极简、低侵入的使用方式：通过简单的标注和极简单的代码撰写，即可完成复杂的配置分布式化。D

15、介绍模块信息-core: 分布式配置基础包模块。-: 分布式配置客户端模块, 依赖-core包。 用户程序使用它作为Jar包进行分布式配置编程。-tool: 分布式配置工具包disconf redis Zookeeper统一配置管理，依赖-core包, 目前使用不多，建议不使用。-web是统一的分布式配置管理平台。-web: 分布式配置平台服务模块, 依赖-core包。采用+纯HTML方式（前后端分离架构）实现。用户使用它来进行日常的分布式配置管理。介绍部署与使用分布式配

16、置Web平台服务部署安装Mysql（Ver 14.12 5.0.45, for -linux-gnu () using ）安装（–7.0.50）安装Nginx（nginx/1.5.3）安装 （-3.3.0）安装 Redis （2.4.5） (数据库配置) (Redis配置) (配置)

17、. (应用配置）放入home/work/dsp/-rd/-部署与使用配置文件目录=/home/work/dsp/-rd/-包生成目录=/home/work/dsp/-rd/ port -websh /.sh修改.xml文件，在Host结点下设定

18、t：部署与使用修改 nginx. :8015; 8081; ; /home/work/var/logs//.log; /home/work/var/logs//error.log; / root /home/work/dsp/-rd/war/html; if ($) max;

19、 /(api|) ; Host $; off; X-Real-IP $; X- $; http:/; 部署与使用客户端使用在您的 Maven POM 文件里加入： com.baidu. – 2.6.30细节讨论放在web平台上：只负责通

20、知，web负责新建、更新、存储配置，并为提供下载配置服务。放在上：负责通知与配置数据存储，并提供下载服务 ，web端管理一些非配置数据，只作为操作平台。放在web平台上职责分配明确，更能发挥各自的优势。放在web平台上：用数据库统一存储所有配置数据，可持久化存储非常方便管理，不管未来是迁移或者扩展之类都非常方便。放在上：不易管理，上的数据相比数据库不易管理。细节讨论放在web平台上：不管是启动还是更新时，均是从web上获取配置。启动时，会在ZK监控结点；更新时disconf redis，-web更新

21、ZK结点。web不会在ZK上新建结点。放在上：启动时，需要从上下载配置。因此必须使用web先写到上，否则启动时就无法使用最新配置。配置更新时，直接从获取最新配置。web必须统一的在上新建、更新结点。两种方案从数据获取方面没有什么区别细节讨论配置“不一致性读“ 问题应用系统的配置更新过程disconf redis，它会涉及到多个配置项的更新，它不是一个原子过程。如果在配置更新的过程中，应用程序去读取配置，这里可能存在些“时间窗口”，从而导致不一致性读问题。无论何种实现，要实现统一读取，避免“非一致

22、性”问题，就必须要对所有读取操作“统一化”。要实现统一读取，可以使用+AOP来实现。通过对配置的get方法做AOP切面，统一将用户的配置请求转发至 配置服务器里获取，从而实现统一读取。细节讨论解决方法一：在每次请求一开始时都复制系统里的所有配置缓存(复制过程要与配置更新Sync互斥)disconf redis，从而保证每次会话的数据的一致性。解决方法二：每次请求都绑定一个版本号，如果读取时版本号不一致则报错，需要重新请求。解决方法三：添加一个注解定义，标注它是需要强一制性的，每次会话读取时只复制这些强一制性配置(复制过程要与配置更新Sync互斥)。解决方法四：系统内保存有多个配置缓存层，读取时

23、统一读取某个版本的缓存。每当配置更新时，缓存层增加。第一种方法，代价太大；第三种还是需要用户主动关注，配置项多会增加负担；第二种相对于第四种来说会影响读取效率。所以第四种方法更好一些。示例程序Redis服务程序假设，我们的应用程序使用了Redis服务，我们将使用Jedis来进行编程，编程时，我们需要Redis的Host和Port，通常情况下，我们会把这两个参数放在配置文件里。准备一个配置文件 。撰写配置文件相应的配置文件类（get和set方法），添加托管。撰写一个连接Redis的类,用于使用Redis服务，实现了 , 两个接口，目的是在Bean初始化后进行Redis的连接,添加托管。添加的支持修改配置类示例程序修改 ，当配置更新时，支持Redis无需重启重新获得连接实例。实现 接口,实现()方法disconf redis Zookeeper统一配置管理，当配置更新时自动调用此方法。在web端上传配置文件，并启动redis服务程序。