分布式数据同步解决方案

篇一：分布式数据库中数据同步 分布式数据库中数据同步

分布式数据库系统已不为大家陌生。该方案中描述了一个典型的分布式数据库系统，主要由几个部分组成: 数据中心、远程数据库、远程数据库与数据中心之间的数据交换。

从运行状态来看，分布式数据库系统又可分为“常连接”和“偶连接”两大类。顾名思义，“常连接”状态下的分布式数据库系统是指数据中心与远程数据库长期保持连通状态的部署环境。一般来说，这种系统对数据的实时性要求高，需要在实时或者近乎实时（比如秒级）的条件下保持数据中心与远程数据库的数据一致性。例如，全国铁路客票系统采用的多级分布式数据库系统中各远程数据库与数据中心的数据之间就需要实现接近实时的数据复制。

本方案中提到的是“偶连接”环境下的分布式数据库系统。该系统允许数据交换有一定延迟。通常，各远程数据库是数据中心的一个数据分区（即数据中心的一部分数据），数据中心与各远程数据库在平时不保持连接状态，且数据中心与各远程数据库均可能有数据变更。在需要的时候，各远程数据库与数据中心通过数据交换模块连接，交换必要的数据。下面针对组成该环境下分布式数据库系统的两个重要部分（远程数据库、数据交换）来阐述如何考虑选择合适的解决方案。 远程数据库

正如上面提到的，各远程数据库是数据中心的一个数据分区，运行在各个远程站点上。对于远程数据库，我们着重要考虑以下几个方面的问题:

1. 免维护。对类似于本方案中提出的运行在船舶上的各远程数据库来说，零维护是至关重要的。如果每个船舶都无需配备IT人员或DBA，这将节省大量成本。

2. 合理资源占用情况下的高性能。对于远程数据库来说，它一般不会像数据中心那样存储着海量数据，同时它的运算环境也远不如数据中心那样强大。很多远程数据库甚至部署在普通的PC上，而且有的远程应用并非需要多用户环境。这就要求各远程数据库在资源有限的环境下合理利用资源，规避可能造成的资源浪费，并且要获取企业级数据库的强大性能。 3. 安全性。数据安全是每个企业建立信息系统时首要考虑的问题。

数据库之间的数据交换

各远程数据库与数据中心的数据交换有以下几个方面的问题需要考虑:

1. 双向同步。一般情况下，不仅远程数据库的数据需要上传到数据中心，数据中心也可能有一些数据需要下载到各远程数据库中去。当然，在数据下载的过程中会涉及到如何调度，把不同的数据下载到不同的远程数据库的问题，即数据如何分区。

2. 异构数据库支持。我们需要考虑数据中心与各远程数据库是非同构数据库的情况。例如，数据中心运行着Oracle，而各远程数据库由于种种原因并不想采用Oracle，因而也需要进行数据同步的情况。

3. 增量同步。当系统运行了一段时间以后，数据中心和各远程数据库的数据都会发生膨胀，为了真正缩短网络连接时间，需要对数据进行摘取，选择自上次同步以来未同步的数据，组织它们进行上传下载。

4. 数据一致性。对于1:N的双向数据传输来说，要控制数据一致性并非一件易事。例如，数据中心将同一条数据下发到了两个不同的远程数据库，这两个远程数据库都对该数据进行了修改。继而，它们分别将数据同步到中心数据库去。那么，在这种情况下，我们如何去判断哪一条数据是真正有效的数据就成了问题。另外，数据一致性还体现在对传输失败的处理上。由于种种原因，我们并不能保证传输的过程不会失败。假设传输失败后，失败的数据该如何处理成了重要的问题。

5. 安全性。前面已经提及各远程数据库上的数据需要进行必要的保护，当然在数据中心与各远程数据库的数据传输链路上也必须对数据进行保护。只有安全的数据中心、安全的远程数据库再加上安全的数据交换渠道才能构成一个安全的分布式数据库系统

篇二：分布式环境下的数据一致性问题的方案讨论 分布式环境下的数据一致性问题的方案讨论

由于互联网目前越来越强调分布式架构，如果是交易类系统，面临的将会是分布式事务上的挑战。当然目前有很多开源的分布式事务产品，例如java JTA，但是这种解决方案的成本是非常高的，而且实现起来非常复杂，效率也比较低下。对于极端的情况：例如发布，故障的时候都是没有办法保证强一致性的。

首先，在目前的互联网应用中，我们通过一个比较常见的例子，让大家更深入的了解一下分布式系统设计中关于数据一致

性的问题。拿我们经常使用的功能来考虑吧，最近网购比较热门，就以京东为例的，我们来看看京东的一个简单的购物流程 用户在京东上下了一个订单，发现自己在京东的账户里面有余额，然后使用余额支付，支付成功之后，订单状态修改为支付成功，然后通知仓库发货。假设订单系统，支付系统，仓库系统是三个独立的应用，是独立部署的，系统之间通过远程服务调用。

订单的有三个状态：I:初始 P:已支付 W:已出库，订单金额100, 会员帐户余额200

如果整个流程比较顺利，正常情况下，订单的状态会变为I->P->W，会员帐户余额100，订单出库。 但是如果流程不顺利了呢?考虑以下几种情况

1：订单系统调用支付系统支付订单，支付成功，但是返回给订单系统数据超时，订单还是I(初始状态)，但是此时会员帐户余额100,会员肯定会马上找京东骂京东，为啥不给老子发货，我都付钱了

2：订单系统调用支付系统成功，状态也已经更新成功，但是通知仓库发货失败，这个时候订单是P(已支付)状态，此时会员帐户余额是100,但是仓库不会发货。会员也要骂京东。 3：订单系统调用支付系统成功，状态也已经更新成功，然后通知仓库发货，仓库告诉订单系统，没有货了。这个时候数据状态和第二种情况一样。对于情况一的问题，我们来分析一下解决方案，能想到的解决方案如下1 假设调用支付系统支付订单的时候先不扣钱，订单状态更新完成之后，在通知支付系统你扣钱

如果采用这种设计方案，那么在同一时刻，这个用户，又支付了另外一笔订单，订单价格200，顺利完成了整个订单支付流程，由于当前订单的状态已经变成了支付成功，但是实际用户已经没有钱支付了，这笔订单的状态就不一致了。即使用户在同一个时刻没有进行另外的订单支付行为，通知支付系统扣钱这个动作也有可能完不成，因为也有可能失败，反而增加了系统的复杂性。

2 订单系统自动发起重试，多重试几次，例如三次，直到扣款成功为止。这个看起来也是不错的考虑，但是和解决方案一样，解决不了问题，还会带来新的问题，假设订单系统第一次调用支付系统成功，但是没有办法收到应答，订单系统又发起调用，完了，重复支付，一次订单支付了200。

假设支付系统正在发布，你重试多少次都一样，都会失败。这个时候用户在等待，你怎么处理?

3 在第二种方案的基础上，我们先解决订单的重复支付行为，我们需要在支付系统上对订单号进行控制，一笔订单如果已经支付成功，不能在进行支付。返回重复支付标识。那么订单系统根据返回的标识，更新订单状态。

接下来解决重试问题，我们假设应用上重试三次，如果三次都失败，先返回给用户提示支付结果未知。假设这个时候用户重新发起支付，订单系统调用支付系统，发现订单已经支付，那么继续下面的流程。如果会员没有发起支付，系统定时(一分钟一次)去核对订单状态，如果发现已经被支付，则继续后续的流程。这种方案，用户体验非常差，告诉用户支付结果未知，用户一定会骂你，你丫咋回事情，我明明支付了，你告诉我未知。假设告诉用户支付失败，万一实际是成功的咋办。你告诉用户支付成功，万一支付失败咋办。

4 第三种方案能够解决订单和支付数据的一致性问题，但是用户体验非常差。当然这种情况比较可能是少数，可以牺牲这一部分的用户体验，我们还有没有更好的解决方案，既能照顾用户体验，又能够保证资金的安全性。

我们再回来看看第一种方案，我们先不扣钱，但是有木有办法让这一部分钱不让用户使用，对了，我们先把这一部分钱冻结起来。订单系统先调用支付系统成功的时候，支付系统先不扣钱，而是先把钱冻结起来，不让用户给其他订单支付，然后等订单系统把订单状态更新为支付成功的时候，再通知支付系统，你扣钱吧，这个时候支付系统扣钱，完成后续的操作。 看起来这个方案不错，我们仔细在分析一下流程，这个方案还存在什么问题，假设订单系统在调用支付系统冻结的时候，支付系统冻结成功，但是订单系统超时，这个时候返回给用户，告知用户支付失败，如果用户再次支付这笔订单，那么由于支付系统进行控制，告诉订单系统冻结成功，订单系统更新状态，然后通知支付系统，扣钱吧。如果这个时候通知失败，木有问题，反正钱都已经是冻结的了，用户不能用，我只要定时扫描订单和支付状态，进行扣钱而已。

那么如果变态的用户重新拍下来一笔订单,100块钱，对新的订单进行支付，这个时候由于先前那一笔订单的钱被冻结了，这个时候用户余额剩余100，冻结100，发现可用的余额足够，那就直接在对用户扣钱。这个时候余额剩余0，冻结100。先前那一笔怎么办，一个办法就是定时扫描，发现订单状态是初始的话，就对用户的支付余额进行解冻处理。这个时候用户的余额变成100，订单数据和支付数据又一致了。假设原先用户余额只有100，被冻结了，用户重新下单，支付的时候就失败了啊，的确会发生这一种情况，所以要尽可能的保证在第一次订单结果不明确的情况，尽早解冻用户余额，比如

10秒之内。但是不管如何快速，总有数据不一致的时刻，这个是没有办法避免的。

上面分析解决了第一个的问题以及相应的方案，发现在数据分布的环境下，很难绝对的保证数据一致性(任何一段区间)，但是有办法通过一种补偿机制，最终保证数据的一致性。 下面再分析一下第二个问题：订单系统调用支付系统成功，状态也已经更新成功，但是通知仓库发货失败，这个时候订单是P(已支付)状态，此时会员帐户余额是100,但是仓库不会发货。会员也要骂京东。

通过上面的分析，这个相对来说是比较简单的，我可以采取重试机制，如果发现通知仓库发货失败，就一致重试， 这里面有两种方式：

1 异步方式：通过类似MQ(消息通知)的机制，这个是异步的通知2 同步调用：类似于远程过程调用

对于同步的调用的方式，比较简单，我们能够及时获取结果;对于异步的通知，就必须采用请求，应答的方式进行，这一点在(关于分布式系统的数据一致性问题(一))里面有介绍。这里面就不再阐述。

来看看第三个问题：订单系统调用支付系统成功，状态也已经更新成功，然后通知仓库发货，仓库告诉订单系统，没有货了。这个时候数据状态和第二种情况一样。

我觉得这是一个很有意思的问题，我们还是考虑几种解决的方案1 在会员下单的时刻，就告诉仓库，我要你把货物留下来，

2 在会员支付订单时候，在支付之前检查仓库有没有货，如果没有货，就告知会员木有货物了

3 如果会员支付成功，这个时候没有货了，就会退款给用户或者等待有货的时候再发货

正常情况，京东的仓库一般都是有货的，所以影响到的会员很少，但是在秒杀和营销的时候，这个时候就不一定了，我们考虑假设仓库有10台iphone如果采用第一种方案，

1 在会员下单的时候，相当于库存就减1，那么用户恶意拍下来，没有去支付，就影响到了其他用户的购买。京东可以设置一个订单超时时间，如果这段时间内没有支付，就自动取消订单

2 在会员支付之前，检查仓库有货，这种方案了，对于用户体验不好，但是对于京东比较好，至少我东西都卖出去了。那些没有及时付款的用户，只能投诉了京东无故取消订单

3 第三种方案，这个方案体验更不好，而且用户感觉受到京东欺诈，但是对于京东来说，比第二种方案更有益，毕竟我还可以多卖出一点东西。

个人觉得，京东应该会采用第二种或者第三种方式来处理这类情况，我在微博上搜索了 “京东 无故取消订单”，发现果真和我预料的处理方式。不过至于这里的无故取消是不是技术上的原因我不知道，如果真的是技术上的原因，我觉得京东可以采用不同的处理方案。对于秒杀和促销商品，可以考虑第一种方案，大多数人都会直接付款，毕竟便宜啊，如果用户抢不到便宜的东西，抱怨当然很大了。这样可以照顾大多数用户的体验。对于一般的订单，可以采用第二种或者第三种方式，这种情况下，发生付款之后仓库没有货的情况会比较少，并且就算发生了，用户也会觉得无所谓，大不了退钱吗，这样就可以实现自己的利益最大化而最低程度的减少用户体验。

而铁道部在这个问题上，采用的是第一种方案，为什么和京东不一样，就是因为用户体验，如果用户把票都买了，你告诉我木有票了，旅客会杀人的。哈哈，不过铁道部不担心票卖不出去，第一种方案对他影响没有什么。

说了这么多，就是说 分布式环境下(数据分布)要任何时刻保证数据一致性是不可能的，只能采取妥协的方案来保证数据最终一致性。这个也就是著名的CAP定理。

在前面的文章中，介绍了关于分布式系统中数据一致性的问题，这一篇主要介绍CAP定理以及自己对CAP定理的了解。 CAP定理是2000年，由 Eric Brewer 提出来的。Brewer认为在分布式的环境下设计和部署系统时，有3个核心的需求，以一种特殊的关系存在。这里的分布式系统说的是在物理上分布的系统，比如我们常见的web系统。

这3个核心的需求是：Consistency，Availability和

Partition Tolerance，赋予了该理论另外一个名字 - CAP。 Consistency：一致性，这个和数据库ACID的一致性类似，但这里关注的所有数据节点上的数据一致性和正确性，而数据库的ACID关注的是在在一个事务内，对数据的一些约束。 Availability：可用性，关注的在某个结点的数据是否可用，可以认为某一个节点的系统是否可用，通信故障除外。 Partition Tolerance：分区容忍性，是否可以对数据进行分区。这是考虑到性能和可伸缩性。 篇三：数据同步系统设计 数据同步系统设计

摘要：在大型分布式应用中，经常需要对数据进行跨库或跨网络进行同步，出于资金或数据安全的方面考虑，不能过多依赖硬件或数据库进行同步，因此需要一种安全和高性能的数据同步解决方案，本文讨论了在不依赖数据库的基础上，实现数据同步的功能，并在性能和可扩展性上进行了优化。在分布式领域有个CAP理论，是说Consistency(一致性),

Availability(可用性), Parti(来自: 小 龙 文档网:分布式数据同步解决方案)tion tolerance(分区和容错) 三部分在系统实现只可同时满足二点，无法三者兼顾。 关键词：数据同步 分布式应用 CAP理论 一、应用场景

在大型分布式应用中，我们经常碰到在多数据库之间的数据同步问题，比如说一款游戏，在玩家注册后，可以马上登陆进入服务器，即数据在一个IDC更新，其它IDC立即可见。为了简化思路，我们这里称玩家注册的数据库(数据来源库)为中心库，同步目的地的数据库为分站库。 能做的

数据快速搬运到指定的IDC节点 数据传递过程中失败时，重新传递 监控数据传递流程 故障转移 数据版本控制 不能做的

不参与业务行为，业务操作只能通过注册的方式集成

不保存业务数据，不提供传递的业务的查询 二、系统要求

1.数据快速同步：除去网络原因，正常情况下从来源库同步到接收库的时间不超过300m