数据一致性在应用系统设计思考.docVIP

数据一致性在应用系统设计思考 　　摘 要：随着网络应用的不断深入，特别是互联网应用的发展，基于分布式数据库的系统越来越多。分布式数据库应用系统的多节点数据存储、多用户访问以及数据读写操作特点，使得应用系统的数据完整性解决方案成为系统设计需要考虑的核心问题。本文试图通过国内外大型应用系统发展的经验，结合实际开发工作的心得，对分布式应用系统开发过程中，数据一致性解决方法做一些初步探讨。 　　关键词：数据 系统 设计 　　中图分类号：TP311 文献标识码：A 文章编号：1003-9082（2013）12-0005-02 　　一、数据一致性 　　数据一致性（Data Consistency）是指事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态，在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性。 　　我们用网上购物作为实例来解释数据一致性，设想网上购物的一次交易，其付款过程至少包括以下几步数据库操作： 　　1.更新客户所购商品的库存信息 　　2.保存客户付款信息，包括与银行系统的支付 　　3.生成订单并且保存到数据库中 　　4.更新用户相关信息，例如购物数量等等。 　　整个交易过程中，设计系统必须保证订单下单、银行已支付两个操作都必须要完成，最终交易成功，与交易相关的所有数据库信息也成功地更新，这样对客户来说就是数据一致。 　　这个例子就是典型的强数据一致性，所有的操作过程都非常顺畅完整。但是但是，如果在这一系列过程中任何一个环节出了差错，例如在更新商品库存信息时发生异常、该顾客银行帐户存款不足等，都将导致交易失败。一旦交易失败，数据库中所有信息都必须保持交易前的状态不变，比如最后一步更新用户信息时失败而导致交易失败，那么必须保证这笔失败的交易不影响数据库的状态--库存信息没有被更新、用户也没有付款，订单也没有生成。否则，数据库的信息将会一片混乱而不可预测。 　　为了保证系统数据库信息更新的有序和完整，系统设计采用数据库事务来解决这一问题。在分布式数据库系统中，“事务”是一系列不可分割的操作序列， 将数据库从一个一致性状态转变到另一个一致性状态， 由于全局事务与局部事务存在并发执行， 可能会造成数据副本不一致。传统的事务控制法通过分布式两段锁协议（2PL 协议） 来保证全局事务与局部事务执行的可串行性， 即可保证事务的一致性调度， 以及通过分布式两段提交协议（2PC 协议） 来同步更新各副本数据 。 　　实际上，随着网络应用的不断深入，特别是互联网应用的发展，基于分布式数据库的系统越来越多，用传统的数据库的事务处理要想实现理想数据一致性非常困难。在一些数据量大、用户对数据的操作范围大的情况下， 事务保持时间长， 若采用2PL 协议， 则会严重地影响事务并发程度， 不能满足实际需要， 同时， 2PC 协议或3PC 协议的方法在网上通信量很大， 而由于网络速度有限， 因此， 会使用户陷入长时间的不可忍受的等待状态， 或遇到频繁的事务失败， 重新启动事务太多， 造成应用程序运行效率低下，严重甚至宕机，最典型的失败应用就属最早的铁路售票系统。 　　二、Cap理论 　　对网络分布数据库的应用出现的问题，Eric Brewer教授提出著名的CAP定理。 　　CAP理论是数据系统设计的基本理论，10年前加州大学伯克利分校Eric Brewer教授提出CAP定理，是指在设计和部署分布式应用的时候，存在三个核心的系统需求，这个三个需求之间存在一定的特殊关系，这三个需求是： 　　C： Consistency 一致性 　　A： Availability 可用性 　　P：Partition Tolerance分区容错性 　　CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性、可用性和分区容错性这三个需求，最多只能同时较好的满足两个。 　　其中字母C、A、P分别代表以下三个特征： 　　强一致性（Consistency）。系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读取到最新的值，这样的系统被认为具有强一致性。 　　可用性（Availability）。好的可用性主要是指系统能够很好的为用户服务，每一个操作总是能够在一定的时间内返回结果。 　　分区容错性（Partition Tolerance）。分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常