数据库包含的三级模式分别是什么

数据库领域公认的标准结构是三级模式结构，它包括外模式、概念模式、内模式，有效地组织、管理数据，提高了数据库的逻辑独立性和物理独立性。用户级对应外模式，概念级对应概念模式，物理级对应内模式，使不同级别的用户对数据库形成不同的视图

三种模式分别指：外模式：外模式又称子模式或用户模式，对应于用户级。它是某个或某几个用户所看到的数据库的数据视图，是与某一应用有关的数据的逻辑表示。外模式是从模式导出的一个子集，包含模式中允许特定用户使用的那部分数据。用户可以通过外模式描述语言来描述、定义对应于用户的数据记录(外模式)，也可以利用数据 *** 纵语言(DataLanguage，DML)对这些数据记录进行 *** 作。外模式反映了数据库的用户观。

概念模式

模式又称概念模式或逻辑模式，对应于概念级。它是由数据库设计者综合所有用户的数据，按照统一的观点构造的全局逻辑结构，是对数据库中全部数据的逻辑结构和特征的总体描述，是所有用户的公共数据视图(全局视图)。它是由数据库管理系统提供的数据模式描述语言(DataDescriptionLanguage，DDL)来描述、定义的，体现、反映了数据库系统的整体观。

内模式

内模式又称存储模式，对应于物理级，它是数据库中全体数据的内部表示或底层描述，是数据库最低一级的逻辑描述，它描述了数据在存储介质上的存储方式和物理结构，对应着实际存储在外存储介质上的数据库。内模式由内模式描述语言来描述、定义，它是数据库的存储观。

在一个数据库系统中，只有唯一的数据库，因而作为定义、描述数据库存储结构的内模式和定义、描述数据库逻辑结构的模式，也是唯一的，但建立在数据库系统之上的应用则是非常广泛、多样的，所以对应的外模式不是唯一的，也不可能是唯一的。

分布式是架构部署模式的一种。分布式多用于描述架构设计上，当然现在有各种新用法。

集群是硬件部署模式的一种，是集中部署在一个机房里的计算机群体的集中称谓。

分布式网站集群系统是一种多网站架构模式，支持生成独立网站、多个网站,完成各个网站横向一体化和纵向一体化网站群的构建，主站、子站、网站间的信息可共享和信息互联。

简单的说：就是一个企业/个人可以像申请博客那样自助建站，维护，更新，而分布式，就是把问题分开解决的意思，即系统分布在几个不同服务器上。

编者按 ：本文由「高可用架构后花园」群讨论整理而成。

有人的地方，就有江湖

有江湖的地方，就有纷争

在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？

具体业务场景如下，比如一个业务 *** 作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。

在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。

强一致

弱一致性

最终一致性

在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如 MySQL 主从同步）又有一定区别，群友的讨论分成以下 6 种解决方案。

业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说，则可以将服务 A、B、C 整合为一个服务 D 给业务，这个服务 D 再通过转换为本地事务的方式，比如服务 D 包含本地服务和服务 E，而服务 E 是本地服务 A ~ C 的整合。

优点： 解决（规避）了分布式事务。

缺点： 显而易见，把本来规划拆分好的业务，又耦合到了一起，业务职责不清晰，不利于维护。

由于这个方法存在明显缺点，通常不建议使用。

此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。

消息日志方案的核心是保证服务接口的幂等性。

考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。

eBay 方式的主要思路如下。

Base：一种 Acid 的替代方案

此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章，是一篇解释 BASE 原则，或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。

如果 ACID 为分区的数据库提供一致性的选择，那么如何实现可用性呢？答案是

BASE (basically available, soft state, eventually consistent)

BASE 的可用性是通过 支持局部故障 而不是系统全局故障来实现的。下面是一个简单的例子：如果将用户分区在 5 个数据库服务器上，BASE 设计鼓励类似的处理方式，一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法，不过它确实可以带来更高的可感知的系统可用性。

文章中描述了一个最常见的场景，如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。

文中提出了一个经典的解决方法，将主要修改 *** 作以及更新用户表的消息 放在一个本地事务 来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性， 增加一个更新记录表 updates_applied 来记录已经处理过的消息。

系统的执行伪代码如下

（点击可全屏缩放）

基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。

在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条 *** 作记录到 updates_applied，事务执行成功之后再删除队列。

通过以上方法，达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。

随着业务规模不断地扩大，电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里，现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。

拆分首先要面临的是什么呢？

最开始的单体应用所有功能都在一起，存储也在一起。比如运营要取消某个订单，那直接去更新订单表状态，然后更新库存表就 ok 了。因为是单体应用，库在一起，这些都可以在一个事务里，由关系数据库来保证一致性。

但拆分之后就不同了，不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库，而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了，而不是直接去 *** 作库。这就涉及一个『 分布式事务 』的问题。

分布式事务有两种解决方式

1 优先使用异步消息。

上文已经说过，使用异步消息 Consumer 端需要实现幂等。

幂等有两种方式， 一种方式是业务逻辑保证幂等 。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。

另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现 。对于 producer 端在业务数据库的同实例上放一个消息库，发消息和业务 *** 作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。

2 有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。 这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。

比如 A 同步调用 B，C。A 本地事务成功的时候更新本地事务记录状态，B 和 C 同样。如果有一次 A 调用 B 失败了，这个失败可能是 B 真的失败了，也可能是调用超时，实际 B 成功。则由一个中心服务对比三方的事务记录表，做一个最终决定。假设现在三方的事务记录是 A 成功，B 失败，C 成功。那么最终决定有两种方式，根据具体场景：

对 b 场景做一个特殊说明：比如 B 是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候库存已经变为 0，无法重试成功，这个时候只有回滚 A 和 C 了。

那么可能有人觉得在业务库的同实例里放消息库或事务记录库，会对业务侵入，业务还要关心这个库，是否一个合理的设计？

实际上可以依靠运维的手段来简化开发的侵入，我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库，通过框架层（消息的客户端或事务 RPC 框架）透明的在背后 *** 作这个库，业务开发人员只需要关心自己的业务逻辑，不需要直接访问这个库。

总结起来，其实两种方式的根本原理是类似的，也就是 将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性 。

交易创建的一般性流程

我们把交易创建流程抽象出一系列可扩展的功能点，每个功能点都可以有多个实现（具体的实现之间有组合/互斥关系）。把各个功能点按照一定流程串起来，就完成了交易创建的过程。

面临的问题

每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢？比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理？再比如锁券成功了，但是扣减库存失败了，该如何处理？

方案选型

服务依赖过多，会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务，9 个都执行成功了，最后一个执行失败了，那么是不是前面 9 个都要回滚掉？这个成本还是非常高的。

所以在拆分大的流程为多个小的本地事务的前提下，对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。

消息通知往往不能保证 100% 成功；且消息通知后，接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决；后者可以选用事务消息来保证。

所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中，锁券和扣减库存是这样的两个典型场景。

要保证多个系统间数据一致，乍一看，必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升；在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时的最终一致性。

我们在交易创建流程中， 首先创建一个不可见订单 ，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。

业界常用的还有支付宝的一种 xts 方案，由支付宝在 2PC 的基础上改进而来。主要思路如下，大部分信息引用自官方网站。

分布式事务服务简介

分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 JAR 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。

核心特性

传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下，ACID 模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题，但是 2PC 是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模达到千万级以上时，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。基于此，我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案，这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。

简单的说，DTS 框架有如下特性：

以下是分布式事务框架的流程图

实现

与 2PC 协议比较

1 电商业务

公司的支付部门，通过接入其它第三方支付系统来提供支付服务给业务部门，支付服务是一个基于 Dubbo 的 RPC 服务。

对于业务部门来说，电商部门的订单支付，需要调用

从业务规则上需要同时保证业务数据的实时性和一致性，也就是支付成功必须加积分。

我们采用的方式是同步调用，首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付，由积分平台提供增加与回撤接口。

具体的流程是先调用积分平台增加用户积分，再调用支付平台进行支付处理，如果处理失败，catch 方法调用积分平台的回撤方法，将本次处理的积分订单回撤。

(点击可以全屏缩放)

2 用户信息变更

分布式服务对衍生的配套系统要求比较多，特别是我们基于消息、日志的最终一致性方案，需要考虑消息的积压、消费情况、监控、报警等。

In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability

英文版 ： >

一：表中应该避免可为空的列；二：表不应该有重复的值或者列；三：表中记录应该有一个唯一的标识符在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分

每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值

另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序

否则的话，很容易产生ID值不统一的情况

另外，在数据库设计的时候，最好还能够加入行号

如在销售订单管理中，ID号是用户不能够维护的

但是，行号用户就可以维护

如在销售订单的行中，用户可以通过调整行号的大小来对订单行进行排序

通常情况下，ID列是以1为单位递进的

但是，行号就要以10为单位累进

如此，正常情况下，行号就以10、20、30依次扩展下去

若此时用户需要把行号为30的纪录调到第一行显示

此时，用户在不能够更改ID列的情况下，可以更改行号来实现

如可以把行号改为1，在排序时就可以按行号来进行排序

如此的话，原来行号为30的纪录现在行号变为了1，就可以在第一行中显示

这是在实际应用程序设计中对ID列的一个有效补充

这个内容在教科书上是没有的

需要在实际应用程序设计中，才会掌握到这个技巧

四：数据库对象要有统一的前缀名一个比较复杂的应用系统，其对应的数据库表往往以千计

若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难

而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼

为此，笔者建立，在开发数据库之前，最好能够花一定的时间，去制定一个数据库对象的前缀命名规范

如笔者在数据库设计时，喜欢跟前台应用程序协商，确定合理的命名规范

笔者最常用的是根据前台应用程序的模块来定义后台数据库对象前缀名

如跟物料管理模块相关的表可以用M为前缀;而以订单管理相关的，则可以利用C作为前缀

具体采用什么前缀可以以用户的爱好而定义

但是，需要注意的是，这个命名规范应该在数据库管理员与前台应用程序开发者之间达成共识，并且严格按照这个命名规范来定义对象名

其次，表、视图、函数等最好也有统一的前缀

如视图可以用V为前缀，而函数则可以利用F为前缀

如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象

五：尽量只存储单一实体类型的数据这里将的实体类型跟数据类型不是一回事，要注意区分

这里讲的实体类型是指所需要描述对象的本身

笔者举一个例子，估计大家就可以明白其中的内容了

如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象

若用户要把这两个实体对象信息放在同一张表中也是可以的

如可以把表设计成图书名字、图书作者等等

可是如此设计的话，会给后续的维护带来不少的麻烦

如当后续有图书出版时，则需要为每次出版的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度

而且若作者的情况有所改变，如住址改变了以后，则还需要去更改每本书的记录

若这个作者的图书从数据库中全部删除之后，这个作者的信息也就荡然无存了

很明显，这不符合数据库设计规范化的需求

遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等

如此设计以后，以上遇到的所有问题就都引刃而解了

最佳回答：回答是：在一般情况下，传统集中式数据利用高端硬件设备保证数据可靠性对。3394

1 传统集中式数据库面临的挑战

优势：

成熟稳定：经过近40年的发展，应用到了几乎所有的行业，已经被打磨的非常成熟稳定，生态很完善；

行业适配性强：适配不同行业的各种需求；

生态完善：拥有大量的ISV应用开发商和技术开发者，技术生态、产业生态和人才生态都很完善。

的差异

1 数据库是核心的IT基础设施

在这里插入描述

• 互联网业务增长，带动核心系统升级

• 核心系统引入数据库分布式与云化改造，支撑横向平滑扩展

在这里插入描述

• 5G规模推广，带动IT系统升级

• 5G具备大带宽和超低延时等能力，需要数据库系统提升响应速度和并发能力

在这里插入描述

• 打造智慧政府

• 实现智慧政府为目标的“互联网+”业务构建，对于数据库的性能和扩展提出了更高的要求

2 传统集中式数据库面临的挑战

21 传统数据库架构

在这里插入描述

22 优势

• 成熟稳定：经过近40年的发展，应用到各行各业，产品技术非常成熟稳定

• 行业适配性强：适配不同行业的各种需求

• 生态完善：拥有大量的ISV应用开发商和技术开发者，技术生态、产业生态和人才生态都很完善

23 劣势

成本高：自身软件售价高，同时依托于高端硬件，CAPEX和OPEX成本高昂

无法横向扩展：容量的提升只能依靠提升设备自身的性能（增加CPU/内存/硬盘，或从PC服务器升级为小型机等），一定能碰到单点的上限

3 使用数据库中间件的分库分表方案依然有短板

在这里插入描述

• 使用通用的数据库，可以实现数据库线性的扩容；

• 数据库是单点数据库，数据库之间没有联系，不知道其他数据库的存在，依靠中间件完成需要跨库的事务；

• 数据库中间件连接各个数据库，实现分库分表。

31 优势

线性扩展：通过分库分表，可以快速实现数据库的水平扩展

技术成本低：不需要改造核心数据库引擎，或者只需要做很少的改造

32 劣势

跨库分布式事务：数据库核心引擎没有分布式能力，只能通过中间件来完成分布式处理，但中间件难以做到RPO=0，因此在遇到异常和故障时无法100%保证分布式事务的ACID能力

全局一致性：由于多个数据库服务器的时间戳不一致，因此很难保证多个库之间数据版本号的全局一致性

负载均衡：扩容和缩容时，底层数据库引擎无法在线调整数据分布规则，因此需要暂停业务并重新导数据，对业务和运维挑战很大

跨库复杂SQL：跨库的复杂SQL运算（比如多表做分片键无关的关联查询）只能在中间件完成，而中间件不具备分布式并行计算能力，最终会限制应用对SQL的使用，产生业务侵入性

4 原生的分布式关系型数据库架构

在这里插入描述

41 优势

数据高可靠+服务高可用：多副本一致性协议Paxos的工业级实现，个别节点发生故障时保证数据零丢失（RPO=0）和服务快速恢复（RTO<30秒）

线性扩容：随着业务量增加进行扩容（比如线上促销期间），随着业务量减少进行缩容（比如促销后）

低成本：基于普通X86服务器保证高可用性，无需使用高端小型机和存储

全局一致性：支持分布式事务，确保全局一致性，支持分布式复杂查询灵活的部署方式：支持三中心、五中心、主备等多种部署模式

对业务透明：业务系统可以像使用单点数据库一样使用分布式数据库，业务迁移改造成本低

5 OceanBase和传统数据库的对比

传统集中式数据库 以OceanBase为代表的分布式数据库

产品架构 经典的“单点集中式”架构，采用“全共享（Share-Everything）”架构。构建于高端的硬件基础之上，比如IBM高端服务器和EMC高端存储设备等 原生的“分布式”数据库，采用业界最严格的Paxos分布式一致性协议基于普通PC硬件的设计，不需要高端硬件

数据可靠性和服务高可用性 利用高端硬件设备保证数据可靠性采用“主从复制”，主节点故障的情况下，会有数据损失（RPO>0）；不能自动恢复服务，服务恢复时间（RTO）通常以小时为单位计算 以普通PC硬件为基础，利用Paxos分布式一致性协议保证数据可靠性

主节点故障的情况下，Paxos可以保证数据无损（即RPO=0)，并且自动选举并恢复服务，服务恢复时间（RTO）在30秒以内

扩展性 数据存储只能在单点内实现纵向扩展，最终必然触达单点架构下的容量上限。计算节点通常无法扩展。少数模式下（如RAC，pureScale）可做计算节点扩展，但多个计算节点之间仍需访问单点共享存储，并且可扩展的计算节点数量有限 数据节点和计算节点均可以在MPP架构下实现水平扩展数据节点和计算节点均没有数量限制，在网络带宽足够的前提下，可以扩充至任意数目

应用场景 集中在企业客户（金融、电信、政企等）的核心系统，无法应付互联网业务场景，应用案例很少 支付宝核心、网商银行核心、阿里巴巴的众多业务，以及多家外部商业银行。逐渐迈向传统业务

使用成本 比较昂贵，需要支付高端基础硬件的费用、高昂的软件授权费用以及产品服务费用 相对较低，基于PC硬件的设计降低了硬件费用，软件授权费用和服务费用也有优势

6 小结

传统集中式数据库经过近40年的发展，已经非常成熟。但在当前这个大数据的时代，传统数据库依然面临较多挑战，分布式数据库可以有效解决这些问题，是未来数据库发展的重点方向

1：传统数据库往往对硬件基础设施有较高要求，同时只能纵向扩展，无法横向扩展，容易达到性能上限；

2：分库分表虽然可以横向扩展了，但也有带来了不支持复杂SQL、较难保证分布式事务的ACID等新问题；

3：分布式数据库可以有效解决这些问题，应用可以像使用集中式数据库一样使用分布式数据库，分布式数据库具有低硬件成本、高可扩展性、高可用性等特性。

文章知识点与官方知识档案匹配

云原生入门技能树首页概览

8775 人正在系统学习中

点击

劣势：

数据库系统的三级模式结构是指数据库系统是由模式、外模式和内模式三级构成的

数据库的二级映像功能与数据独立性为了能够在内部实现数据库的三个抽象层次的联系和转换，数据库管理系统在这三级模式之间提供了两层映像。

事务处理（TRANSACTION）是由一个或多个SQL语句序列结合在一起所形成的一个逻辑处理单元。事务处理中的每个语句都是完成整个任务的一部分工作，所有的语句组织在一起能够完成某一特定的任务。DBMS在对事务处理中的语句进行处理时，是按照下面的约定来进行的，这就是“事务处理中的所有语句被作为一个原子工作单位，所有的语句既可成功地被执行，也可以没有任何一个语句被执行”。DBMS负责完成这种约定，即使在事务处理中应用程序异常退出，或者是硬件出现故障等各种意外情况下，也是如此。在任何意外情况下，DBMS都负责确保在系统恢复正常后，数据库内容决不会出现“部分事务处理中的语句被执行完”的情况。

以上就是关于数据库包含的三级模式分别是什么全部的内容，包括:数据库包含的三级模式分别是什么、分布式数据库与集群数据库之间的关系(分布式数据库和关系型数据库)、保证分布式系统数据一致性的6种方案等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！