数据库学习--数据库基本概念

数据库管理系统(DBMS)

数据库管理系统(Database Management System,DBMS)是一种操纵和管理数据库的大型软件，是用于建立、使用和维护数据库。它对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。用户通过dbms访问数据库中的数据，数据库管理员也通过dbms进行数据库的维护工作。它提供多种功能，可使多个应用程序和用户用不同的方法在同时或不同时刻去建立，修改和询问数据库。它使用户能方便地定义和操纵数据，维护数据的安全性和完整性，以及进行多用户下的并发控制和恢复数据库。

特点

• Database语言提供：
  数据库（Database）语言是指向DBMS发出指令的语言。主要由下面3方面组成数据定义语言（DDL），数据操作语言（DML），数据控制语言（DCL）
• 数据完整性：
  防止不正确的数据的登录和更新
• 事务处理：
  提供多个用户之间数据的共享。多个用户可以同时访问或更新同一个数据并且不会产生冲突。
• 安全性：
  提供用户访问权限功能和用户认证功能，一些DBMS也提供数据加密功能
• 灾难恢复：
  可以从事务处理，系统和存储系统的灾害中恢复数据
• 分布式数据库
  在网络上使用多台主机，并将他们作为一个虚拟DBMS来实行

事务（Transaction）

一个最小的不可再分的工作单元；通常一个事务对应一个完整的业务(例如银行账户转账业务，该业务就是一个最小的工作单元)
一个完整的业务需要批量的DML(insert、update、delete)语句共同联合完成
事务只和DML语句有关，或者说DML语句才有事务。这个和业务逻辑有关，业务逻辑不同，DML语句的个数不同

事务四大特征（ACID）

• 原子性：事务是最小单位，不可再分
• 一致性：事务要求所有的DML语句操作的时候，必须保证同时成功或者同时失败
• 隔离性：事务A和事务B之间具有隔离性
• 持久性：事务的保证，事务中介的标志（内存的数据持久到硬盘文件中）

事务的术语

开启事务：Start Transaction
事务结束：End Transaction
提交事务：Commit Transaction
回滚事务：Rollback Transaction

隔离性（isolation）

1.事务A和事务B之间一定具有隔离性
2.隔离性有隔离级别（4个）

• 读未提交：read uncommitted
  1.事物A和事物B，事物A未提交的数据，事物B可以读取到
  2.这里读取到的数据叫做“脏数据”
  3.这种隔离级别最低，这种级别一般是在理论上存在，数据库隔离级别一般都高于该级别

• 读已提交：read committed
  1.事物A和事物B，事物A提交的数据，事物B才能读取到
  2.这种隔离级别高于读未提交
  3.换句话说，对方事物提交之后的数据，我当前事物才能读取到
  4.这种级别可以避免“脏数据”
  5.这种隔离级别会导致“不可重复读取”
  6.Oracle默认隔离级别

• 可重复读：repeatable read
  1.事务A和事务B，事务A提交之后的数据，事务B读取不到
  2.事务B是可重复读取数据
  3.这种隔离级别高于读已提交
  4.换句话说，对方提交之后的数据，我还是读取不到
  5.这种隔离级别可以避免“不可重复读取”，达到可重复读取
  6.比如1点和2点读到数据是同一个
  7.MySQL默认级别
  8.虽然可以达到可重复读取，但是会导致“幻像读”

• 串行化：serializable
  1.事务A和事务B，事务A在操作数据库时，事务B只能排队等待
  2.这种隔离级别很少使用，吞吐量太低，用户体验差
  3.这种级别可以避免“幻像读”，每一次读取的都是数据库中真实存在数据，事务A与事务B串行，而不并发

隔离级别的作用范围

• 事务隔离级别的作用范围分为两种：
– 全局级：对所有的会话有效
– 会话级：只对当前的会话有效

MVCC的介绍

1.什么是MVCC

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存.

MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

2.什么是当前读和快照读

• 当前读
  像select lock in share mode(共享锁), select for updateupdate , insert ,delete(排他锁)这些操作都是一种当前读，为什么叫当前读？就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。

• 快照读
  像不加锁的select操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC,可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不加粗样式一定是数据的最新版本，而有可能是之前的历史版本

说白了MVCC就是为了实现读-写冲突不加锁，而这个读指的就是快照读, 而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现

3.当前读，快照读和MVCC的关系

• 确的说，MVCC多版本并发控制指的是 “维持一个数据的多个版本，使得读写操作没有冲突” 这么一个概念。仅仅是一个理想概念
• 而在MySQL中，实现这么一个MVCC理想概念，我们就需要MySQL提供具体的功能去实现它，而快照读就是MySQL为我们实现MVCC理想模型的其中一个具体非阻塞读功能。而相对而言，当前读就是悲观锁的具体功能实现
• 要说的再细致一些，快照读本身也是一个抽象概念，再深入研究。MVCC模型在MySQL中的具体实现则是由 3个隐式字段，undo日志 ，Read View 等去完成的，具体可以看下面的MVCC实现原理

MVCC能解决什么问题

数据库并发场景有三种，分别为：

• 读-读：不存在任何问题，也不需要并发控制
• 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
• 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失

MVCC带来的好处是？

多版本并发控制（MVCC）是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。 所以MVCC可以为数据库解决以下问题

• 在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能
• 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题

MVCC的实现原理

MVCC的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3个隐式字段，undo日志 ，Read View 来实现的。所以我们先来看看这个三个point的概念。

隐式字段

每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段

• DB_TRX_ID
  6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID

• DB_ROLL_PTR
  byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里）

• DB_ROW_ID
  6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引

• 实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了

DB_ROW_ID是数据库默认为该行记录生成的唯一隐式主键，DB_TRX_ID是当前操作该记录的事务ID,而DB_ROLL_PTR是一个回滚指针，用于配合undo日志，指向上一个旧版本

undo日志

undo log主要分为两种：

• insert undo log
  代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃

• update undo log
  事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

purge

• 从前面的分析可以看出，为了实现InnoDB的MVCC机制，更新或者删除操作都只是设置一下老记录的deleted_bit，并不真正将过时的记录删除。
• 为了节省磁盘空间，InnoDB有专门的purge线程来清理deleted_bit为true的记录。为了不影响MVCC的正常工作，purge线程自己也维护了一个read
  view（这个read view相当于系统中最老活跃事务的read
  view）;如果某个记录的deleted_bit为true，并且DB_TRX_ID相对于purge线程的read view可见，那么这条记录一定是可以被安全清除的。

对MVCC有帮助的实质是update undo log ，undo log实际上就是存在rollback segment中旧记录链，它的执行流程如下：

一、 比如一个有个事务插入persion表插入了一条新记录，记录如下，name为Jerry, age为24岁，隐式主键是1，事务ID和回滚指针，我们假设为NULL

二、 现在来了一个事务1对该记录的name做出了修改，改为Tom

• 在事务1修改该行(记录)数据时，数据库会先对该行加排他锁
• 然后把该行数据拷贝到undo log中，作为旧记录，既在undo log中有当前行的拷贝副本
• 拷贝完毕后，修改该行name为Tom，并且修改隐藏字段的事务ID为当前事务1的ID, 我们默认从1开始，之后递增，回滚指针指向拷贝到undo log的副本记录，既表示我的上一个版本就是它
• 事务提交后，释放锁

三、 又来了个事务2修改person表的同一个记录，将age修改为30岁

• 在事务2修改该行数据时，数据库也先为该行加锁
• 然后把该行数据拷贝到undo log中，作为旧记录，发现该行记录已经有undo log了，那么最新的旧数据作为链表的表头，插在该行记录的undo log最前面
• 修改该行age为30岁，并且修改隐藏字段的事务ID为当前事务2的ID, 那就是2，回滚指针指向刚刚拷贝到undo log的副本记录
• 事务提交，释放锁

从上面，我们就可以看出，不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，既链表，undo log的链首就是最新的旧记录，链尾就是最早的旧记录

Read View(读视图)

什么是Read View，说白了Read View就是事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大)

所以我们知道 Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个Read View读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，既可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

Read View遵循一个可见性算法，主要是将要被修改的数据的最新记录中的DB_TRX_ID（即当前事务ID）取出来，与系统当前其他活跃事务的ID去对比（由Read View维护），如果DB_TRX_ID跟Read View的属性做了某些比较，不符合可见性，那就通过DB_ROLL_PTR回滚指针去取出Undo Log中的DB_TRX_ID再比较，即遍历链表的DB_TRX_ID（从链首到链尾，即从最近的一次修改查起），直到找到满足特定条件的DB_TRX_ID, 那么这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本

SCN

SCN（System Change Number 简称 SCN）是当Oracle数据库更新后，由DBMS自动维护去累积递增的一个数字。在Oracle中，有四种SCN，分别为：系统检查点SCN、数据文件检查点SCN、启动SCN、终止SCN。

Oracle中的SCN（system change number）相当于数据库中的一个时钟，只不过不是用时分秒来计量，这种内部时钟机制，可称为逻辑时钟，每个数据库都有一个全局SCN生成器，本质上就是不重复的数字。

四种SCN

• 系统检查点SCN：
  系统检查点SCN位于控制文件中，当检查点进程启动时(ckpt)，Oracle就把系统检查点的SCN存储到控制文件中。该SCN是全局范围的，当发生文件级别的SCN时，例如将表空间置于只读状态，则不会更新系统检查点SCN。

• 数据文件检查点scn：
  当ckpt进程启动时，包括全局范围的（比如日志切换）以及文件级别的检查点（将表空间置为只读、begin backup或将某个数据文件设置为offline等），这时会在控制文件中记录的scn。

• 结束scn：
  每个数据文件都有一个结束scn，在数据库的正常运行中，只要数据文件在线且是可读写的，结束scn为null。否则则存在具体的scn值。结束scn也记录在控制文件中。

• 启动scn：
  不同于上述的SCN数据文件开始scn记录在每个数据文件中。当发生系统及文件级别的检查点后，不仅将这时的SCN号记录在控制文件中，同样也记录在数据文件中。

数据库高可用概念

数据库高可用原理

高可用是一种系统，在经过专门的设计之后，可以让系统的可用性从99.9%上升至99.999%，从而减少了系统停机的时间。一般可用性系统每年停机时间为8.8小时，而高可用性系统每年停机时间仅5.3分钟，相较而言，系统服务的高度可用性得到了保证。与此同时，高可用性系统尽可能的缩短了因日常维护、突发情况所导致的停机时间。实现高可用主要通过以下三种方式：
1.双机热备方式
工作原理：该方式需要主机和备用机，称为“双机”，其中的一台主机处于工作状态，备用机处于监控准备状态。当主机出现宕机的情况时，备用机便接管主机的工作，等到主机维修至正常状态时，备用机再将工作传递回主机。主机与备用机间交接工作时所用的切换方式由使用者设定，交接的数据通过共享存储的方式保证其完整性和一致性。但是，由于主机一般不存在经常性宕机的情况，因此备用机长期处于监控准备状态，也就是不工作的状态，就导致了资源的浪费。
2.双机双工方式
工作原理：该方式需要两台主机，二者同时运行着各自的工作，与此同时，随时监控着对方的工作状态。当其中一台主机出现宕机的情况，另一台主机则直接接管出现宕机情况的主机的工作，并且要保证工作的质量。因此，该方式对两台主机的性能要求较高，要有一定的性能冗余，才不会在接管另一台主机的工作时也出现宕机的情况。两台主机接管工作时的数据都存放在共享存储中。
3.集群系统方式
工作原理：该方式有多台主机同时工作，当其中一台主机出现宕机情况时，其他的主机则直接接管它的工作，在该主机修复完成后，系统会自动给它分配新的任务。相较于以上两种方式，该方式的不同之处就在于，交接出去的工作不会再传递回来，该主机将接收新的工作。

数据库高可用功能

高可用性是系统的一个特性，保证系统能在足够长的时间内提供指定程度的服务等级。再细化一下，可以说是在有限的故障条件下，提供一定等级的稳定服务.。对于应用层来说，根据业务特点可以很方便地设计成无状态的服务，在大多数互联网公司中，在业务层的最上层使用动态DNS、LVS、HAProxy等负载均衡组件，配合Docker和Kubernetes实现弹性伸缩，能够很容易实现应用服务的高可用。而数据库能能够做到高可用性的关键就在其有着消除单点问题、自动故障恢复、在线扩容、在线表结构变更、数据量大的解决方案等几个特殊性的功能，拿在线扩容举例，随着数据库的数据量越来越大，Scale是不可避免的问题。对于数据库来说，技术层面最大的追求就在于如何不停服务地对数据库节点进行Scale操作，这是非常有挑战性的事情。以中间件/Proxy方案来说，很多时候不得不提前对数据量进行规划，把扩容作为重要的计划来做，从DBA到运维到测试到开发人员，很早之前就要做相关的准备工作，真正扩容时为了保证数据安全，经常会选择停服务来保证没有新的数据写入，新的实例数据同步后还要做数据的一致性校验。当然业界大公司有足够雄厚的技术实力，可以采用更自动化的方案，将扩容停机时间尽量缩短（但很难缩减到0），但大部分中小互联网公司和传统企业依然无法避免较长时间的停服务问题。TiDB完全实现了在线的弹性扩容，主要基于Placement Driver的调度和Raft算法。

主要技术以及适应场景

数据库高可用是一个复杂的系统工程，其基本技术主要有： HADR、 HACMP、 数据复制，存储层容灾和DPF高可用。在不同场景，不同的业务连续性级别下，可以组合使用这几种技术，以实现从存储，网络，系统，数据库到应用的高可用技术。

CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

• 一致性（C）：
  在分布式系统中的所有数据备份，在同一时刻是否同样的值，即写操作之后的读操作，必须返回该值。（分为弱一致性、强一致性和最终一致性）
• 可用性（A）
  在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• 分区容忍性（P）
  以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

取舍策略

2.1、CA without P： 如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库RDBMS：Oracle、MySQL就是CA。

2.2、CP without A： 如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

2.3、 AP wihtout C： 要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

主要矛盾-Consistency和Availability

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

1. 数据库事务一致性需求 —— 很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。
2. 数据库的写实时性和读实时性需求 —— 对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
3. 对复杂的SQL查询，特别是多表关联查询的需求 —— 任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

与数据库的关系

传统的关系型数据库（CA）在功能支持上通常很宽泛，从简单的键值查询，到复杂的多表联合查询再到事务机制的支持。而与之不同的是，NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现）。
　　传统的SQL数据库的事务通常都是支持ACID的强事务机制。A代表原子性，即在事务中执行多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行；C代表一致性，即保证进行事务的过程中整个数据库的状态是一致的，不会出现数据花掉的情况;I代表隔离性，即两个事务不会相互影响，覆盖彼此数据等；D表示持久化，即事务一旦完成，那么数据应该是被写到安全的，持久化存储的设备上（比如磁盘）。
　　NoSQL系统仅提供对行级别的原子性保证，也就是说同时对同一个Key下的数据进行的两个操作，在实际执行的时候是会串行的执行，保证了每一个Key-Value对不会被破坏。

解决方案——BASE

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果。

**核心思想：**即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

4.1、基本可用Basically Available

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子。

• 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
• 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

4.2、软状态Soft state

软状态也称弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

4.3、最终一致性Eventually consistent

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

亚马逊首席技术官Werner
Vogels在于2008年发表的一篇文章中对最终一致性进行了非常详细的介绍。他认为最终一致性时一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够胡渠道最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因素。

在实际工程实践中，最终一致性存在以下五类主要变种。

因果一致性：

因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。

读己之所写：

读己之所写是指，进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者而言，其读取到的数据一定不会比自己上次写入的值旧。因此，读己之所写也可以看作是一种特殊的因果一致性。

会话一致性：

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

单调读一致性：

单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

单调写一致性：

单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。
以上就是最终一致性的五类常见的变种，在时间系统实践中，可以将其中的若干个变种互相结合起来，以构建一个具有最终一致性的分布式系统。事实上，可以将其中的若干个变种相互结合起来，以构建一个具有最终一致性特性的分布式系统。事实上，最终一致性并不是只有那些大型分布式系统才设计的特性，许多现代的关系型数据库都采用了最终一致性模型。

在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。在同步方式中，数据的复制通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么很显然，从备库中读取的的数据将是旧的，因此就出现了不一致的情况。当然，无论是采用多次重试还是认为数据订正，关系型数据库还是能搞保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性使相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。

七、Raft、Paxos协议概念

1. Paxos算法

Paxos算法是莱斯利·兰伯特（英语：Leslie Lamport，LaTeX中的“La”）于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。用于解决在多个节点间确定一个值。

Paxos算法包含2个部分：

• Basic Paxos算法，描述的是多个节点之间如何就某个值（提案value）达成共识。
• Multi-Paxos思想，注意Multi-Paxos是一种思想，而不是一种算法。Multi-Paxos算法是一个统称，它是指基于Multi-Paxos思想，通过执行多个Basic Paxos实例，实现一系列值的共识的算法。

相比而言，Basic Paxos协议更加复杂，且相对效率较低，所以现在所有和paxos有关的协议，一定是基于Multi-paxos来实现的。

Paxos算法中的角色：

• 提议者（Proposer）: 提议一个值，用于投票表决

• 接受者（Acceptor）：对每个提议的值进行投票，并存储接收的值

• 学习者（Leaner） : 被告知投票的结果。接收达成共识的值。存储保存，不参与投票的过程。一般来说，学习者是数据备份的节点，比如Mater-Slave模型中的slave，被动的接收数据，用于存储备份。

Raft算法

Raft算法是在Multi-Paxos思想的基础上，做了一些简化和限制，比如增加了日志必须是连续的，在理解和算法实现上都相对容易许多。

Raft算法是现在分布式系统开发首选的共识算法。

从本质上说，Raft算法是通过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致。Raft算法是强领导者模型，集群中只能有一个"霸道总裁"。

Raft算法支持三种状态：

• 领导者（Leader）: 工作内容包括3部分，处理写请求、管理日志复制、不断地发送心跳信息。心跳信息实际上是延迟跟随者的过期时间，从而实现告诉跟随者“我是领导者，我还活着”。

• 跟随者（Follower）: 接收处理来自领导者的消息，当等待领导者心跳信息超时的时候，就主动站出来，推荐自己当候选人

• 候选人（Candidate）: 向其他节点发送请求通票（RequestVote）RPC消息，通知其他节点来投票，如果赢得了大多数选票，就晋升当领导者

OLTP

On-Line Transaction Processing联机事务处理过程(OLTP)

也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。

这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(Real time System)。衡量联机事务处理结果的一个重要指标是系统性能，具体体现为实时请求-响应时间(Response Time)，即用户在终端上输入数据之后，到计算机对这个请求给出答复所需要的时间。OLTP是由前台、应用、数据库共同完成的，处理快慢以及处理程度取决于数据库引擎、服务器、应用引擎。

OLTP 数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。

OLTP特征

支持大量并发用户定期添加和修改数据。

反映随时变化的单位状态，但不保存其历史记录。

包含大量数据，其中包括用于验证事务的大量数据。

结构复杂。

可以进行优化以对事务活动做出响应。

提供用于支持单位日常运营的技术基础结构。

个别事务能够很快地完成，并且只需访问相对较少的数据。OLTP 旨在处理同时输入的成百上千的事务。

实时性要求高。

数据量不是很大。

交易一般是确定的，所以OLTP是对确定性的数据进行存取。(比如存取款都有一个特定的金额)

并发性要求高并且严格的要求事务的完整、安全性。(比如这种情况：有可能你和你的家人同时在不同的银行取同一个帐号的款)。

OLAP

联机分析处理OLAP是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多维信息的快速分析的特征。其中F是快速性(Fast)，指系统能在数秒内对用户的多数分析要求做出反应；A是可分析性(Analysis)，指用户无需编程就可以定义新的专门计算，将其作为分析的一部 分，并以用户所希望的方式给出报告；M是多维性(Multi—dimensional)，指提供对数据分析的多维视图和分析；I是信息性(Information)，指能及时获得信息，并且管理大容量信息。

OLAP系统按照其存储器的数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型。

ROLAP

ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。

MOLAP

MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构，从物理层实现起，因此又称为物理OLAP（PhysicalOLAP）；而ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（VirtualOLAP）。

HOLAP

由于MOLAP和ROLAP有着各自的优点和缺点（如下表所示）,且它们的结构迥然不同，这给分析人员设计OLAP结构提出了难题。为此一个新的OLAP结构——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止，对HOLAP还没有一个正式的定义。但很明显，HOLAP结构不应该是MOLAP与ROLAP结构的简单组合，而是这两种结构技术优点的有机结合，能满足用户各种复杂的分析请求。

OLTP与OLAP对比

HTAP

数据库系统一般可以按照负载类型分成操作型数据库（Operational Support System）和决策型数据库（Decision Support System）。操作型数据库主要用于应对日常流水类业务，主要是面向消费者类的业务；决策型数据库主要应对的是企业报表类，可视化等统计类业务，主要面向企业类的业务。

针对两类系统的数据管理和系统设计方式都有很大差异。 (1）对OLTP的数据模型采用基本的约束E-R图模型，而OLAP的数据模型则需要采用特殊的“星型模型”，数据立方等数据仓库相关的技术。 （2）对OLTP的数据存储通常采用行式组织，而OLAP采用列式组织。 （3）OLTP的业务通常对实时要求比OLAP高很多。 （4）传统的数据库，为了同时支持两类业务。通常采用两个数据源, 分别对两套系统进行优化设计。

OLTP的数据定期会通过etl（提取，转换，加载）工具把数据同步导入OLAP系统中。这就涉及到数据源滞后的问题。 OLAP的数据滞后，导致分析出来的结果时效性不够，对决策支持类系统的要求不够。比如说，双11期间，用户购物的行为和推荐系统的推荐结果之间的时间差越短，越有可能提高销量。

HTAP是混合 OLTP 和 OLAP 业务同时处理的系统，2014年Garnter公司给出了严格的定义：混合事务/分析处理(HTAP)是一种新兴的应用体系结构，它打破了事务处理和分析之间的“墙”。它支持更多的信息和“实时业务”的决策。

直接在单一数据源上不加区分的处理TP和AP的方案，目前还不能有效实现。

当前的方案是进行一个折中。采用快照的方式，分开处理OLTP和OLAP请求。让OLAP的请求在OLTP的最新的一致性快照上执行。同时对外暴露一套接口，从而从逻辑来看是一套系统。虽然内部是分开处理OLTP和OLAP的。

这种折衷方案，重要的一点，就是保证快照是尽可能的保持“新”，快照不能太过滞后OLTP的数据。这就需要系统频繁的做快照操作。

目前两种流行的方案，一个是采用linux的系统快照能力，提供HTAP服务的方案，比如Hyper数据库系统。另一种是类似hana的方案，定期生成增量数据，然后合并到AP系统

RDBMS

RDBMS(Relational Database Management System)，关系数据库管理系统，是管理关系数据库的计算机软件，常见的关系数据库管理系统有：Oracle,SQL Server等。关系数据（RDBMS）是表的汇集，其中每一表被赋予一个唯一的名字，每个表都包含一组属性，并且存放大量的元组。关系表中的每个元组代表一个对象，由一个唯一的关键字来标识，并被一组属性值描述。RDBMS就是为了管理这样的表单组成的database而存在的。

对于RDBMS而言，具有的特性是：ACID

对于RSBMS而言，主要优点在于关系结构比较明显，易于管理，，但缺点在于海量数据的时候，性能不佳，扩展性不强；对于NoSQL而言，主要是随着海量数据的出现而出现的，因为可以方便的扩展数据库，而具有很重要的应用场景。

NoSQL

NoSQL(Not Only SQL),不仅仅是SQL，是一种非关系型数据库，没有预定义的模式，是一种键-值对存储模型，更适合于文档数据库，类似于JSON格式的存储，具有很高的性能，高可用性以及伸缩性的问题。

对于NoSQL而言，具有的特性：BASE

具体解释来说，BA为基本可用（Basically Avaible），因为有CAP理论我们可知，一个分布式系统而言，不可能很好的满足一致性，可用性和分区容错性三个需求，最多同时满足二个，其特性指明，NoSQL数据库对于可用性及一致性的弱要求原则。S为软状态，(Soft-state)可以理解为无连接的状态，E表示(Eventual Consistency)，最终一致性。

NoSql与RDBMS的对比

NoSql出现的原因是因为有很多应用不需要使用RDBMS的特性（强一致性以及join查询），而这些特性还成为了阻碍（如join限制了分片等）,以下对比了两种数据库的特性，以便于更好地进行技术选型。

特性	RDBMS	NoSql
强一致事务	支持，ACID特性	不支持，BASE特性
SQL语句（跨表join）	支持	支持
水平扩展（分片）	较难支持，但也有proxy等方案可以支持	较容易支持，MongoDB天然支持分片
数据结构	按照关联关系设计表，便于多表join查询，表结构确定。	将有较多关联的数据放到一个文档中，只支持单文档查询。文档的结构可以灵活增删。
业务场景	数据实体之间存在的关联较多，每个实体之间有自己的生命周期。eg: 顾客与订单。	数据实体之间存在的关联较少，实体之间的关系更多的是类似于值属性之间的关系，即某些‘实体’实际上没有自己的生命周期，可以嵌入到它的主实体中。eg: 顾客与联系方式。

Middleware

概念

中间件，也就是处于中间的软件，通过位置而非功能或特性来定义。中间件根据不同的功能又可以分为不同的种类，比如服务中间件Tomcat，消息中间件MQ等，这里主要讨论数据库中间件

数据库平台需要解决以下三个问题

• 可以为各个服务提供高性能、大容量、高可用的数据访问
• 满足增量数据的订阅与消费，比如缓存数据一致性的需求
• 异地，异构数据源的同步

类别

分库分表
分库分表中间件主要负责与上层应用交互，屏蔽读写分离或者分库分表的底层实现细节，对开发人员透明，像操作单库单表一样去操作数据。分库分表中间件除了基本的分库分表功能，还可以提供读写分离、水平扩容等功能。
典型的分库分表中间件有两种设计方案：

• 直接为应用提供依赖，如Java中引入Jar文件，使用特定代理数据源，内部管理多个普通数据源（c3p0、druid、dbcp等），每个数据源各自与不同的库建立连接。典型代表有网易的DDB和阿里的TDDL等。
• 单独部署代理服务，应用层通过标准JDBC访问代理，代理服务根据数据库（如MySQL）的标准通信协议解析请求，再转发到集群中的各个分库分表。典型代表有阿里Cobar，Mycat（基于Cobar）等。

数据增量
关于数据增量订阅/消费通过一个应用场景来说明。

为了提高查询效率，应对高并发，通常会把热点数据放入缓存中（如从MySQL数据中查询出数据，载入到Redis），如果数据变更该如何通知Redis进行缓存更新？

• 一般思路：更新数据时，先更新database，然后再更新redis。这样实现思路最简单，但是database与缓存操作耦合度很高，并且如何保证database与cache的数据一致性。

• 其他思路：在MySQL主从复制的实现方案中，Slave会读取Master的二进制日志文件（binlog），从而实现两者数据同步。同样的我们可以模拟一个Slave来订阅database的binlog，进而执行CURD操作，更新cache中数据。

典型的中间件有阿里Canal（支持MySQL），Erosa（支持Oracle）等。

数据同步
数据同步可以实现跨（同）机房同步以及异地容灾备份、分流等功能。可以涉及多种数据库，处理之后的数据也可以以多种形式存储。某种程度上，数据增量订阅/消费也可以看做是一种数据同步，典型的数据同步中间件有Otter，JingoBus，DRC等。

数据迁移
相同数据库之间的数据迁移较为简单，如MySQL主备同步，更改相应的配置即可，难点是异构数据库（甚至是不同数据源）之间的数据迁移。典型的中间件有yugong，DataX等。

NewSQL

NewSQL 是对各种新的可扩展/高性能数据库的简称，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。

NewSQL是指这样一类新式的关系型数据库管理系统，针对OLTP（读-写）工作负载，追求提供和NoSQL系统相同的扩展性能，且仍然保持ACID和SQL等特性

系统分类

NewSQL系统虽然在的内部结构变化很大，但是它们有两个显着的共同特点：(1)它们都支持关系数据模型，(2) 它们都使用SQL作为其主要的接口。已知的第一个NewSQL系统叫做H-Store，它是一个分布式并行内存数据库系统。目前NewSQL系统大致分三类：

新构架
第一类型的NewSQL系统是全新的数据库平台，它们均采取了不同的设计方法。它们大概分两类：

• 这类数据库工作在一个分布式集群的节点上，其中每个节点拥有一个数据子集。 SQL查询被分成查询片段发送给自己所在的数据的节点上执行。这些数据库可以通过添加额外的节点来线性扩展。现有的这类数据库有： Google Spanner, VoltDB, Clustrix, NuoDB.
• 这些数据库系统通常有一个单一的主节点的数据源。它们有一组节点用来做事务处理，这些节点接到特定的SQL查询后，会把它所需的所有数据从主节点上取回来后执行SQL查询，再返回结果。

SQL引擎

第二类是高度优化的SQL存储引擎。这些系统提供了MySQL相同的编程接口，但扩展性比内置的引擎InnoDB更好。这类数据库系统有：TokuDB, MemSQL。

透明分片

这类系统提供了分片的中间件层，数据库自动分割在多个节点运行。这类数据库包扩：ScaleBase，dbShards, Scalearc。

RTO和RPO

概述：恢复时间目标(RTO)和恢复点目标(RPO)，故障后需要RTO恢复业务到正常状态。丢失数据到最近一次数据备份对应的时间则是RPO。

RTO：恢复时间目标

RTO指的是可以中断或关闭多少时间而不会对业务造成重大损害。有些业务可能会停机数天而不会产生严重的后果。而一些高优先级的业务只能停下来几秒钟，就会导致巨大损失。

RTO不仅仅是业务损失和恢复之间的持续时间。这个目标还包括IT部门必须采取的步骤来恢复应用程序及其数据。如果IT已经投入高优先级应用程序的故障转移服务，那么它们可以在几秒钟内安全地表达RTO(IT部门必须恢复本地环境，但由于应用程序正在云中进行处理，因此IT部门可能需要一些时间)。

企业的RTO任务是根据优先级和潜在业务损失对应用程序进行分类，并相应地匹配企业的资源。例如，接近零的RTO的典型计划将需要故障转移服务。4小时RTO允许从裸机恢复开始进行本地恢复，并以完整的应用程序和数据可用性结束。对于8小时以上的RTO，IT团队可以与本地系统集成商签署维护合同。

RPO：恢复点目标

恢复点目标是指企业的损失容限：在对业务造成重大损害之前可能丢失的数据量。该目标表示为从丢失事件到最近一次在前备份的时间度量。

如果以定期计划的24小时增量备份全部或大部分数据，那么在最坏的情况下，企业将丢失24小时的数据。对于某些应用来说，这是可以接受的，对于其他人来说并不是这样。

例如，如果企业的应用程序具有4小时RPO，那么备份和数据丢失之间的间隔时间将为4小时。拥有4小时的RPO并不一定意味着企业将失去4小时的数据。例如一个文字处理应用程序在午夜停止运行并在凌晨出现故障，那么可能没有丢失太多(或任何)数据。但是如果一个任务繁忙的应用程序在上午10点关闭并且直到下午2点才恢复，那么企业可能会失去4个小时的高价值并且可能无法替代的数据。在这种情况下，需要进行更加频繁的备份，以便访问特定于应用程序的RPO。

这取决于应用优先级，单个RPO的范围通常为24小时、12小时、8小时、4小时。以秒为单位测量到接近零。只要对生产系统的影响最小，8小时以上的RPO就可以利用现有的备份解决方案。4小时的RPO将需要计划的快照复制，而接近零的RPO将需要连续复制。在RPO和RTO都接近于零的情况下，将连续复制与故障转移服务结合使用，以实现接近100%的应用程序和数据可用性。

RTO和RPO如何相似以及不同的原因

(1)RTO和RPO的几个特征

恢复时间和恢复点目标因应用程序和数据优先级而异。即使是大公司也不能为所有应用程序提供接近零的RTO或RPO，也不应该这样做。

确保100%正常运行时间(RTO)和没有丢失数据(RPO)的唯一方法是投资连续数据复制功能的故障转移虚拟环境。
IT优先处理应用程序和数据以匹配所实现的RTO和RPO的费用。请注意，优先事项不仅取决于收入，还取决于风险。企业可能不经常使用应用程序，但如果其数据受到管制，那么数据丢失可能会导致巨额罚款。

RTO和RPO均以时间为单位进行测量。对于RTO来说，其度量标准是应用程序失败和包括数据恢复在内的完整可用性之间的时间量。RPO也以时间单位来衡量。度量标准是数据丢失和前一次备份之间的时间间隔。对于RTO和RPO来说，其应用程序/数据优先级可直接转换为更短的时间单位。

(2)RTO和RPO的目标存在巨大的差异

尽管它们有相似之处，但RPO和RTO服务于不同的目标。RTO涉及应用程序和系统，但主要描述应用程序停机时间的限制。

RPO主要与失败事件后丢失的数据量有关。

SLA

服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。

QPS，TPS

TPS

TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问.

TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。

QPS

全名 Queries Per Second，意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

简单的说，QPS = req/sec = 请求数/秒。它代表的是服务器的机器的性能最大吞吐能力。

QPS与TPS的区别

TPS是每秒处理事务数，包括了从请求服务器->服务器处理->返回给用户这个过程，每秒能完成多少个这个过程就是多少TPS
QPS跟TPS类似，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，这些请求会计为QPS

Shared Everything和share-nothing

Shared Everthting:一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer

Shared Disk：各个处理单元使用自己的私有 CPU和Memory，共享磁盘系统。典型的代表Oracle Rac， 它是数据共享，可通过增加节点来提高并行处理的能力，扩展能力较好。其类似于SMP（对称多处理）模式，但是当存储器接口达到饱和的时候，增加节点并不能获得更高的性能 。

Shared Nothing：各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP（大规模并行处理）模式，各处理单元之间通过协议通信，并行处理和扩展能力更好。典型代表DB2 DPF和hadoop ，各节点相互独立，各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转。

我们常说的 Sharding 其实就是Share Nothing架构，它是把某个表从物理存储上被水平分割，并分配给多台服务器（或多个实例），每台服务器可以独立工作，具备共同的schema，比如MySQL Proxy和Google的各种架构，只需增加服务器数就可以增加处理能力和容量。