1、1数据一致性在应用系统设计的思考摘 要：随着网络应用的不断深入，特别是互联网应用的发展，基于分布式数据库的系统越来越多。分布式数据库应用系统的多节点数据存储、多用户访问以及数据读写操作特点，使得应用系统的数据完整性解决方案成为系统设计需要考虑的核心问题。本文试图通过国内外大型应用系统发展的经验，结合实际开发工作的心得，对分布式应用系统开发过程中，数据一致性解决方法做一些初步探讨。 关键词：数据 系统 设计 中图分类号：TP311 文献标识码：A 文章编号：1003-9082（2013）12-0005-02 一、数据一致性 数据一致性（Data Consistency）是指事务执行的结果必须是使
2、数据库从一个一致性状态变到另一个一致性状态。保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态，在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性。 我们用网上购物作为实例来解释数据一致性，设想网上购物的一次交易，其付款过程至少包括以下几步数据库操作： 1.更新客户所购商品的库存信息 2.保存客户付款信息，包括与银行系统的支付 3.生成订单并且保存到数据库中 24.更新用户相关信息，例如购物数量等等。 整个交易过程中，设计系统必须保证订单下单、银行已支付两个操作都必须要完成，最终交易成功，与交易相关的所有数据库信息也成功地更新，这样对客户来说就是数据一致
3、。 这个例子就是典型的强数据一致性，所有的操作过程都非常顺畅完整。但是但是，如果在这一系列过程中任何一个环节出了差错，例如在更新商品库存信息时发生异常、该顾客银行帐户存款不足等，都将导致交易失败。一旦交易失败，数据库中所有信息都必须保持交易前的状态不变，比如最后一步更新用户信息时失败而导致交易失败，那么必须保证这笔失败的交易不影响数据库的状态-库存信息没有被更新、用户也没有付款，订单也没有生成。否则，数据库的信息将会一片混乱而不可预测。 为了保证系统数据库信息更新的有序和完整，系统设计采用数据库事务来解决这一问题。在分布式数据库系统中， “事务”是一系列不可分割的操作序列， 将数据库从一个一致
4、性状态转变到另一个一致性状态， 由于全局事务与局部事务存在并发执行， 可能会造成数据副本不一致。传统的事务控制法通过分布式两段锁协议（2PL 协议） 来保证全局事务与局部事务执行的可串行性， 即可保证事务的一致性调度， 以及通过分布式两段提交协议（2PC 协议） 来同步更新各副本数据 。 实际上，随着网络应用的不断深入，特别是互联网应用的发展，基于分布式数据库的系统越来越多，用传统的数据库的事务处理要想实现理想数据一致性非常困难。在一些数据量大、用户对数据的操作范围大3的情况下， 事务保持时间长， 若采用 2PL 协议， 则会严重地影响事务并发程度， 不能满足实际需要， 同时， 2PC 协议或
5、 3PC 协议的方法在网上通信量很大， 而由于网络速度有限， 因此， 会使用户陷入长时间的不可忍受的等待状态， 或遇到频繁的事务失败， 重新启动事务太多，造成应用程序运行效率低下，严重甚至宕机，最典型的失败应用就属最早的铁路售票系统。 二、Cap 理论 对网络分布数据库的应用出现的问题，Eric Brewer 教授提出著名的CAP 定理。 CAP 理论是数据系统设计的基本理论，10 年前加州大学伯克利分校Eric Brewer 教授提出 CAP 定理，是指在设计和部署分布式应用的时候，存在三个核心的系统需求，这个三个需求之间存在一定的特殊关系，这三个需求是： C： Consistency 一致
6、性 A： Availability 可用性 P：Partition Tolerance 分区容错性 CAP 理论的核心是：一个分布式系统不可能同时很好的满足一致性、可用性和分区容错性这三个需求，最多只能同时较好的满足两个。 其中字母“C“、“A“、“P“分别代表以下三个特征： 强一致性（Consistency） 。系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读取到最新的值，这样的系统被认为具有强一致性。 4可用性（Availability） 。好的可用性主要是指系统能够很好的为用户服务，每一个操作总是能够在一定的时间内返回结果。 分区容错性（Pa
7、rtition Tolerance） 。分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，这样就具有好的分区容错性。 依据 CAP 理论，在设计和部署分布式应用的时候，需要在这三个核心系统需求之间做出取舍。一般情况下，满足一致性、可用性的系统，通常在可扩展性上不太强大；满足一致性、分区容忍性的系统，通常性能不是特别高；满足可用性、分区容忍性的系统，通常可能对一致性要求低一些
8、。 现在，在设计一些大型网络应用中，往往采用保持分区容错性，选择可用性放弃一致性，采用折中的 “最终一致性（Eventually Consistent） ”的一致性策略。 最终一致性是一种特殊的弱一致；存储系统保证如果没有新的更新提交，最终所有的访问都将获得最后的更新。如果没有故障发生，不一致窗口的大小取决于通信延迟，系统负载，以及复制策略中涉及的副本数。最常见实现最终一致性的系统是 DNS，对于 name 更新的传播依赖，配置模式以及基于时间控制的缓存；最终，所有的节点将会看到更新。需要注意：在不同的应用系统设计时，最终一致性模型有很多变种。 5三、应用案例分析 Amazon Dynamo
9、Dynamo 是 Amazon（亚马逊） 公司经典的分布式 Key-Value 存储系统，具备去中心化、高可用性、高扩展性的特点。Dynamo 在 Amazon 中得到了成功的应用，能够跨数据中心部署于上万个结点上提供服务，它的设计思想也被后续的许多分布式系统借鉴。 在系统设计方面，为了达到高可用性、高效性，在很多情况下就牺牲了一致性。 Dynamo 采用的是著名的一致性哈希算法，利用数据对象的版本化实现一致性。复制时因为更新产生的一致性问题的维护采取类似 quorum 的机制以及去中心化的复制同步协议，该算法在一致性的策略上，放弃了强一致性（实时一致性） ，而是采用最终一致性模型。 1.淘宝
10、 淘宝作为著名的网上交易网站，除了成功的商业模式之外，其高效的网站设计更是令许多 IT 界人士倍加赞叹。淘宝的数据库架构不是一步到位，演变经历了一个漫长的过程，主要分三个阶段： 第一个阶段：网站结构采用 LAMP，数据库采用几个 MYSQL，应用系统分前台和后台。应用模式为典型的集中式数据库应用，数据一致性策略采用强一致性。 第二个阶段：MYSQL 迁移到 ORAACLE，服务器由 PC server 升级到小型机，应用模式仍为典型的集中式数据库应用，数据一致性策略采用强一致性。 6第三个阶段：核心业务有 ORACLE 逐步迁移到分布式 MYSQL 集群中，应用模式为分布式数据库应用，数据一致
11、采用若一致性策略 淘宝第三阶段的数据库应用架构是典型的大型高性能网站普遍采用的读写分离构架。 一般情况下，为了提高大型网站的访问速度，除了常用的方法如 SQL优化、缓存、集群等外，从数据库构架上常常采用数据库读写分离的架构，该架构数据一致性的策略属于弱一致性，非强一致性。所谓读写分离（Read/Write Splitting） ，基本的原理是让主数据库处理事务性查询，而从数据库处理 SELECT 查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库，对于大访问量的网站，一般会采用读写分离，比如 ebay 就是采用此架构，它的读写比率是 260：1。 淘宝的数据库读写分离的策略大致
12、如下： 写库为集中式的 oracle 环境，提供数据安全性保障； 读库使用 mysql， 采用数据分片，分库分表； oracle 到多台 mysql 按规则复制。 2.陕西省领导桌面系统 为了能够给省委、省政府领导和省发改委主要领导宏观决策提供全面、准确、及时、可靠的一站式信息服务，陕西省信息中心开发了“陕西省领导桌面系统” 。 系统主体采用 C/S，B/S 的混合架构设计，由“前端桌面（客户端）+数据通信系统” 、数据中心、维护端三个子系统组成，三个子系统均能够独立运行。 7系统逻辑结构如下： 数据库的应用架构采用分布式架构，数据中心存放整个业务数据，完成业务数据信息数据管理和维护；每个前端
13、桌面保持有独立的业务数据，前端桌面在不联网情况下也可独立运行，当网络接通时能够自动下载最新数据信息，保证与中心数据库的同步一致。 为了满足前端桌面在断网时，还能使用的高可用性需求，在系统设计时，放弃了强一致性的方式，采用最终一致性同步策略，具体实现方式如下： 采用 Pull 模式定时从桌面从数据中心下载数据 由于每个前端桌面没有固定的 IP，数据中心无法事先确定前端桌面的地址，在数据中心数据发生变化时，无法采用 PUSH 推送方式传送数据，只能采用 Pull 模式。在该模式下，定时向数据中心发送数据请求，数据下载后，加载到本地数据库，实现桌面数据库与中心数据库的最终一致；每条业务数据都有一项“
14、最后修改时间”数据字段标示 全部下载的方式是最简单、最容易实现的模式，但采用方式，要耗费较长的时间。为了提高下载速度以及系统性能，在系统设计中采用增量下载的模式，为此在每条业务数据设有“最后修改时间”数据标示，无论数据是新增或修改，都需要变更“最后修改时间”数据标示，从而每个桌面可以自动判断需要下载数据的时间范围，实现自动数据增量更新。 四、结论 8完成一个高效的大型网络应用系统，并能够较好的实现数据一致性，需要一个综合的和平衡的设计思路和方式，特别是对数据一致性的解决方案设计更需要充分考虑应用需求。从本文列举的案例可以看出，每个应用实现一致性采用的策略各不相同，既有采用系统软件提供的技术实现，也有自己通过软件开发实现，没有通用的模式。 作者简介：张兴华，男，现供职于陕西省信息中心。
