分布式数据库在小型商业银行使用的设想

随着银行业的发展，每天面临着GB级别的增量数据。这就说明了主从备份模式的小机并不能很好的面对一些业务场景的需求。
虽然针对某些达标通过建立索引可以优化我们的查询，数据仓库每天跑定时任务也能够产生结果报表，但是在一些日常的查询当中，我们不可避免地会遇到一些大表，而针对这些大表的查询会耗费比较多的时间。所以有必要针对分布式数据存储进行一些探讨。
在这篇报道中我们主要讨论分布式数据一致性在商业银行当中的可行性。

分布式系统中，服务间的通信本质是以数据复制的方式进行交换的，由于网络或者服务存在诸多不确定性，比如网络故障、网络延时、服务异常等，使得数据复制的过程无法正常完成，造成服务见的数据不一致。
数据不一致直接影响到业务是否正常，特别是在金融领域。例如，客户在我行进行行内转账，客户转账成功后，我们希望这笔钱能够马上到达对方的账户。如果这一点无法保障，这就意味着客户白白损失了一笔冤枉钱。或者两个用户同时购买了同一笔理财产品，如果无法保证数据一致性，就有可能出现同一笔理财产品被卖给了两个人。如何避免这种情况出现？很简单，系统要保证客户A购买理财产品的过程中，客户B处于等待状态，知道客户A购买成功。这个场景说明了一个问题，系统如果要保持一致性，可能影响性能。

CAP和BASE理论

CAP理论

2000年，Eric Brewer在PODC（Principles of Distributed Computing）会议上提出了著名的CAP理论。2年后，Seth Gilbert和Nancy Lynch从数学上证明了这一理论。CAP理论告诉我们，在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）3个要素最多只能同时满足两个，不可兼得。

• 一致性：分布式环境下多个节点的数据是否强一致。
• 可用性：分布式服务能一直保证可用状态。当用户发出一个请求后，服务能在有限时间内返回结果。
• 分区容忍性：特指对网格分区的容忍性。

在分布式系统中，分区容忍性不可或缺，否则就不是一个分布式系统了。下面通过一个例子介绍分布式数据一致性的两种方案。假设我们的服务分别部署在两个数据中心（DC1和DC2），每个数据中心的实例都有一个数据库，同时，两个数据库会互相进行数据同步，即应用实例对数据库的读写操作都落在本地数据库，然后由数据库的同步机制对两个节点进行数据同步。

1. 牺牲一致性

如果我们要优先保证系统可用性。DC1和DC2间出现网络故障，DC2上的应用实例将看不到DC1上的数据变更，DC1上的应用实例也看不到DC2上的数据变更。就是说，我们的系统仍然可用，两个DC的应用实例在网络分区后仍然能够响应服务请求，但是失去了数据一致性。这样被舍弃了一致性的系统被称为一个AP系统。

2. 牺牲可用性

如果我们要优先保证系统可用性。每个DC的数据库都需要知道本地数据副本和其他数据库节点的数据要完全一致。在网格分区的情况下，数据库节点之间无法通信，也就无法同步数据。要保证系统的数据一致性，我们唯一的选择只能是应用拒绝响应请求。这样被舍弃了可用性的系统被称为一个CP系统。

CAP理论在NoSQL中应用很广，比如Cassandra、Dynamo等，默认优先选择AP，弱化C，对一致性要求低一些。另外一些比如HBase、MongoDB等，默认优先选择CP，弱化A。

BASE理论

传统关系型数据库通过事务来保障数据的ACID特性。

• 原子性（Atomicity）：事务中所有操作要么全部完成，要么全部不完成。
• 一致性（Consistency）：事务开始或结束时，数据库处于一致状态。
• 隔离性（Isolation）：事务之间互不影响。
• 持久性（Durability）：事务一旦完成，就不可逆转。

在数据库分区出现之后，事务的ACID实现变得困难，于是厂商引入2PC（两阶段提交）协议来保障数据库多实例之间的事务，但是因为2PC的课扩展性很差，在分布式架构下应用代价较大，于是ebay架构师Dan Pritchett提出了BASE理论，用于解决大规模分布式系统下的数据一致性问题。其核心思想如下。

• 基本可用（Basically Available）：指分布式系统在出现故障时，允许损失部分的可用性来保证核心可用。
• 软状态（Soft State）：指允许分布式系统存在中间状态，该中间状态不会影响到系统的整体可用性。
• 最终一致性（Eventual Consistency）：指分布式系统中的所有副本数据经过一定时间后，最终能够达到一致的状态。

分布式事务的实现存在局限性，BASE理论告诉我们另外一个思路：可以通过放弃系统在每个时刻的强一致性来换取系统的可扩展性。

一致性模型

数据的一致性模型分为以下3类。

1. 强一致性：数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现。
2. 弱一致性：数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到。
3. 最终一致性：弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。

分布式系统的强一致性、弱一致性和最终一致性可以通过Quorum NRW算法分析，Quorum NRW是一种乐观的保证分布式系统一致性的算法，通过对读写副本数的不同设值来获得性能、一致性和可用性之间的平衡。

举个实际的例子，比如支付系统中，买家执行完支付100元的操作之后，就认为完成了一次购买行为，这100元要从买家的账户里扣除，实时加入卖家的账户里，或者说，只有卖家账户收到钱了，才能认为交易完成，买家账户才能扣钱，这就是数据强一致性。另外比如比价系统，比价系统后台定时任务抓取其他平台的商品价格，定时任务可能抓取失败，这就导致比价系统中的价格与商品的当前价格一致不一致，只要比价系统能接受这种不一致，我们就可以认为比价系统是一个弱一致性的系统。再比如评价系统，买家对一件商品评价，卖家或者其他买家不一定能马上看到这条评论，只有过了下个数据同步周期才能看到，我们把这里的评价系统称为最终一致性系统。

总结

由此可见，通过分布式集群方案来解决单机服务器的一些性能问题的设想是可行的。虽然为了实现分布式的效果，可能会影响一定的性能，并且分布式环境的部署也会变得稍微复杂，增加了运维的成本。同时，目前市场上的一些NoSQL产品没有很好的对存储过程的支持，而目前我行开发人员对数据的提取、加工主要是使用存储过程，转移到分布式环境则需要使用MapReduce等方式来达到数据的提取、加工的目的，可谓是任重而道远。