Diamond主要提供持久配置的发布和订阅服务，最大特点是结构简单，稳定可靠。Diamond的主要使用场景是用来进行动态数据库切换与扩容，进行一些业务系统运行时开关配置的推送。Diamond产品专注于高可用性，基于此在架构、容灾机制、数据获取模型上有一些与同类产品的不同之处。
Diamond结构非常简单，也属于是无单点的架构模型，如图1-1所示。
图1-1-Diamond架构模型
发布或者更新配置数据时，步骤如下：
- 写入MySql数据库
- 写本地磁盘
- 通知集群其他机器去数据库dump更新的数据
订阅方获取配置数据时，直接读取服务端本地磁盘文件，尽量减少对数据库压力。
这种架构用短暂的延时换取最大的性能和一致性，一些配置不能接受延时的情况下，通过API可以获取数据库中的最新配置。
容灾机制
Diamond作为一个分布式环境下的持久配置系统，有一套完备的容灾机制，数据存储在：数据库、服务端磁盘、客户端缓存目录以及可以手工干预的容灾目录。客户端通过API获取配置数据按照固定的顺序去不同的数据源获取数据：容灾目录->服务端磁盘->客户端缓存。因此，面对如下情况，Diamond均能很好的应对：
- 数据库主库不可用，可以切换到备库，Diamond继续提供服务
- 数据库主备库全部不可用，Diamond通过本地缓存可以继续提供读服务
- 数据库主备库全部不可用，Diamond服务端全部不可用，Diamond客户端使用缓存目录继续运行，支持离线启动
- 数据库主备库全部不可用，Diamond服务端全部不可用，Diamond客户端缓存数据被删，可以通过拷贝备份的缓存目录到容灾目录下继续使用
综上所述，只有在同时碰到如下四个条件的情况下，客户端应用才无法启动： 数据库主备库全部不可用、Diamond服务端全部不可用、Diamond客户端缓存被清空、客户端没有备份的缓存文件。
1.4、Diamond双11准备与优化
长轮询改造
客户端采用推拉结合的策略在长连接和短连接之间取得一个平衡，让服务端不用太关注连接的管理，又可以获得长连接的及时性。
- 客户端发起一个对比请求到服务端，请求中包含客户端订阅的数据的指纹
- 服务端检查客户端的指纹是否与最新数据匹配
- 如果匹配，服务端持有连接
- 如果30秒内没有相关数据变化，服务端持有连接30秒后释放
- 如果30秒内有相关数据变化，服务端立即返回变化数据的ID
- 如果不匹配，立即返回变化数据的ID
- 客户端根据变化数据的ID去服务端获取最新的内容
Diamond通过这种多重容灾机制以及推拉结合的方式，让客户端逻辑尽量简单，而且高效稳定，使其成为名副其实的“钻石”。