分布式数据库发展背景

“双十一”指数型的成交总额发展曲线，让世界看到了中国电商业务的火箭式发展势头。

而同时，对于背后的业务支撑系统来说，他们同样经历了火箭式的系统压力增长。

“双十一”这场考试的考生，除了直接面向用户的电商网站系统，还有背后各相关物流公司的物流系统，各相关银行的支付系统，各卖家的仓储系统等等。

以银行支付系统为例，核心的支付系统通常采用所谓的“IOE”结构，即IBM的大型机或小型机、Oracle的数据库、EMC的存储设备。这套系统支撑银行传统的柜台业务的确没有什么问题，但是仍存在成本巨大且与服务提供商严重捆绑的隐患。

随着移动互联网的快速发展以及电子支付的兴起，我们从买一件几百块钱的衣服到买一个几毛钱的糖果，都使用移动支付方式进行交易，而所有的这类交易过程背后其实都需要经过银行核心支付系统，这对于银行核心支付系统来说是爆炸式的业务增速。

传统的“IOE”系统为集中式系统，即所有软件系统都运行在一个性能十分强大的服务器上，例如IBM的AS 400，AS 390，当业务压力变大时，采用的一般是“scale up”方式，即继续增加这台服务器的性能上限。

但是随着“摩尔定律”的逐渐失效，单台服务器上的性能极限已经慢慢显露，“scale up”路线即将走到尽头。

在这种情况下，技术人员逐渐开始探索“scale out”路线，即将原有的集中式系统改造为分布式系统，通过多台廉价的服务器的水平扩展方式替换一台高性能服务器垂直扩展方式，即开始实施“众人拾柴火焰高”的宗旨，同时完成降低成本、增长性能的目的。

分布式事务数据库发展背景

“scale out”路线理论上可以进行无限的水平扩展，即无限的业务能力上限，但是实际上在绝大部分场景中却无法达到。

仍以银行支付系统为例，核心原因就在于其业务场景中包含事务类的业务需求。

事务类的业务需求的典型特点是“ACID”属性，即原子性、一致性、隔离性、持久性，这在集中式系统中比较容易满足，且已经经过了很长时间的发展及验证。

但是随着数据库系统呈分布式化后，系统中增加了数据的网络传输环节，网络中数据传输的速度大概比单机系统低1000倍左右，同时还具有产生错误的可能。所以如何保障“ACID”属性在分布式数据库系统中成为一个难题。

针对分布式系统这方面的研究，产生了“CAP”理论。即一致性、可用性、分区容错性只能三选二，不能同时满足。简单说需要满足分区容错性就需要多副本分布，而多副本分布会带来副本一致性问题，副本一致性问题又会导致性能问题，所以CAP无法同时满足。

通常在分布式环境中，分区情况是普遍存在的，所以P必须满足，剩下的针对不同业务，选择CA其一，所以产生了两种分布式数据库路线。

一类是分布式事务型数据库，即“OLTP”数据库。强调一致性，典型的例如加了分布式中间件的MySQL数据库、AWS的Auraro、Google的Spanner。

一类是分布式分析型数据库，即“OLAP”数据库。强调高可用性，典型的例如HBase、Memcached、Greenplum等。

分布式事务数据库技术特点

接下来重点关注分布式事务数据库，即“OLTP”数据库技术特点。

在分布式环境中，数据的扩展形式主要存在两种。

一种是进行数据分区，大表变小表，不同的分区数据存放在不同的服务器上，针对不同分区数据的操作由不同的服务器提供服务，从而增加高可用性。

一种是进行数据镜像，一份变多份，不同镜像的数据存放在不同的服务器上，针对同一份数据的操作可以由不同的服务器提供服务，提升可用性，而且当其中某台服务器发生故障时，能够有副本继续提供，从而提升分区容错性。

而针对两种扩展形式，分布式环境中相应存在两种方案的事务问题。

一种是多机协作问题，即一个事务涉及到两个分区的数据，这两个分区数据分布在不同的服务器上，如何让这个事务保证“ACID”属性？

一种是数据同步问题，即一个事务将改变某一份分区数据时，如何让这份数据的镜像与其保持同步，从而能保证对外提供这份数据的服务器之间不出现互相不一致的问题？

通俗的说，第一种即“consistency”问题，第二种即“consensus”问题。

针对第一种问题，核心依然是传统式单机数据库系统的事务问题，即锁和并发问题，只不过从传统的2PL改变为2PC。常见的解决方案包括2PC、3PC、2+XPC，异步消息队列，TCC等。针对不同的业务场景，再在这集中解决方案里选择不同的隔离级别，从而确定锁以及MVCC实施具体细节。

针对第二种问题，核心是分布式系统中的数据复制问题。由于分布式网络的延迟和不确定性，“一致性”上开始发生妥协，分为三个等级，即“弱一致性”、“最终一致性”、“强一致性”。本问题常见的解决方案包括主从模式、主主模式、paxos、raft、zab等一致性算法方案，针对不同的一致性要求，选择复制方案。

根据上述两种问题，业内大概分为三类方案。

第一种方案，mysql加中间件。常见的中间件例如cobar、mycat等，负责数据分区信息维护，sql解析，事务执行等。此类方案应用成熟，但是因为有中间件这类静态控制节点，所以存在单点问题，同时分库分表等仍需业务方较多干预。

第二种方案，Auraro、Rac类数据库，shared disk。计算层分布式部署，共享存储层。通过计算层的扩展保证集群性能的扩展，统一存储保证数据的一致性。此类方案扩展性较第一种方案增强，但是由于统一存储带来的性能瓶颈，集群规模仍受到限制。据报道，百台规模情况下，性能将会出现大幅下降。

第三种方案，spanner、oceanbase类数据库，shared nothing。计算存储分类，理论均可无限扩展，通过一致性算法及MVCC动态维护集群状态及事务行为。spanner目前已经应用到google的广告系统，ob据称已经支撑蚂蚁金服绝大部分业务。但是存储层分离，节点之间通过网络来通信，事务的延迟肯定较上述两种方案较大，具体延迟情况目前尚未测试验证。

分布式事务数据库发展趋势

首先是分布式事务数据库的功能形态，AP+TP=HTAP是趋势，随着大数据的业务探索及落地，各企业都利用数据扩展出核心业务之外的分析系统，所以同时保障事务性以及高可用性是数据库的功能需求，但是通过何种解决方案同时提供两种服务，以及两者的功能比重，仍需要探索及实践。

其次是新型硬件之下的分布式事务数据库形态，随着存储与计算硬件的变革，传统数据库的底层读写模式与新型的设备匹配度仍有很大鸿沟。是否需要先写日志再刷盘？是否需要以传统磁盘块单位计算缓冲区大小？是否IO还是主要性能瓶颈？可能这些都是未来新型数据库需要改变的方向。

最后是换种思路解决传统软件解决方案无法解决的问题。传统事务一致性因为物理时钟同步难做到，所以采用了逻辑时钟来维护事务顺序，而spanner中google直接采用gps+原子钟硬件校准方案解决物理时钟同步问题，从而做到了全球一致性。所以预计未来将会出现更多协调硬件完成软件无法解决的问题。