Diamond核心原理介绍

长破藏书

已于 2023-09-24 20:39:54 修改

阅读量1k

点赞数 1

文章标签：中间件 java

于 2023-09-24 20:38:47 首次发布

本文链接：https://blog.csdn.net/dddgg__/article/details/133251289

版权

Diamond的简单介绍

Diamond是阿里内部广泛使用的配置中心，提供了配置持久化管理能力和动态配置推送的服务，并且可以分环境的对配置进行管理，在阿里内部服务了很多的应用。

本文主要介绍Diamond的核心原理，不对Diamond的具体使用做过多介绍。

Diamond的架构

Diamond的核心应用架构如下图：

在Diamond的核心架构中，包含4个关键的组件：

Diamond-client

Diamond-client是Diamond的客户端，一般包含在Diamond的SDK内，会被集成到需要引入Diamond的应用中。Diamond-client为应用提供了服务接口，并负责与地址服务器和Diamond-server建立连接，可以动态获取和接受配置信息。正是因为Diamond-client的存在，应用才能方便简单的使用Diamond配置管理的能力。

地址服务器（HTTP-Server）

地址服务器中储存了Diamond—server的地址列表，Diamond-client可以通过域名 jmenv.tbsite.net 访问地址服务器，获取Diamond-server的地址列表。

在应用刚启动时，Diamond-client并不知道Diamond-server的地址，需要先访问地址服务器，获取最新的Diamond-server地址列表，再选择列表中的某台服务器进行访问，获取配置信息。为了防止因地址服务器宕机，无法连接到Diamond-server，Diamond-client会将获取到的地址列表保存在本地，并定时的访问地址服务器，获取最新的地址列表并更新本地。当地址服务器宕机时，Diamond-client会通过本地的地址服务器去访问Diamond-server拉取配置。

地址服务的存在，为Diamond提供了服务发现能力，使得可以方便地对Diamond-server进行运维管理，Diamond-server集群服务器的扩容、缩容、上线、下线对于应用来说是无感知透明的。

Diamond-server服务器

Diamond-server服务器一般是集群部署，是Diamond的核心服务。Diamond-server负责将用户的配置内容存储在Mysql数据库中，同时在Diamond-server的服务器磁盘和缓存中也会保存配置的内容。Diamond的核心能力就是管理用户的配置内容并向Diamond-client提供动态的配置推送服务。

因为Diamond-server是集群部署的，因此彼此之间通过特定的机制同步增量数据。但Diamond-server只保证数据的最终一致性，不保证强一致性，即CAP中，只保证AP。

但在Diamond应用的场景中，配置的更新被看作是低频率事件（一般要求1分钟不超过1次），配置的数据量也不应该太大（100KB以内），在这样的场景下，数据的最终一致性已经基本可以满足所有应用的要求。

Mysql持久化数据库

Diamond的配置内容通过Mysql数据库进行存储，这是Diamond可以对配置进行持久化管理的基础。一般采用“一主库两备库”的部署方式，保证数据的安全。

Diaond如何保证可靠性

Diamond的容灾机制

Diamond能够保证配置的可靠性，建立在Diamond有一套非常完善的容灾机制。

应用的配置数据会被Diamond存储在4个地方：

Diamond-server的服务器磁盘中；
MySQL主备库中；
Diamond-client的缓存；
Diamond-client的本地容灾目录（本地磁盘）中。

具体来说Diamond可以在如下的场景中保证配置管理的可用能力：

mysql主库不可用时，启用备库后，继续提供配置读、写服务。
mysql主备库都不可用时，通过服务端缓存，继续提供配置读服务。
mysql主备库、diamond-server集群整体不可用时，客户端可以借助缓存目录继续使用配置读服务，借助容灾目录使用配置写服务。

因此Diamond的容灾能力非常强悍，只有以上提到的地方都挂了，才会导致Diamond的配置服务不可用，但这是极小的概率，可以认为不可能发生。

在平时，应用获取配置的优先级是：Diamond-client缓存 -> Diamond-server -> 本地容灾。

应用获取配置的优先级是：Diamond-client缓存 -> Diamond-server -> 本地容灾。

优先获取Diamond-client缓存是为了降低Diamond-server服务器的压力和负载，其次从Diamond-server的缓存中获取配置而不直接访问数据库，是为了防止大量应用的流量把数据库打挂了。如果Diamond-server都不能用了，只能使用本地容灾目录中的配置了，但是配置可能不是最新的（Diamond-server的最新配置可能还来不及推送到本地容灾目录中，Diamond-server就挂了）。

Diamond如何保证高可用

引入cache

为了提高系统的吞吐率和响应性能，使用cache是比较常见的方案，因为cache可以避免对磁盘的缓慢访问，直接在内存中读取和写入数据，避免了频繁访问磁盘需要让操作系统在内核态和用户态之间进行频繁转换，这个转换过程多了很多的额外开销。而且内存和磁盘的访问速率一般也有数量级的差距。

在Diamond中，在Diamond-client和Diamond-server中都引入了缓存，这样可以降低应用频繁的访问服务器和Mysql数据库带来的性能问题。

CAP抉择中选择了AP

分布式系统必须在CAP中进行抉择，最多只能兼容其中的两项。Diamond选择了AP，即保证可用性和分区容忍性，而对于数据一致性只保证最终一致性。这样使得Diamond的在任何时候都可以对外提供服务，不会因为数据不一致、或者某个机器宕机导致的服务停用。

基于推模型的客户端长轮询

动态地向应用推送最新的配置信息，是Diamond的核心能力。从自然的角度讲，我们会想到使用TCP的长连接来实现向Diamond推送最新的配置信息，但是海量的应用会带来海量的TCP长连接，这对Diamond-server服务器来说是非常大的连接负担。Diamond没有使用传输层的TCP长连接来实现配置信息的动态推送，而是使用了基于“请求-响应”的HTTP协议来提供服务。Diamond团队曾经考虑过两种方案来实现：

基于HTTP短轮询的“拉模型”

短轮询我认为应该理解为轮询时，建立的连接时间短。短轮询由client发起，每隔一段的时间向服务器发起请求，询问配置是否更新，server服务器要立刻做出响应，告知配置的更新情况，如果更新了配置，server需要将最新的配置返回给client，这有点像client向server“拉”配置。

这会导致一个问题，一般配置更新的频率不高，会导致99%以上的轮询都是无用的，因为配置没有更新。但是每次轮询都需要建立新的HTTP连接，这样造成了很大的开销。

基于HTTP长轮询的“推模型”

为了解决减少无用轮询的问题，Diamond实际的方案是基于HTTP长轮询的“推模型”。和短轮询的比较，长轮询的应该理解为HTTP连接建立的时间长。短轮询由client发起，向服务器发起请求，询问配置是否更新，server收到请求后，如果配置没有更新，不会立即响应（如果更新了自然是会立即响应），而是将这个请求“挂起”一段时间，不去理会，等发生了某些事件，比如配置更新了或者连接的超时时间到了，server才会做出响应。这样就比避免了client很多的请求都是无用的，减少了创建、销毁HTTP请求的消耗。

大家可能会有问题，“长轮询和长连接有什么区别”？

这里做简要解释，长连接是基于传输层的TCP连接通道，具备实时的双向传输能力，建立连接的过程中，就算server不回应，client也可以源源不断的向server发消息，连接不能“挂起”，需要一直保持连接状态，TCP连接多了，会对server造成很大连接负担。

长轮询是基于HTTP的连接，必须是请求—响应模式的，server可以不做出响应，将HTTP连接“挂起”，去处理其他的HTTP连接，对服务器的负担较小，因为server可以处理其他的HTTP请求，不用一直关注被“挂起”的HTTP连接。

实质上Diamond即支持由server向client动态的推送最新的配置，也支持client如果有需要可以主动从server拉最新的配置，非常灵活，可以适应各种业务场景。