diamond专题（四）—— 容灾机制

大家好，本次为大家带来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个条件的概率，在生产环境中是极小的。

以上就是diamond的容灾机制，接下来的专题文章会带大家一起探究diamond的实现细节。

本文来源于"阿里中间件团队播客",原文发表时间" 2012-04-19"

跨系统数据一致性方案的思考（上） 本文主要意在总结沉淀现有问题解决经验过程，整理解决跨系统数据不一致问题的经验方法。 跨系统数据一致性，比较优秀的解决方案就是微服务化，不同应用系统采用统一数据源方式，这样可以有效避免数据一致性问题。 但是我们很多系统由于历史原因或者业务缘由，导致非服务化情况下，又要采取数据一致性方案。
核心特性—高可用性与容灾 在生产环境部署数据库时，往往会搭建多个副本（Replica），保证数据库集群的高可用性以及数据的持久性。传统的部署方式是一主一备，即主备间通过日志同步数据变更。但是主备复制存在先天性缺陷，以常见的MySQL半同步复制为例，一旦网络延迟超出阈值，同步就会退化到异步复制。此时如果主节点宕机，副本可能丢失已提交的数据，也就是常说的副本不一致。
服务的容灾与容错 服务容灾的解决方案就是冗余。多几个备份来切换。常用的有N+1容灾和两地三中心。N和中心实际上都是机房的意思。所谓中心就是数据中心。N是数据中心的电力配置部分。电力配置有市电和备用发动机供电，但是一般互联网公司是不支持备用发动机供电的。所以一般一个机房就是一个N。
跨地域场景下，如何解决分布式系统的一致性？ 跨地域，即常说的“异地双活”、“异地多活”中的异地概念。在业务发展较快的情况下，我们的服务便需要跨地域部署，以满足各区域就近访问和跨地域容灾等需求，在此过程中，不可避免会涉及到跨地域下的分布式一致性问题。由跨地域所带来的网络延迟问题，以及由于网络延迟而衍生的一系列问题，对于设计和构建一个跨地域分布式一致性系统是极大的挑战，业界有很多针对此问题的解决方案，都希望能解决跨地域场景下的一致性问题。