腾讯分布式数据库TDSQL金融级能力的架构原理概述
目录
TDSQL是什么：腾讯如何打造一款金融级分布式数据库
我们先初步了解TDSQL产品，以及它的适用场景。第一章包括四个方面：使用场景、发展历程、核心特性，以及兼容性。
首先，TDSQL是腾讯推出的一款兼容MySQL的自主可控、高一致性分布式数据库产品。这里我们强调一点，高度兼容MySQL——TDSQL完全兼容MySQL协议，并且做到完全自主可控、数据强一致性。第二是TDSQL具备分布式的特性，具备一个弹性扩展、高可用的架构。在互联网行业，海量的用户流量场景很常见，如果数据库不具备可伸缩性、可扩展性，是很难应对如：电商的大型促销，春节抢红包等突增流量的场景，这些其实都是对数据库应对海量用户流量的考验。
目前TDSQL已经服务超过500+的金融政企，行业覆盖银行、保险、证券、政务、互联网金融等各个领域。
我们再看一下TDSQL的前世今生。TDSQL最早可以追溯到2002年，那个时候其实还不叫TDSQL，它是腾讯计费平台部的一个数据库服务，当时使用了开源的MySQL。2002年-2007年随着公司业务的发展，腾讯所面临的用户量的压力也越来越大。这个时候我们提出了7×24小时不宕机的高可用设计方案，来保证数据库能提供7×24小时不间断连续高可用服务。那个时候，腾讯的增值业务日渐成规模，业务对数据也越来越敏感，对数据可用性的要求越来越高，甚至平时还要防备一些像运营商的光纤被挖断等各种各样的异常场景。
在2007年-2012年，这可能是互联网时代从互联网到移动互联网的发展的快速5年。当然，公司的业务也是突飞猛进。我们开始把这个高可用的数据库产品化。到2012年，TDSQL的雏形就已经出来了，作为一款内部产品，开始在公司内部提供金融级的数据强一致性、可靠性服务。
从2012年起，TDSQL已经在腾讯内部做得已经比较成熟，已经是一个知名的产品了，但是它一直没有对外做商业化。2014年恰逢一个很好的机会——微众银行的成立。微众银行做数据库选型的时候关注到了TDSQL，经过反复测试验证，发现当时的TDSQL已经完全具备了微众银行对数据可用性和一致性的要求。借此机会，TDSQL成功在微众银行投产，成为微众银行唯一的数据库，覆盖了银行的核心业务。
所以说2014年，TDSQL完成了商业化，也实现了私有化部署。2014年以后，TDSQL推广到了很多银行、金融机构，这过程中是借鉴了2014年TDSQL在微众银行成功实施的宝贵的经验。
因为在2014年微众银行的部署中，我们也踩了很多坑，也认识到在私有化部署环境的各种各样的挑战，并一一攻克了这些挑战。当2014年在私有化部署完成之后，再到2015年TDSQL上公有云，我们继续通过公有云服务打磨自己的产品。
所以从2012年作为一个内部产品到2014年的私有化部署，再到2015年公有云上的部署，TDSQL已经逐步从一个内部产品逐渐走向行业，成为一个正式对外的商用数据库。从2015年到2019年，TDSQL已经推广到许多银行和金融政企。但是很重要的一点是，虽然服务了很多银行、金融客户，但是在银行领域有一块比较难动的蛋糕叫银行的传统核心系统。传统核心系统数据库长期以来一直是被国外的商用数据库所垄断，比如说ORACLE、DB2啊，像TDSQL这类分布式数据库是很难介入的。
2018年，我们关注到张家港银行有更换核心系统的需求，就此建立联系并成功达成合作，最终，2019年，我们将腾讯这套分布式数据库系统成功应用到了张家港银行的传统核心系统。张家港行也是作为全国第一家传统核心系统上分布式数据库的银行，分布式数据库不再是只局限于银行的互联网核心、互联网银行等外围系统的尝试，而是真真正正切入到银行系统的心脏—传统核心，这也是国产数据库领域一个具有里程碑意义的事件。
所以在未来，我们也将继续“走出去”深入到更复杂、更新核心的业务系统，打磨我们的产品。
这是TDSQL的发展历程。
TDSQL核心特性：极具挑战的“四高”服务与安全可运维
我们再看TDSQL的核心特性。
首先作为适应于金融场景的数据库，数据强一致性是立命之本，因为数据不能丢、不能错。在金融场景，你没有办法去估量——假如错一条数据，到底这条数据是1分钱还是1个亿，所以数据强一致是我们最根本的一个特性。不允许丢，不允许错，这是对数据库起码的要求。
第二是金融级高可用。TDSQL确保99.999%以上的可用性，并支持跨IDC、多机房、同城多活的部署方式。我们最先切入金融场景是因为金融场景的挑战是最大的。中国金融行业受监管要求最为苛刻，同时也对数据和业务的可用性、可靠性、一致性更是有极高的要求。我们要求99.999%的可用性，也就是说这个数据库全年故障的时间不能超过5分钟。
第三是高性能、低成本。互联网时代的企业，都是海量业务、海量机器，性能稍微提高一个10%，可能就节约成百上千台机器的成本，这个经济效益还是比较大的。所以高性能、低成本也是TDSQL的一个关键特性。
第四点是线性水平扩展。因为无论是互联网还是其他企业，随着数字化的发展，比如说出现突增流量，搞个活动等，现在单机的承载量越来越容易凸显出瓶颈。所以我们提出这种水平线性扩展的能力，要求它可进行水平伸缩。可能一台机器的负载、硬盘、机器资源容纳不了，但可以把它拆到多台机器，不需要考虑太多，它可以自动地提高自身吞吐量和负载量。
第五点是企业级安全。金融数据是敏感的，一些敏感的金融数据需要在当前数据基础上再做一层更高级别的企业安全防护，比如数据库防火墙，以及透明加密，等等。
第六点是便捷的运维，私有化部署中，很多情况下其实他们的网络环境和部署环境跟我们是隔离的，如果银行客户有问题，那其实我们第一时间是切入不了去帮助解决的，所以就需要一套完善的配套设施，简单容易上手，可以自动帮用户去定位问题、解决问题，同时也尽量减少运维的复杂度。
TDSQL核心架构
接下来我们了解TDSQL的架构以及模块划分。通过这一章节的了解，我们更能切入TDSQL 的技术细节，它为什么要这样设计，这样设计有什么好处，如何通过这样的架构和设计实现高可用、线性扩展等能力。
TDSQL系统总览
?资源池
这张图从下往上看，首先最底层是资源池，属于IaaS层服务，可以是物理机，也可以是虚拟机，只要是给TDSQL添加机器就好，TDSQL是在一个机器的资源池上实现了数据库实例的管理。当然，这里推荐的还是物理机，如果增加一层虚拟机服务，无疑在稳定性和性能方面都会引入一些隐患。
?存储节点
从资源池再往上是存储节点。存储节点要强调的是TDSQL的两种存储形态，一种是Noshard 数据库，一种是分布式数据库（也叫Shard版TDSQL）。简单来说，Noshard就是一个单机版的TDSQL，在MySQL的基础上做了一系列的改造和改良，让它支持TDSQL的一系列特性，包括高可用，数据强一致、7×24小时自动故障切换等。第二种是分布式数据库，具备水平伸缩能力。所以TDSQL对外其实呈现了两种形态，呈现一种非分布式形态，一种是分布式的形态。至于这两种形态的区别，或者说什么场景更适合于哪种数据库，后面我们有专门的章节去分析。
?计算节点
再看计算节点。计算节点就是TDSQL的计算引擎，做到了计算层和存储层相分离。计算层主要是做一些SQL方面的处理，比如词法解、语法解析、SQL改写等。如果是分布式数据库形态，还要做分布式事务相关的协调，所以我们看到计算层不存储数据，只运行SQL方面的实时计算，所以它更偏CPU密集型。此外，TDSQL计算节点还具备OLAP的能力，对一些复杂的计算可以进行算法上的优化——什么时候该下推到存储引擎层，什么时候需要在计算层做汇总等，这是计算节点需要做的事情。
?赤兔运营管理平台
再往上，是赤兔运营管理平台，如果说把下面这一套东西比作一个黑盒，我们希望有一个用户界面操纵这个黑盒，这个界面就是赤兔运营管理平台。通过这个平台，DBA可以操纵TDSQL后台黑盒，所以相当于是一套WEB管理系统。让所有DBA的操作都可以在用户界面上完成，而不需要登陆到后台，不需要关心计算节点是哪个，存储节点是哪个，或者怎么样管理它，要加一些节点或者减一些节点，或者把这个节点从哪里要迁到哪里……这些都可以通过界面化完成。DBA操作界面不容易出错，但如果登陆到后台很容易一个误操作，不小心把机器重启了，就可能会造成一定的影响。
?“扁鹊”智能DBA平台
有了赤兔之外，为什么还有一个“扁鹊”智能DBA平台呢？可能正常情况下，我们机器是好的，但是，机器如果发生了故障，或者说哪天磁盘有坏块了，或者是IO性能越来越差……SSD 其实有一个衰老的过程，到了后期的话，吞吐量和IOPS可能会有一定下降，导致数据库的响应速度变慢。这种情况如果DBA要排查，得先去看到是哪一个实例、涉及到哪一台机器、这个机器有什么问题、检测机器的健康状态……这些都是机械性的工作，有了扁鹊智能管理平台，当出现故障的时候就可以自动分析故障的原因，举个例子，可以找出是因为什么导致SQL变慢了，或者又是因为什么原因发生了主备切换，突然IO异常了或者其他什么原因导致机器故障。
此外，扁鹊智能DBA平台还有一个智能诊断系统，可以定期由DBA发起对实例进行的诊断。比如有些数据库实例，CPU常年跑得很高，其实是一些比较差的SQL导致的。这个时候扁鹊智能DBA系统，可以很方便地到用户实例上做巡检，得到一个健康状况图，并对它进行打分，发现这个实例比如他的CPU超用了，需要扩容，但是没有扩容，就会减分；然后其他表的索引没有建好，要减分……以此生成一个诊断报告。所以，有了扁鹊，再加上赤兔运营管理平台，DBA的工作其实是非常轻松的，可能每天只需要点几下按纽，然后就解决了一系列的麻烦，包括高可用，性能分析，锁分析等，完全把DBA从繁杂的工作中解放出来。
此外，我们看到这里其实还有几个小的模块。调度系统，调度系统主要是负责整体的资源调度，比如说数据库实例的增加删除、过期作废，还有一些容量的调度，即扩容、缩容，还有一些多租户的管理。也就是说这是整个管理台的调度器。
另外还有一个备份系统，这个是冷备中心，后面有一个专门的章节去讲，这里就不再赘述。此外，我们还提供了一些服务模块作为辅助，比如审计，还有数据库之间的迁移服务——我们TDSQL怎么能够帮助异地数据库迁进来，或者从TDSQL再迁出。此外，还包括数据校验、数据订阅、SQL防火墙、注入检测等安全方面的模块，以及一个辅助模块——帮助我们的DBA也好，用户也好，完成一些个性化的丰富的需求。
以上是TDSQL系统总览。
TDSQL架构模块及其特性
我们再看一下核心架构。核心架构其实是上一个图的缩览，我们把核心的模块挑选出来。
首先用户的请求通过负载均衡发往SQL引擎。然后，SQL引擎作为计算接入层，根据这个SQL的要求从后端的存储节点去取数据。当然，无论是SQL引擎还是后端的数据库实例都存在一个元数据来管理调度。举个例子，计算引擎需要拿到一个路由，路由告诉SQL引擎，这个SQL该发往哪一个后端的数据节点，到底是该发往主节点还是发往备节点。所以我们引入了ZK（Zookeeper）来储存类似于路由这类元数据信息。当然ZK只是静态的存储元数据，维护和管理这些元数据信息，还需要有一套调度以及接口组件，这里是OSS、Manager/Schedule。所以我们这张图可以看到是TDSQL整体来说就分为三部分：管理节点、计算节点和存储节点。当然这里还有一个辅助模块，帮助完成一些个性化需求的，比如备份、消息队列，数据迁移工具等。另外，这里的负载均衡其实不是必需的，用户可以选用自身的硬件负载，也可以用LVS软负载，这个负载均衡根据实际的用户场景可自定义。
了解了整体架构以后，我们继续再看一下每个节点的特性是什么、对机器的依赖程度如何，要求机器有哪些特性，等等。
?管理模块：轻松通过web界面管理整个数据库后台
首先，我们要看的是管理模块。作为一个集群只搭建一套的管理模块，一般可以复用一组机器。同时，管理模块对机器的要求相对来说比较低，比如资源紧张的时候，我们用虚拟机就可以代替。在我们内部，一套管理模块承载最大的管理单集群近上万实例。
管理模块包含前文说的几个关键模块：Zookeeper(ZK)、Scheduler、Manager、OSS和监控采集程序、赤兔管理控制台。那么它们是怎么联合工作的呢？首先，DBA用户在赤兔管理台——这一套WEB前台发起一个操作——点了一个按纽，这个按纽可能是对实例进行扩容，这个按纽会把这个https的请求转移到OSS模块，这个OSS模块有点像web服务器，它能接收web请求，但是它可以把这个转发到ZK。所以，OSS模块就是一个前端到后台的桥梁，有了OSS模块，整个后台的工作模块都可以跟前台、跟web界面绑定在一起。
好，捕捉到这个请求之后，在ZK上创建一个任务节点，这个任务节点被调度模块捕获，捕获之后就处理任务。处理完任务，再把它的处理结果返回到ZK上。ZK上的任务被OSS捕获，最后也是https的请求，去查询这个任务，最后得到一个结果，返回给前端。
这是一个纯异步的过程，但是有了这套管理模块，让我们可以轻松的通过web界面去管理整个TDSQL的后台。当然，这整个过程都有一个监控采集模块去采集，对整个流程的审计及状态进行获取。
?DB模块：数据库无损升级
DB模块，即数据节点，数据存取服务属于IO密集型的服务，因此，数据节点也是我们的存储节点，它对IO的要求比较高，一般建议配置SSD硬盘，最好是PCI-E的SSD。因为对数据库服务来说，CPU再高，如果IO跟不上，仍然是小马拉大车。比如只有1千的IOPS，CPU根本就跑不起来，用不起来。所以这里一般建议至少IOPS要达到1万以上。
我们再看一下SET的概念。SET就是数据库实例，一个SET包含数据库的——比如我们默认要求的是一主两备，一个Master节点和两个Slave节点。当然在DB节点上有一个Agent 的模块。MySQL在执行中，我们要监控它的行为，以及进行操作。如果把这些东西做到MySQL里面为什么不可以呢？这其实存在一个问题，如果对数据节点进行升级，可能就要涉及到重启，一旦重启就影响用户的业务，影响服务。这个时候我们就考虑，在它上面加一
个模块Agent，它来完成对所有集群对MySQL的操作，并且上报MySQL的状态。有了它之后，对TDSQL数据节点的大部分升级，都会转变为对Agent的升级，而升级Agent，对业务没有任何影响，这就实现了无损升级。相比于Agent我们对数据节点MySQL不会频繁升级，一般情况下一年、半年都不会动它。这是我们DB模块，也是存储节点。
?SQL引擎模块：分布式复杂SQL处理
接下来再看另外一个比较重要的模块：SQL引擎模块。SQL引擎处于计算层的位置，本身属于CPU密集型，所以我们在选机型上尽量要求CPU高一些。其次是内存，作为计算接入层，
它要管理链接，如果是大量的短链接或者长链接，非常占内存，所以它对CPU和内存的要求比较高。此外，它本身不存储数据，也没有主备之分，所以对硬盘没有太大要求。
我们看一下SQL引擎的特性。SQL引擎首先还是从ZK上拉取到元数据，作为SQL引擎，包括权限校验、读写分离，以及统计信息、协议模拟等相关的操作。
可能有些人会问，其实这个SQL引擎岂不是一种中间件？其实并不是这样，SQL引擎如果是一个中间件，它都可以脱离MySQL。但是我们这个SQL引擎，需要做词法、语法分析，以及作为查询引擎等工作。而且在分布式的场景下，SQL引擎复杂的功能性就会凸显，比如要处理分布式事物，还要维护全局自增字段，保证多个数据、多个存储节点共享一个保证全局自增的序列；如果是分布式的话，要限制一些语法，包括词法和语法的解析；还有在一些复杂计算上，它还要做一些SQL下推，以及最后数据的聚合。所以SQL引擎还是一个相对来说比较复杂的模块，作为计算层，并不是一个简单的中间件那么简单。这就是一个SQL引擎。
TDSQL金融级特性之：数据强一致性保障
前面我们了解了TDSQL的整体架构和核心特性。接下来我们要重点聊一聊它最重要的特性——作为金融场景下不可或缺的数据强一致性的保障。我们将从四个方面来聊一聊数据一致性的保障：
?主备数据复制方式
?数据复制比较：TDSQL主备数据复制方案VS MySQL原生方案
?核心功能：容灾切换，数据强一致、0丢失0出错
?数据强一致性
?TDSQL主备数据复制：高性能强同步
首先在讲数据一致性之前，我们先了解一下MySQL原生的数据复制的方式。
一、何为分布式数据库系统？一个分布式数据库系统有哪些特点？ 答案：分布式数据库系统通俗地说，是物理上分散而逻辑上集中的数据库系统。分布式数据库系统使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的多个逻辑单位连接起来，共同组成一个统一的数据库系统。因此，分布式数据库系统可以看成是计算机网络与数据库系统的有机结合。一个分布式数据库系统具有如下特点： 物理分布性，即分布式数据库系统中的数据不是存储在一个站点上，而是分散存储在由计算机网络连接起来的多个站点上，而且这种分散存储对用户来说是感觉不到的。 逻辑整体性，分布式数据库系统中的数据物理上是分散在各个站点中，但这些分散的数据逻辑上却构成一个整体，它们被分布式数据库系统的所有用户共享，并由一个分布式数据库管理系统统一管理，它使得“分布”对用户来说是透明的。 站点自治性，也称为场地自治性，各站点上的数据由本地的DBMS管理，具有自治处理能力，完成本站点的应用，这是分布式数据库系统与多处理机系统的区别。 另外，由以上三个分布式数据库系统的基本特点还可以导出它的其它特点，即：数据分布透明性、集中与自治相结合的控制机制、存在适当的数据冗余度、事务管理的分布性。 二、简述分布式数据库的模式结构和各层模式的概念。 分布式数据库是多层的，国分为四层： 全局外层：全局外模式，是全局应用的用户视图，所以也称全局试图。它为全局概念模式的子集，表示全局应用所涉及的数据库部分。 全局概念层：全局概念模式、分片模式和分配模式 全局概念模式描述分布式数据库中全局数据的逻辑结构和数据特性，与集中式数据库中的概念模式是集中式数据库的概念视图一样，全局概念模式是分布式数据库的全局概念视图。分片模式用于说明如何放置数据库的分片部分。分布式数据库可划分为许多逻辑片，定义片段、片段与概念模式之间的映射关系。分配模式是根据选定的数据分布策略，定义各片段的物理存放站点。 局部概念层：局部概念模式是全局概念模式的子集。局部层：局部模式 局部模式是分布式数据库中关于物理数据库的描述，类同集中式数据库中的模式，但其描述的容不仅包含只局部于本站点的数据的存储描述，还包括全局数据在本站点的存储描述。 三、简述分布式数据库系统中的分布透明性，举例说明分布式数据库简单查询的 各级分布透明性问题。 分布式数据库中的分布透明性即分布独立性，指用户或用户程序使用分布式数据库如同使用集中式数据库那样，不必关心全局数据的分布情况，包括全局数据的逻辑分片情况、逻辑片段的站点位置分配情况，以及各站点上数据库的数据模型等。即全局数据的逻辑分片、片段的物理位置分配，各站点数据库的数据模型等情况对用户和用户程序透明。
分布式数据库管理系统简介 一、什么是分布式数据库： 分布式数据库系统是在集中式数据库系统的基础上发展来的。是数据库技术与网络技术结合的产物。 分布式数据库系统有两种：一种是物理上分布的，但逻辑上却是集中的。这种分布式数据库只适宜用途比较单一的、不大的单位或部门。另一种分布式数据库系统在物理上和逻辑上都是分布的，也就是所谓联邦式分布数据库系统。由于组成联邦的各个子数据库系统是相对“自治”的，这种系统可以容纳多种不同用途的、差异较大的数据库，比较适宜于大范围内数据库的集成。 分布式数据库系统（DDBS）包含分布式数据库管理系统（DDBMS和分布式数据库（DDB）。 在分布式数据库系统中，一个应用程序可以对数据库进行透明操作，数据库中的数据分别在不同的局部数据库中存储、由不同的DBMS进行管理、在不同的机器上运行、由不同的 操作系统支持、被不同的通信网络连接在一起。 一个分布式数据库在逻辑上是一个统一的整体：即在用户面前为单个逻辑数据库，在物理上则是分别存储在不同的物理节点上。一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库。它的分布性表现在数据库中的数据不是存储在同一场地。更确切地讲，不存储在同一计算机的存储设备上。这就是与集中式数据库的区别。从用户的角度看，一个分布式数据库系统在逻辑上和集中式数据库系统一样，用户可以在任何一个场地执行全局应用。就好那些数据是存储在同一台计算机上，有单个数据库管理系统（DBMS）管理一样，用 户并没有什么感觉不一样。 分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性。 分布式数据库系统是一个客户/ 服务器体系结构。 在系统中的每一台计算机称为结点。如果一结点具有管理数据库软件，该结点称为数据库服务器。如果一个结点为请求服务器的信息的一应用，该结点称为客户。在ORACL客户， 执行数据库应用，可存取数据信息和与用户交互。在服务器，执行ORACL软件，处理对ORACLE 数据库并发、共享数据存取。ORACL允许上述两部分在同一台计算机上，但当客户部分和 服务器部分是由网连接的不同计算机上时，更有效。 分布处理是由多台处理机分担单个任务的处理。在ORACL数据库系统中分布处理的例 子如： 客户和服务器是位于网络连接的不同计算机上。 单台计算机上有多个处理器，不同处理器分别执行客户应用。 参与分布式数据库的每一服务器是分别地独立地管理数据库，好像每一数据库不是网络化的数据库。每一个数据库独立地被管理，称为场地自治性。场地自治性有下列好处： ?系统的结点可反映公司的逻辑组织。
海量数据下分布式数据库系统的探索与研究 摘要：当前，互联网用户规模不断扩大，这些都与互联网的快速发展有关。现 在传统的数据库已经不能满足用户的需求了。随着云计算技术的飞速发展，我国 海量数据快速增长，数据量年均增速超过50％，预计到2020年，数据总量全球 占比将达到20％，成为数据量最大、数据类型最丰富的国家之一。采用分布式数 据库可以显著提高系统的可靠性和处理效率，同时也可以提高用户的访问速度和 可用性。本文主要介绍了分布式数据库的探索与研究。 关键词：海量数据；数据库系统 1.传统数据库： 1.1 层次数据库系统。 层次模型是描述实体及其与树结构关系的数据模型。在这个结构中，每种记 录类型都由一个节点表示，并且记录类型之间的关系由节点之间的一个有向直线 段表示。每个父节点可以有多个子节点，但每个子节点只能有一个父节点。这种 结构决定了采用层次模型作为数据组织方式的层次数据库系统只能处理一对多的 实体关系。 1.2 网状数据库系统。 网状模型允许一个节点同时具有多个父节点和子节点。因此，与层次模型相比，网格结构更具通用性，可以直接描述现实世界中的实体。也可以认为层次模 型是网格模型的特例。 1.3 关系数据库系统。 关系模型是一种使用二维表结构来表示实体类型及其关系的数据模型。它的 基本假设是所有数据都表示为数学关系。关系模型数据结构简单、清晰、高度独立，是目前主流的数据库数据模型。 随着电子银行和网上银行业务的创新和扩展，数据存储层缺乏良好的可扩展性，难以应对应用层的高并发数据访问。过去，银行使用小型计算机和大型存储 等高端设备来确保数据库的可用性。在可扩展性方面，主要通过增加CPU、内存、磁盘等来提高处理能力。这种集中式的体系结构使数据库逐渐成为整个系统的瓶颈，越来越不适应海量数据对计算能力的巨大需求。互联网金融给金融业带来了 新的技术和业务挑战。大数据平台和分布式数据库解决方案的高可用性、高可靠 性和可扩展性是金融业的新技术选择。它们不仅有利于提高金融行业的业务创新 能力和用户体验，而且有利于增强自身的技术储备，以满足互联网时代的市场竞争。因此，对于银行业来说，以分布式数据库解决方案来逐步替代现有关系型数 据库成为最佳选择。 2.分布式数据库的概念： 分布式数据库系统：分布式数据库由一组数据组成，这些数据物理上分布在 计算机网络的不同节点上（也称为站点），逻辑上属于同一个系统。 （1）分布性：数据库中的数据不是存储在同一个地方，更准确地说，它不是 存储在同一台计算机存储设备中，这可以与集中数据库区别开来。 （2）逻辑整体性：这些数据在逻辑上是相互连接和集成的（逻辑上就像一个 集中的数据库）。 分布式数据库的精确定义：分布式数据库由分布在计算机网络中不同计算机
高并发分布式服务架构方案 下图是一个非常全面的架构蓝图，针对不同的应用系统需要的模块各有不同。此架构方案主要包括以下几个方面的设计：数据存储和读取，基础服务，应用层（APP/业务/Proxy），日志监控等，下面对这些主要的问题提供具体的各项针对性技术方案。 数据的存储和读取 分布式系统应该根据应用对数据不同的一致性、可用性等要求和数据的不同特性，采用不同的数据存储和读取方案，主要有以下几种可选方案： 1)内存型数据库。内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格， 适合进行海量数据的存储和读取。例如开源nosql数据库mongodb、redis等。 2)关系型数据库。关系型数据库在满足并发性能的同时，也需要满足事务性，可通过 读写分离，分库分表来应对高并发大数据量的情况。例如Oracle，Mysql等。 3)分布式数据库。对于数据的高并发的访问，传统的关系型数据库提供读写分离的方案， 但是带来的确实数据的一致性问题提供的数据切分的方案；对于越来越多的海量数据，传统的数据库采用的是分库分表，实现起来比较复杂，后期要不断的进行迁移维护；对
于高可用和伸缩方面，传统数据采用的是主备、主从、多主的方案，但是本身扩展性比较差，增加节点和宕机需要进行数据的迁移。对于以上提出的这些问题，分布式数据库HBase有一套完善的解决方案，适用于高并发海量数据存取的要求。 基础服务 基础服务主要是指数据层之上的数据路由，Cache，搜索等服务。 1)路由Router。对于数据库切分方案中的分库分表问题，需要解决在请求对应的数据时 定位需要访问的位置，可根据一致性Hash，维护路由表至内存数据库等方案解决。 2)Cache。对于高并发的系统来讲，使用Cache可以减轻对后端系统的压力，所有Cache 可承担大部分热数据的读操作。当前用的比较多的是redis和memcache，redis比memcache有丰富的数据操作的API，redis对数据进行了持久化，而memcache没有这个功能，因此memcache更加适合在关系型数据库之上的数据的缓存。 3)搜索。搜索可以支持应用系统的按照关键词的检索，搜索提示，搜索排序等功能。开源 开源的企业级搜索引擎主要有lucene, sphinx，选择搜索引擎主要考虑以下三个方面： a)搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高 可用性 b)索引的实时性 c)搜索引擎的性能 Solr是基于Lucene开发的高性能的全文搜索服务器，满足以上三个方面的考虑，而且目前在企业中应用非常广泛。 应用层 应用层主要包括面向用户的应用，网站、APP等，还包括相关的业务处理的运算等。 1)负载均衡-反向代理。一个大型的平台包括很多个业务域，不同的业务域有不同的集群， 可以用DNS做域名解析的分发或轮询，DNS方式实现简单。但是因存在cache而缺乏灵活性；一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在做分发，当然会采用做冗余(比如lvs+keepalived)的考虑，采取主备方式。Nginx是基于事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件，可用作反向代理的工具。
分布式数据库技术在大数据中的应用
分布式数据库技术在大数据中的应用 摘要随着当前运营商对数据管理和应用需求的不断增加，分布式数据库技术得到极大的发展。在本文中首先对当前大数据环境下的分布式数据库技术进行介绍，然后分析分布式数据库技术在大数据中的具体应用。 关键词分布式数据库；数据管理；数据处理 中图分类号 TP3 文献标识码 A 文章编号 1674-6708（2016）165-0108-01 随着当前移动互联网技术的迅猛发展，数据的种类和数量呈现快速的增长，传统的处理方式逐渐的不能够适应当前的发展需要，基于此种背景下，分布式数据库技术需要得到更快的发展，以达到对大数据的存储、管理以及分析等处理要求。 1 大数据中发展分布式数据库的意义 在面对当前的大数据时代，传统的集中式数据库已经逐渐的不能够满足人们的使用要求，需要找到新的处理方式来进行更新，分布式数据库就是在这样的背景下逐渐的被发展和应用。分布式数据库在使用中有着许多传统集中式数据库不具备的优点：第一，分布式数据库有着极为强大的扩展能力，这是传统数据库所不具备的，在数据的存储方面表现出巨大的优势；第二，来自于成本上的优势。
在大数据中，如果仍旧采用原有的数据库，在进行扩容的时候，会花费大量的资金，使得成本上花费巨大，而且所取得的效果也是有限的。分布式数据库则只需要较少的资金就能够完成扩容处理，占据着特别大的优势[1]；第三，分布式数据库在用户上有着很大的优势，分布式数据库让人们对大数据的存储、分析和处理变得容易和快捷。 2 分布式数据库技术分析 在大数据中，分布式数据库技术得到极大的发展，也正是由于分布式数据库技术表现出来的先进性能，才使得分布式数据库得到广泛的使用。在分布式数据库中，其由很多个并行的处理单元组成，而且每个处理单元都是一个完整的系统，其中包括数据的存储，数据的分析等，对于每一个处理单元来说，其所处的位置和作用都是对等的，而且是相对独立的。混合存储技术：突破传统行存的限制，实现行列混合存储。该项技术对于分布式数据库的性能有着很大的提升，使得分布式数据库在运行速度和运行的灵活性上都有很大的提高。再就是智能索引技术，该种技术所占用的空间减少，并且能够很好的解决后面数据库慢的问题，不会对后面的索引数据造成影响[2]。除此之外，分布式数据库中还具有许多先进的技术，如并行处理技术、高效透明压缩技术等，都是传统数据库中所不具备
金融级分布式数据库架构设计
目录 1.行业背景 (3) 2.数据库分布式改造的途径 (3) 3.分布式数据库总体架构 (4) 4.两阶段提交的问题 (5) 5.CAP与BASE的抉择 (7) 6.raft的优势 (8) 6.1. Leader选举 (9) 6.2. 日志复制 (10) 6.3. 安全性 (11) 7.分布式数据库如何实现PITR (16)
1.行业背景 银行业从最初的手工记账到会计电算化，到金融电子化，再到现在的金融科技，可以看到金融与科技的结合越来越紧密，人工智能、大数据、物联网、区块链等新兴技术改变了金融的交易方式，为金融行业的创新前行提供了源源不断的动力。同时互联网金融的兴起是一把双刃剑，带来了机遇的同时也带来了挑战。普惠金融使得金融的门槛降低，更多的普通大众参与到金融活动中，这让金融信息系统承受了越来越大的压力。于是我们可以看到大型商业银行、保险公司、证券公司、交易所等核心交易系统都在纷纷进行分布式改造，其中数据库作为有状态的应用，成为了信息系统中唯一的单点，承担了所有来自上层应用的压力。随着数据库瓶颈的凸显，进行分布式改造迫在眉睫。 2.数据库分布式改造的途径 数据库进行分布式改造主要有三种途径：分布式访问客户端、分布式访问中间件、分布式数据库。由于其分布式能力实现在不同的层次（应用层、中间层、数据库层），对应用程序有不同的侵入程度，其中分布式访问客户端对应用侵入性最大，改造难度最大，而分布式数据库方案对应用侵入性最小，但是架构设计及研发难度最大。
3.分布式数据库总体架构 其实当前市面上的分布式数据库总体架构都是类似的，由必不可缺的三个组件组成：接入节点、数据节点、全局事务管理器。总体架构如下，协调节点负责sql解析，生成分布式执行计划，sql转发，数据汇总等；数据节点负责数据存储与运算；全局事务管理器负责全局事务号的生成，保证事务的全局一致性。这个架构或多或少都受到了google spanner F1论文的影响，这篇文章主要分析了这几个组件在实现上有什么难点，该如何进行架构设计。
分布式数据库系统(DDBS概述 一个远程事务为一个事务,包含一人或多个远程语句,它所引用的全部是在同一个远程结点上.一个分布式事务中一个事务,包含一个或多个语句修改分布式数据库的两个或多个不同结点的数据. 在分布式数据库中,事务控制必须在网络上直辖市,保证数据一致性.两阶段提交机制保证参与分布式事务的全部数据库服务器是全部提交或全部回滚事务中的语句. ORACLE分布式数据库系统结构可由ORACLE数据库管理员为终端用户和应用提供位置透明性,利用视图、同义词、过程可提供ORACLE分布式数据库系统中的位置透明性. ORACLE提供两种机制实现分布式数据库中表重复的透明性：表快照提供异步的表重复;触发器实现同步的表的重复。在两种情况下，都实现了对表重复的透明性。 在单场地或分布式数据库中，所有事务都是用COMMIT或ROLLBACK语句中止。 二、分布式数据库系统的分类： (1 同构同质型DDBS：各个场地都采用同一类型的数据模型(譬如都是关系型，并且是同一型号的DBMS。 (2同构异质型DDBS：各个场地采用同一类型的数据模型，但是DBMS的型号不同，譬如DB2、ORACLE、SYBASE、SQL Server等。 (3异构型DDBS：各个场地的数据模型的型号不同，甚至类型也不同。随着计算机网络技术的发展，异种机联网问题已经得到较好的解决，此时依靠异构型DDBS就能存取全网中各种异构局部库中的数据。 三、分布式数据库系统主要特点： DDBS的基本特点： (1物理分布性：数据不是存储在一个场地上，而是存储在计算机网络的多个场地上。 逻辑整体性：数据物理分布在各个场地，但逻辑上是一个整体，它们被所有用户(全局用户共享，并由一个DDBMS统一管理。 (2场地自治性：各场地上的数据由本地的DBMS管理，具有自治处理能力，完成本场地的应用(局部应用。 (3场地之间协作性：各场地虽然具有高度的自治性，但是又相互协作构成一个整体。 DDBS的其他特点 (1数据独立性 (2集中与自治相结合的控制机制 (3适当增加数据冗余度
1.大型分布式数据库解决方案 企业数据库的数据量很大时候，即使服务器在没有任何压力的情况下，某些复杂的查询操作都会非常缓慢，影响最终用户的体验；当数据量很大的时候，对数据库的装载与导出，备份与恢复，结构的调整，索引的调整等都会让数据库停止服务或者高负荷运转很长时间，影响数据库的可用性和易管理性。 分区表技术 让用户能够把数据分散存放到不同的物理磁盘中，提高这些磁盘的并行处理能力，达到优化查询性能的目的。但是分区表只能把数据分散到同一机器的不同磁盘中，也就是还是依赖于一个机器的硬件资源，不能从根本上解决问题。 分布式分区视图 分布式分区视图允许用户将大型表中的数据分散到不同机器的数据库上，用户不需要知道直接访问哪个基础表而是通过视图访问数据，在开发上有一定的透明性。但是并没有简化分区数据集的管理、设计。用户使用分区视图时，必须单独创建、管理每个基础表（在其中定义视图的表）,而且必须单独为每个表管理数
据完整性约束，管理工作变得非常复杂。而且还有一些限制，比如不能使用自增列，不能有大数据对象。对于全局查询并不是并行计算，有时还不如不分区的响应快。 库表散列 在开发基于库表散列的数据库架构，经过数次数据库升级，最终采用按照用户进行的库表散列，但是这些都是基于自己业务逻辑进行的，没有一个通用的实现。客户在实际应用中要投入很大的研发成本，面临很大的风险。 面对海量数据库在高并发的应用环境下，仅仅靠提升服务器的硬件配置是不能从根本上解决问题的，分布式网格集群通过数据分区把数据拆分成更小的部分，分配到不同的服务器中。查询可以由多个服务器上的CPU、I/O来共同负载，通过各节点并行处理数据来提高性能；写入时，可以在多个分区数据库中并行写入，显著提升数据库的写入速度。
分布式数据库系统（1） 胡经国 本文作者的话 本文是根据有关文献和资料编写的《漫话云计算》系列文稿之一。以此作为云计算学习笔录，供云计算业外读者进一步学习和研究参考。希望能够得到大家的指教和喜欢！ 下面是正文 一、分布式数据库系统概述 1、概述一 分布式数据库（Distributed Database，DDB）是指数据分散存储在计算机网络中的各台计算机上的数据库。 分布式数据库系统（Distributed Database System，DDBS）通常使用较小的计算机系统，每台计算机可单独放在一个地方；每台计算机中都可能有DBMS （数据库管理系统）的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库；位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的、逻辑上集中、物理上分布的大型数据库系统。 2、概述二 分布式数据库，是指利用高速计算机网络，将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。 分布式数据库的基本思想，是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。 近年来，随着数据量的高速增长，分布式数据库技术也得到了快速的发展。传统的关系型数据库开始从集中式模型向分布式架构发展。基于关系型的分布式数据库，在保留传统数据库的数据模型和基本特征前提下，从集中式存储走向分布式存储，从集中式计算走向分布式计算。 另一方面，随着数据量越来越大，关系型数据库开始暴露出一些难以克服的缺点。以NoSQL为代表的、具有高可扩展性、高并发性等优势的非关系型数据库快速发展；一时间市场上出现了大量的key-value（键－值）存储系统、文档型数据库等NoSQL数据库产品。NoSQL类型数据库正日渐成为大数据时代下分布式数据库领域的主力。 这种按分布式组织数据库的方法克服了物理中心数据库组织的弱点。
根据CAP理论，一致性(C)，可用性(A)，分区容错性(P)，三者不可兼得，必须有所取舍。而传统数据库保证了强一致性(ACID模型)和高可用性，所以要想实现一个分布式数据库集群非常困难，这也解释了为什么数据库的扩展能力十分有限。而近年来不断发展壮大的NoSQL运动，就是通过牺牲强一致性，采用BASE模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。 但是，对于CAP理论也有一些不同的声音，数据库大师Michael Stonebraker就撰文《Errors in Database Systems, Eventual Consistency, and the CAP Theorem》，表示为了P而牺牲C是不可取的。事实上，数据库系统最大的优势就对一致性的保证，如果我们放弃了一致性，也许NoSQL比数据库更有优势。那么，有没有可能实现一套分布式数据库集群，即保证可用性和一致性，又可以提供很好的扩展能力呢？回答是：有的。 目前，有很多分布式数据库的产品，但是绝大部分是面向DSS类型的应用，因为相比较OLTP应用，DSS应用更容易做到分布式扩展。Michael Stonebraker提到了一种新型的数据库VoltDB，它的定义是Next-Generation SQL Database for Fast-Scaling OLTP Applications。虽然产品还没有问世，但是从技术资料上来看，它有几个特点： 1.采用Share nothing架构，将物理服务器划分为以CPU core为单位的Virtual node，采用Sharding技术，将数据自动分布到不同的Virtual node，最大限度的利用机器的计算资源； 2.采用内存数据访问技术，类似于内存数据库(In-memory database)，区别于传统的数据库(Disk-based database)，消除了传统数据库内存管理的开销，而且响应速度非常快； 3.每个Virtual node上的操作是自治的，利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销(比如Latch和Lock)； 4.数据同步写多个副本，不存在单点故障，而且消除了传统数据库需要记录redo log的开销。
第9章分布式数据库系统 9.1 基本内容分析 9.1.1 本章重要概念 （1）分布计算的三种形式：处理分布，数据分布，功能分布。 （2）C/S系统，工作模式，技术特征，体系结构，两层、三层、多层C/S结构。 （3）DDBS的定义、特点、优点、缺点和分类；分布式数据存储的两种形式（分片和分配）。 （4）DDB的体系结构：六层模式，分布透明性的三个层次，DDBS的组成，DDBMS的功能和组成。 （5）分布式查询处理的查询代价，基于半联接的优化策略，基于联接的优化策略。 （6）分布式数据库的并发控制和恢复中出现的问题，以及处理机制。 9.1.2 本章的重点篇幅 （1）两层、三层、多层C/S结构。（教材P365-367） （2）分布式数据存储：分片和分配。（教材P375-377） （3）DDB的体系结构。（教材P378的图9.10，P381的图9.12） （4）基于半联接的执行示意图。（教材P389的图9.17） 9.2 教材中习题9的解答 9.1 名词解释 ·集中计算：单点数据和单点处理的方式称为集中计算。 ·分布计算：随着计算机网络技术的发展，突破集中计算框架，DBMS的运行环境逐渐从单机扩展到网络，对数据的处理从集中式走向分布式、从封闭式走向开放式。这种计算环境称为分布计算。 ·处理分布：指系统中处理是分布的，数据是集中的这种情况。 ·数据分布：指系统中数据是分布的，但逻辑上是一个整体这种情况。 ·功能分布：将计算机功能分布在不同计算机上执行，譬如把DBMS功能放在服务器上执行，把应用处理功能放在客户机上执行。 ·服务器位置透明性：指C/S系统向客户提供服务器位置透明性服务，用户
山西大学研究生学位课程论文（2014 ---- 2015 学年第 2 学期） 学院（中心、所）：计算机与信息技术学院 专业名称：计算机应用技术 课程名称：分布式数据库技术 论文题目：分布式数据库研究现状及发展趋势授课教师（职称）：曹峰（） 研究生姓名：刘杰飞 年级：2014级 学号：201422403003 成绩： 评阅日期： 山西大学研究生学院 2015年 6 月17日
分布式数据库研究现状及发展趋势 摘要随着大数据、云时代的到来，数据库应用需求的拓展和计算机硬件环境的变化，特别是计算机网络与数字通信技术的飞速发展，卫星通信、蜂窝通信、计算机局域网、广域网和激增的Intranet及Internet得到了广泛应用，使分布式数据库系统应运而生。为了符合当今信息系统的应用需求和企业组织的管理思想和管理模式。分布式数据库提供了解决整个信息资产被分裂所成的信息孤岛，为孤岛联系在一起提供桥梁。本文主要介绍分布式数据库的研究现状，存在的一些问题以及未来的发展趋势。 关键词分布式数据库；发展趋势；现状及问题 1.引言 随着信息技术的飞速发展，社会经济结构、生产方式和消费结构已经发生了重大变化，这些变化深刻地影响着人民生活的方方面面。尤其是近十年来人们对计算机的依赖性越来越强，同时也对计算机提出了更高的要求。随着数据库在各个行业中的不断发展，各行业也对数据库提出了更高的要求，数据量也急剧增加，同时有关大数据分析的讨论正在愈演愈烈。甚至出现了爆炸性增长的趋势，一方面是由于移动互联网和移动智能终端的普及发展，数据信息正以每年40%的速度增长，造成数据量庞大；同时，数据种类呈多样性，文本、图片、视频等结构化和非结构化数据共存；另一方面也要求实时交互性强；最重要的是大数据蕴含了巨大的商业价值。相应的对于管理这些数据的复杂度也随之增加。同时各行业部门或企业所使用的软硬件之间的差异，这给开发企业管理数据库管理软件带来了巨大的工作量，如果能够有效解决这个问题，即使用同一模块管理操作不同的数据表格，对不同的数据表格进行查询、插入、删除、修改等操作，也即对企业简单的应用实现即插即用的功能，那么就能大大地减少软件开发的维护和更新费用，缩短软件的开发周期。分布式数据库系统的开发，降低了企业开发的成本，提高了软件使用的回报率。当今社会已进入了信息时代，人们将越来越多的信息存储在网络中的计算机上。如何更有效地存储、管理、共享和提取信息，越来越引起人们的关注。集中式数据库已经不能满足人们的需求，因此分布式数据库系统应运而生，并且得到迅速发展。 分布式数据库系统的出现，有效地利用企业现有资源和网络资源。分布式数据库系统是一个面向地理上分布而在管理上需要不同程度集中的处理系统，主要解决在计算机网络上如何进行数据的分布和处理。由于分布式数据库有许多突出的优点，因此，分布式数据库系统可以广泛地应用于大企业，多种行业及军事国防等领域，这对建立集约型社会，加快社会主义现代化建设，将具有重要的现实意义。。
分布式数据库设计报告
目录 1案例背景 (1) 需求分析 (1) 2 分布式数据库设计 (2) 设计目标 (2) 总体设计目标 (2) （4）可靠性： (3) 完成方式及周期 (3) 分布式数据库架构图 (4) 物理设计施工 (5) 3 总结 (5) 4所用设备汇总 (7) 5所使用软件 (7)
成品车间分布式数据库设计 1案例背景 随着成品车间信息化程度越来越高，我们的传统集中式数据库系统的缺点逐渐体现出来主要有: 1、所有数据处理、存储集中在一台计算机上完成，一旦机器损坏或系统崩 溃数据数据很难恢复。 2、单台机器写入/查询处理能力不足，一台机器既要读取数据，又要写入数 据，遇到大批量超过单台数据库的处理能力，就会出现卡顿，在生产时 间不敢批量制造/查询数据。 3、硬件性能瓶颈，包括(硬盘、CPU、内存)，使用升级硬件的方法效果有限。 4、出现故障没有备用服务器可以替代。 5、当前成品车间存在2种数据库，oracle，sql sever，交叉使用不方便管 理维护，出现问题排查困难。 6、由于数据库初期创建数据库/表比较混乱，现在对数据的统计管理需要在 两台服务器之间交叉进行，统计难度高，效率低。 需求分析 成品车间信息化程度越来越高，各个节点产生的数据量越来越大，对数据系统要求越来越高，我们所使用的传统集中式数据库已经无法从容应对越来越大的数据。 成品车间生产线数据库主要有oracle和sql server两种，分别分布在2台计算机中，柔性线、自动线、三相线交叉使用两种类型数据库，主要出现的问题有; 1、一旦其中一个数据库出现问题，那么就有很大的几率导致三条线体 的某个节点或全部节点失去数据服务，导致停线。 2、数据库出现故障，必须停线，故障修复之后才可以上线使用。
第一章 1.1 采用分布式数据库系统的主要原因是什么？ 集中式数据库系统的不足：1.数据按实际需要已经在网络上分布存储，如果再采用集中式处理，势必造成附加成本和通信开销，2,。应用程序集中在一台计算机上运行，一旦该计算机发生故障，将会影响整个系统的运行，可靠性不高。3集中式处理导致系统的规模和配置都不够灵活，系统的可扩展性较差。 1.2 分布式数据库系统有哪几种分类方法？这些方法是如何分类的？ 1.按局部数据库管理系统的数据模型的类型分类。 （1）同构型：同构同质型：各个站点上的数据库的数据模型都是同一类型的，而且是同一种DBMS。 同构异质型：各个站点上的数据库的数据模型都是同一类型的，但不是同一种DBMS。 （2）异构型：各个站点上的数据库的数据模型各不相同。 2.按分布式数据库系统全局控制系统类型分类 （1）全局控制集中型DDBS （2）全局控制分散型DDBS （3）全局控制可变型DDBS 1.3 什么是分布式数据库系统？它具有那些主要特点？怎样区分分布式数据库系统与只提供远程数据访问的网络数据库系统？ 分布式数据库系统是物理上分散而逻辑上集中的数据库系统，其可以看成是计算机网络和数据库系统的有机结合。 基本特点：物理分布性、逻辑整体性、站点自治性。 导出特点：数据分布透明性、集中与自治相结合的机制、存在适当的数据冗余度、事务管理的分布性。 区分：分布式数据库的分布性是透明的，用户感觉不到远程与本地结合的接缝的存在。 1.6分布式DBMS具有哪些集中式DBMS不具备的功能？ 数据跟踪，分布式查询处理，分布式事务管理，复制数据管理，安全性，分布式目录管理 1.14分布式数据库系统的主要优点是什么？存在哪些技术问题？ 分布式数据库系统优点：良好地可靠性和可用性；提高系统效率，降低通信成本；较大的灵活性和可伸缩性；经济型和保护投资；适应组织的分布式管理和控制；数据分布式具有透明性和站点具有较好的自治性；提高了资源利用率；实现了数据共享。
分布式数据库系统 分布式数据库系统有两种：一种是物理上分布的，但逻辑上却是集中的。这种分布式数据库只适宜用途比较单一的、不大的单位或部门。另一种分布式数据库系统在物理上和逻辑上都是分布的，也就是所谓联邦式分布数据库系统。由于组成联邦的各个子数据库系统是相对“自治”的，这种系统可以容纳多种不同用途的、差异较大的数据库，比较适宜于大范围内数据库的集成。 ----- ---- 分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。在分布式数据库系统中，一个应用程序可以对数据库进行透明操作，数据库中的数据分别在不同的局部数据库中存储、由不同的DBMS进行管理、在不同的机器上运行、由不同的操作系统支持、被不同的通信网络连接在一起。 一个分布式数据库在逻辑上是一个统一的整体，在物理上则是分别存储在不同的物理节点上。一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库。它的分布性表现在数据库中的数据不是存储在同一场地。更确切地讲，不存储在同一计算机的存储设备上。这就是与集中式数据库的区别。从用户的角度看，一个分布式数据库系统在逻辑上和集中式数据库系统一样，用户可以在任何一个场地执行全局应用。就好那些数据是存储在同一台计算机上，有单个数据库管理系统(DBMS)管理一样，用户并没有什么感觉不一样。 分布式数据库系统是在集中式数据库系统的基础上发展起来的，是计算机技术和网络技术结合的产物。分布式数据库系统适合于单位分散的部门，允许各个部门将其常用的数据存储在本地，实施就地存放本地使用，从而提高响应速度，降低通信费用。分布式数据库系统与集中式数据库系统相比具有可扩展性，通过增加适当的数据冗余，提高系统的可靠性。在集中式数据库中，尽量减少冗余度是系统目标之一．其原因是，冗余数据浪费存储空间，而且容易造成各副本之间的不一致性．而为了保证数据的一致性，系统要付出一定的维护代价．减少冗余度的目标是用数据共享来达到的。而在分布式数据库中却希望增加冗余数据，在不同的场地存储同一数据的多个副本,其原因是：①．提高系统的可靠性、可用性当某一场地出现故障时，系统可以对另一场地上的相同副本进行操作，不会因一处故障而造成整个系统的瘫痪。②．提高系统性能系统可以根据距离选择离用户最近的数据副本进行操作，减少通信代价，改善整个系统的性能。 分布式数据库具有以下几个特点： (1)、数据独立性与位置透明性。数据独立性是数据库方法追求的主要目标之一，分布透明性指用户不必关心数据的逻辑分区，不必关心数据物理位置分布的细节，也不必关心重复副本（冗余数据）的一致性问题，同时也不必关心局部场地上数据库支持哪种数据模型．分布透明性的优点是很明显的．有了分布透明性，用户的应用程序书写起来就如同数据没有分布一样．当数据从一个场地移到另一个场地时不必改写应用程序．当增加某些数据的重复副本时也不必改写应用程序．数据分布的信息由系统存储在数据字典中．用户对非本地数据的访问请求由系统根据数据字典予以解释、转换、传送． (2)、集中和节点自治相结合。数据库是用户共享的资源．在集中式数据库中，为了保证数据库的安全性和完整性，对共享数据库的控制是集中的，并设有DBA负责监督和维护系统的正常运行．在分布式数据库中，数据的共享有两个层次：一是局部共享，即在局部数据库中存储局部场地上各用户的共享数据．这些数据是本场地用户常用的．二是全局共享，即在分布式数据库的各个场地也存储可供网中其它场地的用户共享的数据，支持系统中的全局应用．因此，相应的控制结构也具有两个层次：集中和自治．分布式数据库系统常常采用集中和自治相结合的控制结构,各局部的DBMS可以独立地管理局部数据库，具有自治的功能．同时，系统又设有集中控制机制，协调各局部DBMS 的工作，执行全局应用。当然,不同的系统集中和自治的程度不尽相同．有些系统高度自治，连全局
从Google Spanner漫谈分布式存储与数据库技术 文/曹伟 Spanner 的设计反映了 Google 多年来在分布式存储系统领域上经验的积累和沉淀，它采用了 Megastore 的数据模型，Chubby 的数据复制和一致性算法，而在数据的可扩展性上使用了 BigTable 中的技术。新颖之处在于，它使用高精度和可观测误差的本地时钟来判断分布式系统中事件的先后顺序。Spanner 代表了分布式数据库领域的新趋势——NewSQL。 Spanner 是 Google 最近公开的新一代分布式数据库，它既具有 NoSQL 系统的可扩展性，也具有关系数据库的功能。例如，它支持类似 SQL 的查询语言、支持表连接、支持事务（包括分布式事务）。Spanner 可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性。一套 Spanner 集群可以扩展到上百个数据中心、百万台服务器和上T条数据库记录的规模。目前，Google 广告业务的后台（F1）已从 MySQL 分库分表方案迁移到了Spanner 上。 数据模型 传统的 RDBMS（例如 MySQL）采用关系模型，有丰富的功能，支持 SQL 查询语句。而NoSQL 数据库多是在 key-value 存储之上增加有限的功能，如列索引、范围查询等，但具有良好的可扩展性。Spanner 继承了 Megastore 的设计，数据模型介于 RDBMS 和 NoSQL 之间，提供树形、层次化的数据库 schema，一方面支持类 SQL 的查询语言，提供表连接等关系数据库的特性，功能上类似于 RDBMS；另一方面整个数据库中的所有记录都存储在同一个key-value 大表中，实现上类似于 BigTable，具有 NoSQL 系统的可扩展性。 在 Spanner 中，应用可以在一个数据库里创建多个表，同时需要指定这些表之间的层次关系。例如，图 1 中创建的两个表——用户表（Users）和相册表（Albums），并且指定用户表是相册表的父节点。父节点和子节点间存在着一对多的关系，用户表中的一条记录（一
分布式数据库系统（全文） 胡经国 本文作者的话 本文是根据有关文献和资料编写的《漫话云计算》系列文稿之一。以此作为云计算学习笔录，供云计算业外读者进一步学习和研究参考。希望能够得到大家的指教和喜欢！ 下面是正文 一、分布式数据库系统概述 1、概述一 分布式数据库（Distributed Database，DDB）是指数据分散存储在计算机网络中的各台计算机上的数据库。 分布式数据库系统（Distributed Database System，DDBS）通常使用较小的计算机系统，每台计算机可单独放在一个地方；每台计算机中都可能有DBMS （数据库管理系统）的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库；位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的、逻辑上集中、物理上分布的大型数据库系统。 2、概述二 分布式数据库，是指利用高速计算机网络，将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。 分布式数据库的基本思想，是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。 近年来，随着数据量的高速增长，分布式数据库技术也得到了快速的发展。传统的关系型数据库开始从集中式模型向分布式架构发展。基于关系型的分布式数据库，在保留传统数据库的数据模型和基本特征前提下，从集中式存储走向分布式存储，从集中式计算走向分布式计算。 另一方面，随着数据量越来越大，关系型数据库开始暴露出一些难以克服的缺点。以NoSQL为代表的、具有高可扩展性、高并发性等优势的非关系型数据库快速发展；一时间市场上出现了大量的key-value（键－值）存储系统、文档型数据库等NoSQL数据库产品。NoSQL类型数据库正日渐成为大数据时代下分布式数据库领域的主力。 这种按分布式组织数据库的方法克服了物理中心数据库组织的弱点。
腾讯分布式数据库TDSQL金融级能力的架构原理概述
目录
TDSQL是什么：腾讯如何打造一款金融级分布式数据库 我们先初步了解TDSQL产品，以及它的适用场景。第一章包括四个方面：使用场景、发展历程、核心特性，以及兼容性。 首先，TDSQL是腾讯推出的一款兼容MySQL的自主可控、高一致性分布式数据库产品。这里我们强调一点，高度兼容MySQL——TDSQL完全兼容MySQL协议，并且做到完全自主可控、数据强一致性。第二是TDSQL具备分布式的特性，具备一个弹性扩展、高可用的架构。在互联网行业，海量的用户流量场景很常见，如果数据库不具备可伸缩性、可扩展性，是很难应对如：电商的大型促销，春节抢红包等突增流量的场景，这些其实都是对数据库应对海量用户流量的考验。
目前TDSQL已经服务超过500+的金融政企，行业覆盖银行、保险、证券、政务、互联网金融等各个领域。 我们再看一下TDSQL的前世今生。TDSQL最早可以追溯到2002年，那个时候其实还不叫TDSQL，它是腾讯计费平台部的一个数据库服务，当时使用了开源的MySQL。2002年-2007年随着公司业务的发展，腾讯所面临的用户量的压力也越来越大。这个时候我们提出了7×24小时不宕机的高可用设计方案，来保证数据库能提供7×24小时不间断连续高可用服务。那个时候，腾讯的增值业务日渐成规模，业务对数据也越来越敏感，对数据可用性的要求越来越高，甚至平时还要防备一些像运营商的光纤被挖断等各种各样的异常场景。
在2007年-2012年，这可能是互联网时代从互联网到移动互联网的发展的快速5年。当然，公司的业务也是突飞猛进。我们开始把这个高可用的数据库产品化。到2012年，TDSQL的雏形就已经出来了，作为一款内部产品，开始在公司内部提供金融级的数据强一致性、可靠性服务。 从2012年起，TDSQL已经在腾讯内部做得已经比较成熟，已经是一个知名的产品了，但是它一直没有对外做商业化。2014年恰逢一个很好的机会——微众银行的成立。微众银行做数据库选型的时候关注到了TDSQL，经过反复测试验证，发现当时的TDSQL已经完全具备了微众银行对数据可用性和一致性的要求。借此机会，TDSQL成功在微众银行投产，成为微众银行唯一的数据库，覆盖了银行的核心业务。 所以说2014年，TDSQL完成了商业化，也实现了私有化部署。2014年以后，TDSQL推广到了很多银行、金融机构，这过程中是借鉴了2014年TDSQL在微众银行成功实施的宝贵的经验。 因为在2014年微众银行的部署中，我们也踩了很多坑，也认识到在私有化部署环境的各种各样的挑战，并一一攻克了这些挑战。当2014年在私有化部署完成之后，再到2015年TDSQL上公有云，我们继续通过公有云服务打磨自己的产品。