‘壹’ 保证分布式系统数据一致性的6种方案
编者按 ：本文由“高可用架构后花园”群讨论整理而成。
有人的地方，就有江湖
有江湖的地方，就有纷争
在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？
具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。
在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。
强一致
弱一致性
最终一致性
在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如 MySQL 主从同步）又有一定区别，群友的讨论分成以下 6 种解决方案。
业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说，则可以将服务 A、B、C 整合为一个服务 D 给业务，这个服务 D 再通过转换为本地事务的方式，比如服务 D 包含本地服务和服务 E，而服务 E 是本地服务 A ~ C 的整合。
优点： 解决（规避）了分布式事务。
缺点： 显而易见，把本来规划拆分好的业务，又耦合到了一起，业务职责不清晰，不利于维护。
由于这个方法存在明显缺点，通常不建议使用。
此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。
消息日志方案的核心是保证服务接口的幂等性。
考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。
eBay 方式的主要思路如下。
Base：一种 Acid 的替代方案
此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章，是一篇解释 BASE 原则，或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。
如果 ACID 为分区的数据库提供一致性的选择，那么如何实现可用性呢？答案是
BASE (basically available, soft state, eventually consistent)
BASE 的可用性是通过 支持局部故障 而不是系统全局故障来实现的。下面是一个简单的例子：如果将用户分区在 5 个数据库服务器上，BASE 设计鼓励类似的处理方式，一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法，不过它确实可以带来更高的可感知的系统可用性。
文章中描述了一个最常见的场景，如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。
文中提出了一个经典的解决方法，将主要修改操作以及更新用户表的消息 放在一个本地事务 来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性， 增加一个更新记录表 updates_applied 来记录已经处理过的消息。
系统的执行伪代码如下
（点击可全屏缩放图片）
基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。
在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条操作记录到 updates_applied，事务执行成功之后再删除队列。
通过以上方法，达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。
随着业务规模不断地扩大，电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里，现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。
拆分首先要面临的是什么呢？
最开始的单体应用所有功能都在一起，存储也在一起。比如运营要取消某个订单，那直接去更新订单表状态，然后更新库存表就 ok 了。因为是单体应用，库在一起，这些都可以在一个事务里，由关系数据库来保证一致性。
但拆分之后就不同了，不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库，而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了，而不是直接去操作库。这就涉及一个‘ 分布式事务 ’的问题。
分布式事务有两种解决方式
1. 优先使用异步消息。
上文已经说过，使用异步消息 Consumer 端需要实现幂等。
幂等有两种方式， 一种方式是业务逻辑保证幂等 。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。
另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现 。对于 procer 端在业务数据库的同实例上放一个消息库，发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。
2. 有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。 这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。
比如 A 同步调用 B，C。A 本地事务成功的时候更新本地事务记录状态，B 和 C 同样。如果有一次 A 调用 B 失败了，这个失败可能是 B 真的失败了，也可能是调用超时，实际 B 成功。则由一个中心服务对比三方的事务记录表，做一个最终决定。假设现在三方的事务记录是 A 成功，B 失败，C 成功。那么最终决定有两种方式，根据具体场景：
对 b 场景做一个特殊说明：比如 B 是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候库存已经变为 0，无法重试成功，这个时候只有回滚 A 和 C 了。
那么可能有人觉得在业务库的同实例里放消息库或事务记录库，会对业务侵入，业务还要关心这个库，是否一个合理的设计？
实际上可以依靠运维的手段来简化开发的侵入，我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库，通过框架层（消息的客户端或事务 RPC 框架）透明的在背后操作这个库，业务开发人员只需要关心自己的业务逻辑，不需要直接访问这个库。
总结起来，其实两种方式的根本原理是类似的，也就是 将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性 。
交易创建的一般性流程
我们把交易创建流程抽象出一系列可扩展的功能点，每个功能点都可以有多个实现（具体的实现之间有组合/互斥关系）。把各个功能点按照一定流程串起来，就完成了交易创建的过程。
面临的问题
每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢？比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理？再比如锁券成功了，但是扣减库存失败了，该如何处理？
方案选型
服务依赖过多，会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务，9 个都执行成功了，最后一个执行失败了，那么是不是前面 9 个都要回滚掉？这个成本还是非常高的。
所以在拆分大的流程为多个小的本地事务的前提下，对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。
消息通知往往不能保证 100% 成功；且消息通知后，接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决；后者可以选用事务消息来保证。
所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中，锁券和扣减库存是这样的两个典型场景。
要保证多个系统间数据一致，乍一看，必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升；在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时的最终一致性。
我们在交易创建流程中， 首先创建一个不可见订单 ，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。
业界常用的还有支付宝的一种 xts 方案，由支付宝在 2PC 的基础上改进而来。主要思路如下，大部分信息引用自官方网站。
分布式事务服务简介
分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 JAR 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。
核心特性
传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下，ACID 模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题，但是 2PC 是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模达到千万级以上时，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。基于此，我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案，这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。
简单的说，DTS 框架有如下特性：
以下是分布式事务框架的流程图
实现
与 2PC 协议比较
1. 电商业务
公司的支付部门，通过接入其它第三方支付系统来提供支付服务给业务部门，支付服务是一个基于 Dubbo 的 RPC 服务。
对于业务部门来说，电商部门的订单支付，需要调用
从业务规则上需要同时保证业务数据的实时性和一致性，也就是支付成功必须加积分。
我们采用的方式是同步调用，首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付，由积分平台提供增加与回撤接口。
具体的流程是先调用积分平台增加用户积分，再调用支付平台进行支付处理，如果处理失败，catch 方法调用积分平台的回撤方法，将本次处理的积分订单回撤。
(点击图片可以全屏缩放)
2. 用户信息变更
分布式服务对衍生的配套系统要求比较多，特别是我们基于消息、日志的最终一致性方案，需要考虑消息的积压、消费情况、监控、报警等。
In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability.
英文版 ： http://queue.acm.org/detail.cfm?id=1394128
中文版： http://article.yeeyan.org/view/167444/125572
感谢李玉福、余昭辉、蘑菇街七公提供方案，其他多位群成员对本文内容亦有贡献。
本文编辑李玉福、Tim Yang，转载请注明来自@高可用架构
‘贰’ 集中式数据处理和分布式数据处理的优缺点
集中式数据处理优点：
1、部署结构简单。
2、数据容易备份，只需要把中央计算机上的数据备份即可。
3、不易感染病毒，只要对中央计算机做好保护，终端一般不需要外接设备，感染病毒的几率很低。
4、总费用较低，中央计算机的功能非常强大，终端只需要简单、便宜的设备。
缺点：
1、中央计算机需要执行所有的运算，当终端很多时，会导致响应速度变慢。
2、如果终端用户有不同的需要，要对每个用户的程序和资源做单独的配置，在集中式系统上做起来比较困难，而且效率不高。
分布式数据处理优点：
1、分布式网络中的每台机器都能存储和处理数据，降低了对机器性能的要求，所以不必购买昂贵的高性能机器，这大大降低了硬件投资成本。
2、扩展性极佳。在当前系统存储或计算能力不足时，可以简单地通过增加廉价PC机的方式来增加系统的处理和存储能力。
3、处理能力极强。庞大的计算任务可以在合理分割后由分布式网络中的机器并行地处理
缺点
1、计算程序全负荷运行时仍会对计算机的各个部件造成一定压力。
2、对项目方来说，参加分布式计算的志愿者不是项目方自己的人员，不是全体可信任，因此必须引入一定的冗余计算机制，才能防止计算错误、恶意作弊等。
(2)分布式数据处理怎样实现其准确性扩展阅读
分布式计算为信息不只分布在一个软件或计算机上，而是分布于多个软件上，可以用多台或一台计算机同时运行若干个软件，通过网络实现信息的共享。与其他算法相比，分布式算法有明显的优势：
1、共享资源更加方便。
2、能够实现计算负载的平衡，用多台计算机同时处理任务。
3、可以根据实际需要合理选择适当的计算机运行该程序。计算机分布式计算的灵魂是平衡负载和共享资源。分布式计算具有高效、快捷、准确的优势
‘叁’ 什么是分布式数据库系统分布式数据库系统有哪些特点
分布式数据库是一个逻辑数据库，它的物理数据库在地理位置上分布在多个数据库管理系统的计算机网络中，这些数据库系统构成了分布式的数据库管理系统。在分布式数据库管理系统中，每台计算机上的用户在访问数据库时并不感到他使用的数据在物理上不存储在自己的计算机中，而是由分布式数据库系统由网络从其它机器中传输过来。因此，对每一用户来说，看到的都是一个统一的概念模式。分布式数据库系统的主要特点是：（1）具有较高的可靠性，当系统中一台机器发生故障时、不会导致整个系统的破坏。当故障排除后，分布式数据库系统可将故障期间的数据库加以恢复修改。（2）分散了工作负荷，使大量的处理均匀分担。（3）便于实现系统的扩充。分布式数据库系统是计算机通讯和数据库技术相结合的产物，是非常有代表性的数据库技术发展方向之一。
‘肆’ 在设计一个可靠好的分布式数据库时，应该考虑哪些问题
在设计分布式数据库时，应特别考虑如下几个方面的问题：
1. 数据保存 (存储分段/复制，横向/纵向表分区);
2. 目录管理(catalog management): 命名，数据独立性
3. 查询处理(基于代价的调优， 半合并)4. 数据更新(同步/异步)
‘伍’ 分布式存储中，怎样使用paxos算法保证数据的一致性
在分布式系统中，我们经常遇到多数据副本保持一致的问题，在我们所能找到的资料中该问题讲的很笼统，模模糊糊的，把多个问题或分类糅合在一起，难以理解。在思考和翻阅资料后，通俗地把一致性的问题可分解为2个问题：
1、任何一次修改保证数据一致性。
2、多次数据修改的一致性。
在弱一致性的算法，不要求每次修改的内容在修改后多副本的内容是一致的，对问题1的解决比较宽松，更多解决问题2，该类算法追求每次修改的高度并发性，减少多副本之间修改的关联性，以获得更好的并发性能。例如最终一致性，无所谓每次用户修改后的多副本的一致性及格过，只要求在单调的时间方向上，数据最终保持一致，如此获得了修改极大的并发性能。
在强一致性的算法中，强调单次修改后结果的一致，需要保证了对问题1和问题2要求的实现，牺牲了并发性能。本文是讨论对解决问题1实现算法，这些算法往往在强一致性要求的应用中使用。
解决问题1的方法，通常有两阶段提交算法、采用分布式锁服务和采用乐观锁原理实现的同步方式,下面分别介绍这几种算法的实现原理。
两阶段提交算法
在两阶段提交协议中，系统一般包含两类机器（或节点）：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与者（participants，cohorts或workers），一般包含多个，在数据存储系统中可以理解为数据副本的个数。两阶段提交协议由两个阶段组成，在正常的执行下，这两个阶段的执行过程如下所述：
阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）。
在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
阶段2：提交阶段（commit phase）。
在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。
举个例子：A组织B、C和D三个人去爬长城：如果所有人都同意去爬长城，那么活动将举行；如果有一人不同意去爬长城，那么活动将取消。用2PC算法解决该问题的过程如下：
首先A将成为该活动的协调者，B、C和D将成为该活动的参与者。
阶段1：A发邮件给B、C和D，提出下周三去爬山，问是否同意。那么此时A需要等待B、C和D的邮件。B、C和D分别查看自己的日程安排表。B、C发现自己在当日没有活动安排，则发邮件告诉A它们同意下周三去爬长城。由于某种原因，D白天没有查看邮件。那么此时A、B和C均需要等待。到晚上的时候，D发现了A的邮件，然后查看日程安排，发现周三当天已经有别的安排，那么D回复A说活动取消吧。
阶段2：此时A收到了所有活动参与者的邮件，并且A发现D下周三不能去爬山。那么A将发邮件通知B、C和D，下周三爬长城活动取消。此时B、C回复A“太可惜了”，D回复A“不好意思”。至此该事务终止。
两阶段提交算法在分布式系统结合，可实现单用户对文件（对象）多个副本的修改，多副本数据的同步。其结合的原理如下：
1、客户端（协调者）向所有的数据副本的存储主机（参与者）发送：修改具体的文件名、偏移量、数据和长度信息，请求修改数据，该消息是1阶段的请求消息。
2、存储主机接收到请求后，备份修改前的数据以备回滚，修改文件数据后，向客户端回应修改成功的消息。 如果存储主机由于某些原因（磁盘损坏、空间不足等）不能修改数据，回应修改失败的消息。
3、客户端接收发送出去的每一个消息回应，如果存储主机全部回应都修改成功，向每存储主机发送确认修改的提交消息；如果存在存储主机回应修改失败，或者超时未回应，客户端向所有存储主机发送取消修改的提交消息。该消息是2阶段的提交消息。
4、存储主机接收到客户端的提交消息，如果是确认修改，则直接回应该提交OK消息；如果是取消修改，则将修改数据还原为修改前，然后回应取消修改OK的消息。
5、 客户端接收全部存储主机的回应，整个操作成功。
在该过程中可能存在通信失败，例如网络中断、主机宕机等诸多的原因，对于未在算法中定义的其它异常，都认为是提交失败，都需要回滚，这是该算法基于确定的通信回复实现的，在参与者的确定回复（无论是回复失败还是回复成功）之上执行逻辑处理，符合确定性的条件当然能够获得确定性的结果哲学原理。
分布式锁服务
分布式锁是对数据被外界修改持保守态度，在整个数据处理过程中将数据处于锁定状态，在用户修改数据的同时，其它用户不允许修改。
采用分布式锁服务实现数据一致性，是在操作目标之前先获取操作许可，然后再执行操作，如果其他用户同时尝试操作该目标将被阻止，直到前一个用户释放许可后，其他用户才能够操作目标。分析这个过程，如果只有一个用户操作目标，没有多个用户并发冲突，也申请了操作许可，造成了由于申请操作许可所带来的资源使用消耗，浪费网络通信和增加了延时。
采用分布式锁实现多副本内容修改的一致性问题， 选择控制内容颗粒度实现申请锁服务。例如我们要保证一个文件的多个副本修改一致， 可以对整个文件修改设置一把锁，修改时申请锁，修改这个文件的多个副本，确保多个副本修改的一致，修改完成后释放锁；也可以对文件分段，或者是文件中的单个字节设置锁， 实现更细颗粒度的锁操作，减少冲突。
常用的锁实现算法有Lamport bakery algorithm （俗称面包店算法）， 还有Paxos算法。下面对其原理做简单概述。
Lamport面包店算法
是解决多个线程并发访问一个共享的单用户资源的互斥问题的算法。 由Leslie Lamport（英语：Leslie Lamport）发明。
Lamport把这个并发控制算法可以非常直观地类比为顾客去面包店采购。面包店只能接待一位顾客的采购。已知有n位顾客要进入面包店采购，安排他们按照次序在前台登记一个签到号码。该签到号码逐次加1。根据签到号码的由小到大的顺序依次入店购货。完成购买的顾客在前台把其签到号码归0. 如果完成购买的顾客要再次进店购买，就必须重新排队。
这个类比中的顾客就相当于线程，而入店购货就是进入临界区独占访问该共享资源。由于计算机实现的特点，存在两个线程获得相同的签到号码的情况，这是因为两个线程几乎同时申请排队的签到号码，读取已经发出去的签到号码情况，这两个线程读到的数据是完全一样的，然后各自在读到的数据上找到最大值，再加1作为自己的排队签到号码。为此，该算法规定如果两个线程的排队签到号码相等，则线程id号较小的具有优先权。
把该算法原理与分布式系统相结合，即可实现分步锁。
Paxos算法
该算法比较热门，参见WIKI，http://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95
Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。一个典型的场景是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中，是分布式计算中的重要问题。节点通信存在两种模型：共享内存(Shared memory)和消息传递(Messages passing)。Paxos算法就是一种基于消息传递模型的一致性算法。BigTable使用一个分布式数据锁服务Chubby，而Chubby使用Paxos算法来保证备份的一致性。
采用乐观锁原理实现的同步
我们举个例子说明该算法的实现原理。如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用前面的分布式锁服务机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。
乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。
操作员 A 此时将其读出（version=1 ），并从其帐户余额中扣除 $50（$100-$50 ）。
在操作员 A 操作的过程中，操作员B也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。
乐观锁机制与分布式系统相结合上， 我整理了伪代码如下：
obj 操作的目标
vlaue 修改的值
atom_update_ver 每个目标上的版本，每次修改该值递增
set( obj, value)
{
//从每个节点上取出修改前的对象版本
get original_ver = obj.atom_update_ver from each node;
//将值赋到每个节点的obj目标
set obj = value from each node;
//条件修改每个节点的obj版本，目标版本加一
//比较和修改操作是原子操作
result = (set obj.atom_update_ver = original_ver + 1
where original_ver + 1 > obj.atom_update_ver
for each node);
if(result == ok)
return set_ok;
else
return set(obj, value);//不成功递归修改
该算法未考虑节点下线、失效等问题，在后续我将分析采用乐观锁原理实现一致性算法，解决问题2、节点失效、通信失败等问题。
‘陆’ 如何解决分布式系统数据事务一致性问题
文探讨了在分布式系统中，如何基于业务方面的考量、将RESTful与MQ(消息中间件)结合、解决事务完整性/数据一致性问题的架构设计。
一、面向业务考量的最终一致性方案考虑
这里先举两个例子。
1、支付宝的“WS Transaction标准”尝试：
支付宝在他们的分布式系统中为解决事务完整性的问题，曾经尝试过WS Transaction标准，但是经过实际做测试，最后发现成本实在是太高了。完成一个事务，为确保事务完整性，20多条的消息的交互，其中只有1条是业务消息，其他都是系统之间的协议消息。这就会导致客户端响应太慢，客户无法承受这样的性能。
2、Ebay架构师的最终一致性方案：
来自Ebay的架构师根据他们的最佳实践给出过解决方案。就是关于数据一致性的，比如他们的分布式存储如何保持数据一致性。其中探讨了“实时一致”与“严格事务”之间的悖论，他们采用了局部实时一致、全局最终一致的解决方案。在这里就需要从业务上辨别哪些操作是可以放宽的（允许不在一个事务中），哪些操作必须是原子性的。现在Ebay的整个架构就是基于“最终一致性”的，支付宝也从中受到启发，沿用该设计思路解决了“客户端迅速响应”和“服务端数据一致”的矛盾。
故考虑系统架构设计的时候，不仅仅考虑技术，也把业务因素考虑进来，面向业务考量进行系统设计，会让我们在技术上做出更合理的抉择。基于业务考虑，有利于得出事务的优先级别，也有利于作出架构设计上的最佳取舍。通常来说银行、证券系统的事务完整性（或者说数据一致性）具有绝对优先级，也就要求绝对严格的实时保证。而通讯系统在事务完整性（或者说数据一致性上）的优先级别上甚至没有支付宝和Ebay高，这两者都有复杂的帐务交易。如果他们也认为局部实时一致、全局最终一致就能够满足业务的要求，那么自然在通讯系统中也有其可行性。
二、Restful与MQ技术适用场景分析
一般而言Restful技术架构为对客户端开放的一组资源服务。在分布式系统中既有客户端与服务器之间的交互，又有服务器与服务器之间的交互。比如说XCAP协议就是标准的Restful风格的接口，提供客户端远程操作XML文档的服务，而“运营管理系统”调用其他业务系统接口，用以管理用户可被分配的服务以及权限等，则是服务器之间的信息交互。前者当然适合Restful风格的技术接口，后者个人更倾向于异步的、基于消息的通信方式。因为客户端与服务器通常是跨越互联网的，而服务器与服务器之间可能位于一个局域网内，甚至可能被安放在同一个机房。
我们知道Restful风格的技术架构通常是通过JSON或者XML等进行信息的传递，总之都是通过“字符串格式”的封装进行信息传递。通过字符格式交互信息在使用上带来简便的同时，因为封装、解析、转换等过程使其在性能自然要付出一些代价，如果是服务器之间在更底层同类协议之间的数据交互性能就要高的多。这里顺便提到信息交互在不同场景下的性能顺序，按照从快到慢排序：
1、同一进程之间的信息交互；
2、同一机器两个进程之间的信息交互；
3、两个分布机器之间的信息交互。
因为HTTP是在TCP/IP协议之上的包装，WebService是在HTTP协议之上的包装，根据越低层协议之间的信息交互越高效的特征，从协议级由快到慢排序：
1、基于TCP/IP协议的信息交互；
2、基于HTTP协议的信息交互；
3、基于WebService协议的信息交互。
另外，因为“运营管理系统”与其他系统之间是直接交互的，比如运营要给某个用户开通某些特定服务，那就要分别调用提供这几个服务的业务系统的“细粒度”接口。一旦增加新的服务，也势必影响到运营管理系统的修改。我们说在分布式系统中有个原则，尽可能设计“粗粒度”接口，以减少系统之间的网络交互。如果在运营管理系统与其他业务系统之间由“消息中间件”来进行信息交互，那么：
1、运营管理系统可以设计面向服务的“粗粒度”接口，开通几个服务只需要把几种类型的数据封装在一起，一次性传递给MQ。增加服务也只不过增加一种数据类型而已；
2、MQ可以保证消息最终一定会被接收、处理。因为MQ可以实现基于“订阅-通知”的Event-Driven机制，业务系统只要在MQ中注册自己，就可以实时收到来自MQ的消息。即使出现系统或者网络异常，消息也会被MQ中间件持久化，一旦业务系统恢复，消息马上会被发往业务系统，这显然比目前采用的每隔一段时间扫描一次数据库要高效的多。
三、MQ与最终一致性
MQ消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上，队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行——它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。它为构造异步方式实现的分布式应用提供了松耦合方法，在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。
在分布式系统中，尤其是不同语言的分布式系统中，如果没有消息中间件完成信息交换，应用开发者为了高效传输数据，就要编写相应语言的应用程序来发送和接收信息，且交换信息没有标准方法，每个应用必须进行特定的编程从而和多平台、不同环境下的一个或多个应用通信。
假如系统可以采用数据“局部实时一致、全局最终一致”的方案，就可以选择不需要支持事务的MQ中间件，因为其可以保证：即使在系统异常、网络异常等特殊情况下，消息也会被持久化，当系统恢复，消息马上会被处理，也即最终一定会被接受处理，也就是最终一致。而不需要支持事务的MQ性能及吞吐率都会很高。
总之，个人倾向于用 Restful对客户端提供服务，服务器之间引入MQ服务，建立异步的、基于消息的信息交互方式，并基于数据局部实时一致、全局最终一致的原则，来解决事务问题。
‘柒’ 如何确保数据，信息的准确性，完整性，可靠性，及时性，安全性和保密性
数据完整性（Data Integrity）是
指数据的精确性（Accuracy） 和可靠性（Reliability）。它是应防止数据库中存在不符合语义规定的数据和防止因错误信息的输入输出造成无效操作或错误信息而提出的。数据完整性分为四类：实体完整性（Entity Integrity）、域完整
性（Domain Integrity）、参照完整性（Referential Integrity）、用户定义的完整性（User-definedIntegrity）。
保证数据的完整性:
用约束而非商务规则强制数据完整性
如果你按照商务规则来处理需求，那么你应当检查商务层次/用户界面：如果商务规则以后发生变化，那么只需要进行更新即可。
假如需求源于维护数据完整性的需要，那么在数据库层面上需要施加限制条件。
如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。除非你的字段命名很冗长，否则字段名本身还不够。 — Lamont Adams
只要有可能，请采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
— Peter Ritchie
2. 分布式数据系统
对分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来5 年或者10 年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置一些标记。在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据，比如计算常数和利息率等，设置版本号保证数据在每个站点都完全一致。
— Suhair TechRepublic
3. 强制指示完整性
没有好办法能在有害数据进入数据库之后消除它，所以你应该在它进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
— kol
4. 关系
如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。
— CS Data Architect
5. 采用视图
为了在你的数据库和你的应用程序代码之间提供另一层抽象，你可以为你的应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
— Gay Howe
6. 给数据保有和恢复制定计划
考虑数据保有策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。
— kol
7. 用存储过程让系统做重活
解决了许多麻烦来产生一个具有高度完整性的数据库解决方案之后，我所在的团队决定封装一些关联表的功能组，提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。在此期间，我们发现3GL 编码器设置了所有可能的错误条件，比如以下所示：
SELECT Cnt = COUNT (*)
FROM [<Table>]
WHERE [<primary key column>] = <new value>
IF Cnt = 0
BEGIN
INSERT INTO [<Table>]
( [< primary key column>] )
VALUES ( <New value> )
ELSE
BEGIN
<indicate plication error>
而一个非3GL 编码器是这样做的：
INSERT INTO [<Table>]
( [< primary key column>] )
VALUES
( <New value> )
IF @@ERROR = 2627 -- Literal error code for Primary Key Constraint
BEGIN
<indicate plication error>
第2 个程序简单多了，而且事实上，利用了我们给数据库的功能。虽然我个人不喜欢使用嵌入文字（2627）。但是那样可以很方便地用一点预先处理来代替。数据库不只是一个存放数据的地方，它也是简化编码之地。
— a-smith
8. 使用查找
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等
‘捌’ Hadoop与分布式数据处理 Spark VS Hadoop有哪些异同点
Spark是一个开源的通用并行分布式计算框架，由加州大学伯克利分校的AMP实验室开发，支持内存计算、多迭代批量处理、即席查询、流处理和图计算等多
种范式。Spark内存计算框架适合各种迭代算法和交互式数据分析，能够提升大数据处理的实时性和准确性，现已逐渐获得很多企业的支持，如阿里巴巴、百
度、网易、英特尔等公司。
针对以下几个问题来深入的学习
1、 Spark VSHadoop有哪些异同点？
Hadoop:分布式批处理计算，强调批处理，常用于数据挖掘、分析
Spark:是一个基于内存计算的开源的集群计算系统，目的是让数据分析更加快速, Spark 是一种与 Hadoop
相似的开源集群计算环境，但是两者之间还存在一些不同之处，这些有用的不同之处使 Spark 在某些工作负载方面表现得更加优越，换句话说，Spark
启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。
Spark 是在 Scala 语言中实现的，它将 Scala 用作其应用程序框架。与 Hadoop 不同，Spark 和 Scala 能够紧密集成，其中的 Scala 可以像操作本地集合对象一样轻松地操作分布式数据集。
尽管创建 Spark 是为了支持分布式数据集上的迭代作业，但是实际上它是对 Hadoop 的补充，可以在 Hadoop
文件系统中并行运行。通过名为Mesos的第三方集群框架可以支持此行为。Spark 由加州大学伯克利分校 AMP 实验室
(Algorithms,Machines,and People Lab) 开发，可用来构建大型的、低延迟的数据分析应用程序。
虽然 Spark 与 Hadoop 有相似之处，但它提供了具有有用差异的一个新的集群计算框架。首先，Spark
是为集群计算中的特定类型的工作负载而设计，即那些在并行操作之间重用工作数据集（比如机器学习算法）的工作负载。为了优化这些类型的工作负
载，Spark 引进了内存集群计算的概念，可在内存集群计算中将数据集缓存在内存中，以缩短访问延迟.
在大数据处理方面相信大家对hadoop已经耳熟能详，基于GoogleMap/Rece来实现的Hadoop为开发者提供了map、rece原
语，使并行批处理程序变得非常地简单和优美。Spark提供的数据集操作类型有很多种，不像Hadoop只提供了Map和Rece两种操作。比如
map,filter, flatMap,sample, groupByKey, receByKey, union,join,
cogroup,mapValues,
sort,partionBy等多种操作类型，他们把这些操作称为Transformations。同时还提供Count,collect,
rece, lookup,
save等多种actions。这些多种多样的数据集操作类型，给上层应用者提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的
Data Shuffle一种模式。用户可以命名，物化，控制中间结果的分区等。可以说编程模型比Hadoop更灵活.
2、Spark在容错性方面是否比其他工具更有优越性？
从Spark的论文《Resilient Distributed Datasets:
AFault-TolerantAbstraction for In-Memory Cluster
Computing》中没看出容错性做的有多好。倒是提到了分布式数据集计算，做checkpoint的两种方式，一个是checkpoint
data，一个是loggingthe
updates。貌似Spark采用了后者。但是文中后来又提到，虽然后者看似节省存储空间。但是由于数据处理模型是类似DAG的操作过程，由于图中的某
个节点出错，由于lineage
chains的依赖复杂性，可能会引起全部计算节点的重新计算，这样成本也不低。他们后来说，是存数据，还是存更新日志，做checkpoint还是由用
户说了算吧。相当于什么都没说，又把这个皮球踢给了用户。所以我看就是由用户根据业务类型，衡量是存储数据IO和磁盘空间的代价和重新计算的代价，选择代
价较小的一种策略。取代给中间结果进行持久化或建立检查点，Spark会记住产生某些数据集的操作序列。因此，当一个节点出现故障时，Spark会根据存
储信息重新构造数据集。他们认为这样也不错，因为其他节点将会帮助重建。
3、Spark对于数据处理能力和效率有哪些特色？
Spark提供了高的性能和大数据处理能力，使得用户可以快速得到反馈体验更好。另一类应用是做数据挖掘，因为Spark充分利用内存进行缓存，利用
DAG消除不必要的步骤，所以比较合适做迭代式的运算。而有相当一部分机器学习算法是通过多次迭代收敛的算法，所以适合用Spark来实现。我们把一些常
用的算法并行化用Spark实现，可以从R语言中方便地调用，降低了用户进行数据挖掘的学习成本。
Spark配有一个流数据处理模型，与Twitter的
Storm框架相比，Spark采用了一种有趣而且独特的办法。Storm基本上是像是放入独立事务的管道，在其中事务会得到分布式的处理。相
反，Spark采用一个模型收集事务，然后在短时间内（我们假设是5秒）以批处理的方式处理事件。所收集的数据成为他们自己的RDD，然后使用Spark
应用程序中常用的一组进行处理。作者声称这种模式是在缓慢节点和故障情况下会更加稳健，而且5秒的时间间隔通常对于大多数应用已经足够快了。这种方法也很
好地统一了流式处理与非流式处理部分。
总结
这几天在看Hadoop权威指南、hbase权威指南、hive权威指南、大规模分布式存储系统、zoopkeeper、大数据互联网大规模数据挖掘与分布式处理等书同时补充，能静下心来好好的完整的看完一本书，是相当不错的。
‘玖’ 做数据分析如何保障数据的准确性
从业多年，在数据准确性上摔过不少跟斗，总结了一些切实有效的方法，能够帮你尽可能的规避错误，确保数据的准确性，分享给大家
对数据上游的管理虽然看上去，数据分析师是掌握数据资源的人，但从数据的生产流程来看，数据分析师其实位于数据的下游，数据需要至少先经过采集环节、清洗环节、存储环节才能被数据分析师拿到，甚至有的体量特别大的数据，他的调取和处理环节也不能被数据分析师控制。所以，想要最终做出的数据不出错，那就要先确保我们的数据上游是准确的。
虽然数据上游一般是由其他业务或技术人员负责，但数据分析师也可以通过提需求或生产过程参与的方式，对数据上游进行管理：
设立数据“安检站”“大包小包过机安检”只要你坐过北京的地铁，相信这句话一定耳熟能详，为了确保所有旅客不把易燃易爆等危险品带入地铁内危及他人安全，地铁在每个进站口设置安检站对所有过往人员物品进行检查。虽然避免数据错误的最主要方法就是检查，但全流程无休止的数据检查显然是费时费力且效率低的，我们其实也可以在数据流入流出的关键节点设立“安检站”，只在这个时候进行数据检查。
一般我会在这些地方设立“安检站”：
几种行之有效的检查方法：
确保数据准确的几个日常习惯除了上述成体系的错误规避手段外，几个日常的好习惯也可以让我们尽可能的离错误远一点：
以上，是确保数据准确的大致经验总结，几句最关键的话再重复唠叨一下：
数据处理的准确性校验一直是个难题，是否存在一些针对据处理准确性的通用做法呢？
下面是一些对于数据进行计算处理后，保证数据准确性的个人实践：
对于大部分数据来说，数据处理可以分为以下 五个步骤 ：
1.数据采集；2.数据传输（实时/批量）；3.数据建模/存储；4.数据计算/分析；5.数据可视化展示/挖掘
针对上面五点分别展开介绍：
一、数据采集
通常数据处理之前会有数据采集的过程，数据采集会涉及到多数据来源，每中数据来源由于格式等不一致，需要特殊处理。
1.针对不通的数据源，需要做到每个数据源获取 数据能够独立。
2.采集过程需要监控，传输之前如有条件，可以做到本地有备份数据，便于异常查找时进行数据比对。
二、数据传输（实时/批量）
数据源本地已经做到有备份的情况下，对于传输异常的时候，需要 支持重试 ，存储端需要支持去重。
三、数据建模/存储
数据存储可以针对结果集合进行冗余分类存储，便于数据进行比对,针对存储需要进行副本备份，同时数据可以考虑按生效记录进行叠加存储，支持回溯 历史 的存储结构进行存储。
四、数据计算/分析/挖掘
数据进行计算，分析的时候需要进行步骤分解，便于准确性的分析和统计
1.计算之前，支持测算，同时支持数据进行分批计算，需要能导出本批次清单基础数据（例如人员或者id），便于数据核对。
2.计算之中，支持快速少量指定的典型数据测算，支持选择，是否存储参与计算过程的全部的中间变量。
3.计算之后，可以选择，支持导出本次计算过程中的所有参与变量和中间变量参数，可以线下根据数据列表对应的参数，进行计算，从而进行数据准确性的核对。
计算过程中，支持针对有问题的数据ID进行染色，染色后的数据，所有的中间过程变量全部进行打印输出。
五、数据可视化展示
可视化挖掘过程，需要主要前台图形化界面的数据量