Diamond
Diamond主要提供持久配置的发布和订阅服务,最大特点是结构简单,稳定可靠。Diamond的主要使用场景是用来进行动态数据库切换与扩容, 进行一些业务系统运行时开关配置的推送。Diamond产品专注于高可用性,基于此在架构、容灾机制、数据获取模型上有一些与同类产品的不同之处。
Diamond结构非常简单,也属于是无单点的架构模型,如图1-1所示。
图1-1-Diamond架构模型
发布或者更新配置数据时,步骤如下:
-
写入MySql数据库
-
写本地磁盘
-
通知集群其他机器去数据库dump更新的数据
订阅方获取配置数据时,直接读取服务端本地磁盘文件,尽量减少对数据库压力。
这种架构用短暂的延时换取最大的性能和一致性,一些配置不能接受延时的情况下,通过API可以获取数据库中的最新配置。
容灾机制
Diamond作为一个分布式环境下的持久配置系统,有一套完备的容灾机制,数据存储在:数据库、服务端磁盘、客户端缓存目录以及可以手工干预的容 灾目录。客户端通过API获取配置数据按照固定的顺序去不同的数据源获取数据:容灾目录->服务端磁盘->客户端缓存。因此,面对如下情 况,Diamond均能很好的应对:
-
数据库主库不可用,可以切换到备库,Diamond继续提供服务
-
数据库主备库全部不可用,Diamond通过本地缓存可以继续提供读服务
-
数据库主备库全部不可用,Diamond服务端全部不可用,Diamond客户端使用缓存目录继续运行,支持离线启动
-
数据库主备库全部不可用,Diamond服务端全部不可用,Diamond客户端缓存数据被删,可以通过拷贝备份的缓存目录到容灾目录下继续使用
综上所述,只有在同时碰到如下四个条件的情况下,客户端应用才无法启动: 数据库主备库全部不可用、Diamond服务端全部不可用、Diamond客户端缓存被清空、客户端没有备份的缓存文件。
长轮询改造
客户端采用推拉结合的策略在长连接和短连接之间取得一个平衡,让服务端不用太关注连接的管理,又可以获得长连接的及时性。
-
客户端发起一个对比请求到服务端,请求中包含客户端订阅的数据的指纹
-
服务端检查客户端的指纹是否与最新数据匹配
-
如果匹配,服务端持有连接
-
如果30秒内没有相关数据变化,服务端持有连接30秒后释放
-
如果30秒内有相关数据变化,服务端立即返回变化数据的ID
-
-
如果不匹配,立即返回变化数据的ID
-
客户端根据变化数据的ID去服务端获取最新的内容
Diamond通过这种多重容灾机制以及推拉结合的方式,让客户端逻辑尽量简单,而且高效稳定,使其成为名副其实的“钻石”。
容灾机制
diamond之所以表现的稳定可靠,除了架构简单之外,另一个重要原因是diamond具有一套完备的容灾机制,容灾机制涉及到client和server两部分,主要包括以下几个方面:
1、server存储数据的方式。
server存储数据是“数据库 + 本地文件”的方式,集群间的数据同步我们在之前的文章中讲过(请参考专题二的原理部分),client订阅数据时,访问的是本地文件,不查询数据库,这样即使数据库出问题了,仍然不影响client的订阅。
2、server是一个集群。
这是一个基本的容灾机制,集群中的一台server不可用了,client发现后可以自动切换到其他server上进行访问,自动切换在client内部实现。
3、client保存snapshot
client每次从server获取到数据后,都会将数据保存在本地文件系统,diamond称之为snapshot,即数据快照。当client下次启动发现在超时时间内所有server均不可用(可能是网络故障),它会使用snapshot中的数据快照进行启动。
4、client校验MD5
client每次从server获取到数据后,都会进行MD5校验(数据保存在response body,MD5保存在response header),以防止因网络故障造成的数据不完整,MD5校验不通过直接抛出异常。
5、client与server分离
client可以和server完全分离,单独使用,diamond定义了一个“容灾目录”的概念,client在启动时会创建这个目录,每次主动获取数据(即调用getAvailableConfigInfomation()方法),都会优先从“容灾目录”获取数据,如果client按照一个固定的规则,在“容灾目录”下配置了需要的数据,那么client直接获取到数据返回,不再通过网络从diamond-server获取数据。同样的,在每次轮询时,都会优先轮询“容灾目录”,如果发现配置还存在于其中,则不再向server发出轮询请求。 以上的情形, 会持续到“容灾目录”的配置数据被删除为止。
根据以上的容灾机制,我们可以总结一下diamond整个系统完全不可用的条件:
1、数据库不可用。
2、所有server均不可用。
3、client主动删除了snapshot
4、client没有备份配置数据,导致其不能配置“容灾目录”。
同时满足以上4个条件的概率,在生产环境中是极小的。