对于数据库来说，关系型数据库对于保证数据完整性和一致性方面表现是最好的！
数据的完整性




完整性分类
具体描述
如何保证




实体完整性
每个实体都是独一无二的
主键 / 唯一索引（唯一约束）


参照完整性（引用完整性）
子表中不能有父表中没有的数据
外键


域完整性
数据都是有效的
数据类型和长度、非空约束、默认值约束、检查约束


数据的一致性：
数据的一致性通过事务实现 —> 一系列的对数据进行的不可分割的操作，要么全做，要么全部做
事务的ACID特性：




事物的特性
描述




Atomicity（原子性）
不可分割


Consistency（一致性）
事务前后数据状态保持一致


Isolation（隔离性）
多个并发的事务不知道彼此的中间状态


Duration（持久性）
事务完成后，对数据的修改要持久化


并发事务访问数据可能产生五大类的问题：

第一类丢失更新
第二类丢失更新
脏读（读脏数据）
不可重复读
幻读

如何解决这五类问题

单版本并发控制 - 锁 - 悲观锁 - 性能太差
多版本并发控制（MVCC）- 乐观锁 - 性能更好 - 需要冗余字段来支持

直接操作锁非常的麻烦，我们可以通过设置事务隔离级别的方式，让数据库自动选择合适的锁机制来保护数据。




事物的隔离级别
特点




read uncommitted
可以读到脏数据


read committed
Oracle默认的隔离级别  -不能避免不可重复读现象，但不会读到脏数据


repeatable read
避免不可重复读现象（ MySQL默认的事物隔离级别） 另一个事物更新数据，刚才查到的是什么，现在还是什么（查询事物没有提交和回滚之前都可以重复读）


serializable
此种方法不会出现并发数据的问题，但是效率地下，不建议使用


MySQL如何查看和修改事务隔离级别（transaction —> tx）




功能
方法




查看事物隔离级别
select @@tx_isolation


修改事物隔离级别
set session transaction isolation level read committed


在Linux环境下验证不同事物隔离级别的特性所需要使用到的命令




事物过程
相关命令




开事物
begin; / start transaction；


提交事物
commit；


回滚事物
rollback；（未提交之前，取消前面的操作，如更新或删除操作）


linux下面验证的场景举例：

数据库连接：mysql -u root -p
第一个实验场景：读脏数据
事物A：
begin；
update tb_emp set sal=2800 where eno = 1359;
事物B：
set session transaction isolation level read committed;
begin;
select * from tb_emp;       --->读脏数据
commit;
事物A:
rollback;

第二个实验场景：不可重复读
事物B：
set session transaction isolation level read committed;
begin;
select * from tb_emp where sal<3000;
事物A：
begin；
update tb_emp set sal=3800 where eno=1359;
commit;
事物B：
select * from tb_emp where sal<3000; --->没有1359对应的记录了，不可重复读
commit；

第三个实验场景：可以重复读
事物B：
set session transaction isolation level repeatable read;
begin;
select * from tb_emp where sal<3000;
事物A：
begin；
update tb_emp set sal=3800 where eno=1359;
commit;
事物B：
select * from tb_emp where sal<3000; --->还可以读到最开始使用select使用此命令读到的内容
commit；

欢迎支持笔者新作：《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》，同时欢迎关注笔者的微信公众号：朱小厮的博客。

什么是数据一致性?
  在数据有多分副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副本写入成功，部分副本写入失败。这就造成各个副本之间的数据不一致，数据内容冲突。 实践中，导致数据不一致的情况有很多种，表现样式也多种多样，比如数据更新返回操作失败，事实上数据在存储服务器已经更新成功。
CAP定理
  CAP定理是2000年，由 Eric Brewer 提出来的。Brewer认为在分布式的环境下设计和部署系统时，有3个核心的需求，以一种特殊的关系存在。这里的分布式系统说的是在物理上分布的系统，比如我们常见的web系统。

  这3个核心的需求是：Consistency，Availability和Partition Tolerance，赋予了该理论另外一个名字 － CAP。

  Consistency：一致性，这个和数据库ACID的一致性类似，但这里关注的所有数据节点上的数据一致性和正确性，而数据库的ACID关注的是在在一个事务内，对数据的一些约束。系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读取到最新值。

  Availability：可用性，每一个操作总是能够在一定时间内返回结果。需要注意“一定时间”和“返回结果”。“一定时间”是指，系统结果必须在给定时间内返回。“返回结果”是指系统返回操作成功或失败的结果。

  Partition Tolerance：分区容忍性，是否可以对数据进行分区。这是考虑到性能和可伸缩性。

  CAP定理认为，一个提供数据服务的存储系统无法同事满足数据一致性、数据可用性、分区容忍性。

  为什么不能完全保证这个三点了，个人觉得主要是因为一旦进行分区了，就说明了必须节点之间必须进行通信，涉及到通信，就无法确保在有限的时间内完成指定的行文，如果要求两个操作之间要完整的进行，因为涉及到通信，肯定存在某一个时刻只完成一部分的业务操作，在通信完成的这一段时间内，数据就是不一致性的。如果要求保证一致性，那么就必须在通信完成这一段时间内保护数据，使得任何访问这些数据的操作不可用。

  如果想保证一致性和可用性，那么数据就不能够分区。一个简单的理解就是所有的数据就必须存放在一个数据库里面，不能进行数据库拆分。这个对于大数据量，高并发的互联网应用来说，是不可接受的。

  在大型网站应用中，数据规模总是快速扩张的，因此可伸缩性即分区容忍性必不可少，规模变大以后，机器数量也会变得庞大，这是网络和服务器故障会频繁出现，要想保证应用可用，就必须保证分布式处理系统的高可用性。所以在大型网站中，通常会选择强化分布式存储系统的可用性(A)和伸缩性§，在某种程度上放弃一致性©。一般来说，数据不一致通常出现在系统高并发写操作或者集群状态不稳（故障恢复、集群扩容等）的情况下，应用系统需要对分布式数据处理系统的数据不一致性有所了解并进行某种意义上的补偿和纠错，以避免出现应用系统数据不正确。
数据一致性模型
  一些分布式系统通过复制数据来提高系统的可靠性和容错性，并且将数据的不同的副本存放在不同的机器，由于维护数据副本的一致性代价高，因此许多系统采用弱一致性来提高性能，一些不同的一致性模型也相继被提出。
强一致性： 要求无论更新操作实在哪一个副本执行，之后所有的读操作都要能获得最新的数据。
弱一致性：用户读到某一操作对系统特定数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。
最终一致性：是弱一致性的一种特例，保证用户最终能够读取到某操作对系统特定数据的更新。
数据一致性实现技术
Quorum系统NRW策略
  这个协议有三个关键字N、R、W。
N代表数据所具有的副本数。
R表示完成读操作所需要读取的最小副本数，即一次读操作所需要参与的最小节点数目。
W表示完成写操作所需要写入的最小副本数，即一次写操作所需要参与的最小节点数目。
  该策略中，只需要保证R+W>N，就可以保证强一致性。

  例如：N=3，W=2，R=2，那么表示系统中数据有3个不同的副本，当进行写操作时，需要等待至少有2个副本完成了该写操作系统才会返回执行成功的状态，对于读操作，系统有同样的特性。由于R + W > N，因此该系统是可以保证强一致性的。

  R + W> N会产生类似Quorum的效果。该模型中的读（写）延迟由最慢的R(W)副本决定，有时为了获得较高的性能和较小的延迟，R和W的和可能小于N，这时系统不能保证读操作能获取最新的数据。

  如果R + W > N，那么分布式系统就会提供强一致性的保证，因为读取数据的节点和被同步写入的节点是有重叠的。在关系型数据管理系统中，如果N=2，可以设置为W=2，R=1，这是比较强的一致性约束，写操作的性能比较低，因为系统需要2个节点上的数据都完成更新后才将确认结果返回给用户。

  如果R + W ≤ N，这时读取和写入操作是不重叠的，系统只能保证最终一致性，而副本达到一致的时间则依赖于系统异步更新的实现方式，不一致性的时间段也就等于从更新开始到所有的节点都异步完成更新之间的时间。

R和W的设置直接影响系统的性能、扩展性与一致性。如果W设置为1，则一个副本完成更改就可以返回给用户，然后通过异步的机制更新剩余的N-W的副本；如果R设置为1，只要有一个副本被读取就可以完成读操作，R和W的值如较小会影响一致性，较大则会影响性能，因此对这两个值的设置需要权衡。

下面为不同设置的几种特殊情况:

1. 当W=1,R=N时，系统对写操作有较高的要求，但读操作会比较慢，若N个节点中有节点发生故障，那么读操作将不能完成。

2. 当R=1,W=N时，系统对读操作有较高性能、高可用，但写操作性能较低，用于需要大量读操作的系统，若N个节点中有节点发生故障，那么些操作将不能完成。

3. 当R=Q,W=Q(Q=N/2+1)时，系统在读写性能之间取得平衡，兼顾了性能和可用性。

两阶段提交算法
  在两阶段提交协议中，系统一般包含两类机器（或节点）：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与者（participants，cohorts或workers），一般包含多个，在数据存储系统中可以理解为数据副本的个数。两阶段提交协议由两个阶段组成，在正常的执行下，这两个阶段的执行过程如下所述：
阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）。

在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
阶段2：提交阶段（commit phase）。

在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。
  举个例子：A组织B、C和D三个人去爬长城：如果所有人都同意去爬长城，那么活动将举行；如果有一人不同意去爬长城，那么活动将取消。用2PC算法解决该问题的过程如下：
首先A将成为该活动的协调者，B、C和D将成为该活动的参与者。
阶段1：A发邮件给B、C和D，提出下周三去爬山，问是否同意。那么此时A需要等待B、C和D的邮件。B、C和D分别查看自己的日程安排表。B、C发现自己在当日没有活动安排，则发邮件告诉A它们同意下周三去爬长城。由于某种原因，D白天没有查看邮件。那么此时A、B和C均需要等待。到晚上的时候，D发现了A的邮件，然后查看日程安排，发现周三当天已经有别的安排，那么D回复A说活动取消吧。
阶段2：此时A收到了所有活动参与者的邮件，并且A发现D下周三不能去爬山。那么A将发邮件通知B、C和D，下周三爬长城活动取消。此时B、C回复A“太可惜了”，D回复A“不好意思”。至此该事务终止。
  两阶段提交算法在分布式系统结合，可实现单用户对文件（对象）多个副本的修改，多副本数据的同步。其结合的原理如下：
客户端（协调者）向所有的数据副本的存储主机（参与者）发送：修改具体的文件名、偏移量、数据和长度信息，请求修改数据，该消息是1阶段的请求消息。
存储主机接收到请求后，备份修改前的数据以备回滚，修改文件数据后，向客户端回应修改成功的消息。如果存储主机由于某些原因（磁盘损坏、空间不足等）不能修改数据，回应修改失败的消息。
客户端接收发送出去的每一个消息回应，如果存储主机全部回应都修改成功，向每存储主机发送确认修改的提交消息；如果存在存储主机回应修改失败，或者超时未回应，客户端向所有存储主机发送取消修改的提交消息。该消息是2阶段的提交消息。
存储主机接收到客户端的提交消息，如果是确认修改，则直接回应该提交OK消息；如果是取消修改，则将修改数据还原为修改前，然后回应取消修改OK的消息。
客户端接收全部存储主机的回应，整个操作成功。
  在该过程中可能存在通信失败，例如网络中断、主机宕机等诸多的原因，对于未在算法中定义的其它异常，都认为是提交失败，都需要回滚，这是该算法基于确定的通信回复实现的，在参与者的确定回复（无论是回复失败还是回复成功）之上执行逻辑处理，符合确定性的条件当然能够获得确定性的结果哲学原理。

  缺点：单个A是个严重问题：没有热备机制，A节点宕机了或者链接它的网络坏了会阻塞该事务；吞吐量不行，没有充分发动更多A的力量，一旦某个A第一阶段投了赞成票就得在它上面加独占锁，其他事务不得接入，直到当前事务提交or回滚。
分布式锁服务
  分布式锁是对数据被外界修改持保守态度，在整个数据处理过程中将数据处于锁定状态，在用户修改数据的同时，其它用户不允许修改。

  采用分布式锁服务实现数据一致性，是在操作目标之前先获取操作许可，然后再执行操作，如果其他用户同时尝试操作该目标将被阻止，直到前一个用户释放许可后，其他用户才能够操作目标。分析这个过程，如果只有一个用户操作目标，没有多个用户并发冲突，也申请了操作许可，造成了由于申请操作许可所带来的资源使用消耗，浪费网络通信和增加了延时。

  采用分布式锁实现多副本内容修改的一致性问题， 选择控制内容颗粒度实现申请锁服务。例如我们要保证一个文件的多个副本修改一致， 可以对整个文件修改设置一把锁，修改时申请锁，修改这个文件的多个副本，确保多个副本修改的一致，修改完成后释放锁；也可以对文件分段，或者是文件中的单个字节设置锁， 实现更细颗粒度的锁操作，减少冲突。

  常用的锁实现算法有Lamport bakery algorithm （俗称面包店算法）， 还有Paxos算法以及乐观锁。下面对其原理做简单概述。
1.  Lamport面包店算法
  是解决多个线程并发访问一个共享的单用户资源的互斥问题的算法。 由Leslie Lamport（英语：Leslie Lamport）发明。

  这个算法也可以称为时间戳策略，或者叫做Lamport逻辑时钟。

  这里先陈述一下这个逻辑时钟的内容：

  我们用分布式系统中的事件的先后关系，用“->”符号来表示，例如：若事件a发生在事件b之前，那么a->b.

  该关系需要满足下列三个条件：
如果a和b是同一进程中的事件，a在b之前发生，则a->b
如果事件a是消息发送方，b是接收方，则a->b
对于事件a、b、c,如果有a->b,b->c,则有a->c
  注意，对于任何一个事件a，a -> a都是不成立的，也就是说，关系->是反自反的。有了上面的定义，我们也可以定义出“并发”(concurrent)的概念了：

对于事件a、b，如果a -> b，b -> a两个都不成立，那么a和b就是并发的。

  直观上，上面的->关系非常好理解，即“xxx在xxx之前发生”。也就是说，一个系统在输入I1下，如果有a->b，那么对于这个系统的同一个输入I1，无论重复运行多少次，a也始终发生在b之前；如果在输入I1下a和b是并发的，则表示在同一个输入I1下的不同运行中，a可能在b之前，也可能在b之后，也可能恰好同时发生。也就是，并发并不是指一定同时发生，而是表示一种不确定性。->和并发的概念，就是我们理解一个系统时最基础的概念之一了。

  有了上面的概念，我们可以给系统引入时钟了。这里的时钟就是lamport逻辑时钟。一个时钟，本质上是一个事件到实数（假设时间是连续的）的函数。这个函数将每个事件映射到一个数字，代表这个事件发生的时间。形式一点来说，对于每个进程Pi，都有一个时钟Ci，这个时钟将该进程中的事件a映射到Ci(a)。而整个系统的时钟C=<　C0, C1, …, Cn>，对于一个事件b，假设b属于进程Pj，那么C(b) =Cj(b)。
  这里插一句，从这个定义也可以看到大师对分布式系统的理解。分布式系统中不存在一个“全局”的实体。在该系统中，每个进程都是一个相对独立的实体，它们有自己的本地信息（本地Knowledge）。而整个系统的信息则是各个进程的信息的一个聚合。

  有了时钟的一个“本质定义”还不够，我们需要考虑，什么样的时钟是一个有意义的，或者说正确的时钟。其实，有了前文的->关系的定义，正确的时钟应满足的条件已经十分明显了：

  时钟条件：对于任意两个事件a，b，如果a -> b，那么C(a) < C(b)。

  注意，反过来讲这个条件可不成立。如果我们要求反过来也成立，即“如果a -> b为假，那么C(a) < C(b)也为假”，那就等于要求并发事件必须同时发生，这显然是不合理的。

  结合前文->关系的定义，我们可以把上面的条件细化成如下两条：
如果a和b是进程Pi中的两个事件，并且在Pi中，a在b之前发生，那么Ci(a) < Ci(b)；
如果a是Pi发送消息m，b是Pj接收消息m，那么Ci(a) < Cj(b)；
  上面就定义了合理的逻辑时钟。显然，一个系统可以有无数个合理的逻辑时钟。实现逻辑时钟也相对简单，只要遵守两条实现规则就可以了：
每个进程Pi在自己的任何两个连续的事件之间增加Ci值；
如果事件a是Pi发送消息m，那么在m中应该带上时间戳Tm=Ci(a)；如果b是进程Pj接收到消息m，那么，进程Pj应该设置Cj为大于max(Tm,Cj(b))。
  有了上面逻辑时钟的定义，我们现在可以为一个系统中所有的事件排一个全序，就是使用事件发生时的逻辑时钟读数进行排序，读数小的在先。当然，此时可能会存在两个事件同时发生的情况。如果要去除这种情况，方法也非常简单：如果a在进程Pi中，b在进程Pj中，Ci(a) = Cj(b)且i < j，那么a在b之前。形式化一点，我们可以把系统事件E上的全序关系“=>”定义为：

  假设a是Pi中的事件，b是Pj中的事件，那么：a => b当且仅当以下两个条件之一成立：
Ci(a) < Cj(b)；
Ci(a) = Cj(b) 且 i < j；
  Lamport把上面这些数理逻辑时钟的概念以非常直观地类比为顾客去面包店采购。面包店只能接待一位顾客的采购。已知有n位顾客要进入面包店采购，安排他们按照次序在前台登记一个签到号码。该签到号码逐次加1。根据签到号码的由小到大的顺序依次入店购货。完成购买的顾客在前台把其签到号码归0. 如果完成购买的顾客要再次进店购买，就必须重新排队。

  这个类比中的顾客就相当于线程，而入店购货就是进入临界区独占访问该共享资源。由于计算机实现的特点，存在两个线程获得相同的签到号码的情况，这是因为两个线程几乎同时申请排队的签到号码，读取已经发出去的签到号码情况，这两个线程读到的数据是完全一样的，然后各自在读到的数据上找到最大值，再加1作为自己的排队签到号码。为此，该算法规定如果两个线程的排队签到号码相等，则线程id号较小的具有优先权。

  把该算法原理与分布式系统相结合，即可实现分步锁。

  注意这个系统中需要引入时钟同步，博主的意见是可以采用SNTP实现时钟同步（非权威，仅供参考）。
2.Paxos算法
  该算法比较热门，类似2pc算法的升级版，在此不做赘述，可以自行搜索相关资料。(博主会在之后整理列出)

  需要注意的是这个算法也是Leslie Lamport提出的，由此可见这位大师之牛逼！

  Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。一个典型的场景是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中，是分布式计算中的重要问题。节点通信存在两种模型：共享内存(Shared memory)和消息传递(Messages passing)。Paxos算法就是一种基于消息传递模型的一致性算法。BigTable使用一个分布式数据锁服务Chubby，而Chubby使用Paxos算法来保证备份的一致性。

  不仅只用在分布式系统，凡是多个过程需要达成某种一致性的都可以用到Paxos 算法。一致性方法可以通过共享内存（需要锁）或者消息传递实现，Paxos 算法采用的是后者。下面是Paxos 算法适用的几种情况：一台机器中多个进程/线程达成数据一致；分布式文件系统或者分布式数据库中多客户端并发读写数据；分布式存储中多个副本响应读写请求的一致性。
3. 采用乐观锁原理实现的同步
  我们举个例子说明该算法的实现原理。如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用前面的分布式锁服务机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。

  乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

  对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。
操作员 A 此时将其读出（version=1 ），并从其帐户余额中扣除 $50（$100-$50 ）。
在操作员 A 操作的过程中，操作员B也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。这样，就避免了操作员 B 用基于version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。
欢迎支持笔者新作：《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》，同时欢迎关注笔者的微信公众号：朱小厮的博客。

维护数据完整性

一、概述
数据的完整性，是指存储在数据库中的数据的正确性和可靠性，它是衡量数据中数据质量的一种标准。数据完整性可以分为四类。


1、实体完整性，实体完整性的目的是确保数据库中所有实体的唯一性，也就是不应出现完全相同的数据记录。


2、区域完整性，匹配完整性要求数据表中的数据位于某一个特定的允许范围内。


3、参考完整性，是用来维护相关数据表之间数据一致性的手段，通过实现参考完整性，可以避免因一个数据表的记录改变而造成另一个数据表内的数据变成无效值。


4、用户自定义完整性，用户自定义由用户根据实际应用中的需要自行定义。


二、利用约束维护数据完整性


第一种：字段级约束，只能作用于一个字段。
第二种：数据级的约束；分为：
1、主键约束，使用数据表中的一列数据或多列数据来唯一标识一行数据。在数据表中不能存在主键相同的两行数据，主键不能为ＮＵＬＬ。


２、外键约束，主要用来实现数据的区域完整性和引用完整性。如果确定了数据表中某一个字段将作为该数据表与其他数据表关联时使用的外键，则该字段的聚会范围将决定于关联数据表中该字段的取值范围。外键可以与另一张表上的主键约束建立联系，也可以与另一张表上的唯一约束建立联系。当一行新的数据被加入到表中，或对表中已经存在的外键上的数据进行修改时，新的数据必须存在于另一张表的主键上，或者为ＮＵＬＬ。


３、唯一约束，主要用来确保非主键字段中的唯一性。唯一约束可以用来同时约束一个或多个非主键字段中数据的唯一性，而主键约束只允许一个字段数据的唯一性或多个字段组合在一起的唯一性；使用唯一约束的字段中允许出现ＮＵＬＬ值，而在使用主键约束时，字段中不允许出现ＮＵＬＬ值。


４、检查(CHECK)约束，检查约束通过检查输入数据字段值来维护数据的完整性，以确保只有符合条件的数据才能够进入数据表。它通常是通过一个逻辑表达式的结果是否为真来判断是否符合条件。与外键约束不同，外键约束是从另一张表上获得合理的数据，而检查约束则是通过对一个表达式的结果进行判断来对数据进行检查。


三、利用规则维护数据完整性




规则限制了可以存储在表中或用户定义数据类型的值，它可以使用多种方式　来完成对数据值的检验，可以使用函数返回验证信息，也可以使用关键字BETWEEN, LIKE, IN完成对输入数据的检查。


规则是数据库对象之一，它的作用与ＣHECK约束的部分功能相同，在向表的某列插入或更新数据时，用它来限制输入的新值的取值范围，但规则作为单独的数据库对象来实现，在一列上只能使用一个规则却可以使用多个CHECK，另外，规则可以应用于多个示例，还可以应用于用户自定义的数据类型，而CHECK只能应用于它定义的列。


规则是实现区域完整性的方法之一，当数据库中的数据被插入或更新时，需要检查这个新值是否遵循规则，如果违反了规则，则操作失败。


１、DEFAULT对象（数据库对象），可以实现数据完整性，绑定到列或用户自定义数据类型时，如果插入时没有明确提供值，默认值便指定一个值，并将其插入到对象所绑定的列中。


２、RULES对象（数据库对象），可以用它来实现数据完整性，当绑定到列或用户自定义数据类型时，规则将指定可以插入到列中的可接受的值。


四、使用触发器和存储过程实现数据完整性


触发器是一种特殊的存储过程，它不能被显示地调用，而是在向表中插入、更新或删除数据时被自动激活。所以，触发器可以用来对表实施复杂的完整性约束，当触发器所的数据发生改变时，触发器会自动被激活，从而防止对数据的不正确修改。


触发器与数据表紧密相连，可以看作是数据表定义的一部分，能学它们都是以一组SQL语句的形式存在。触发器基于一个表创建，介是可以针对多个表进行操作。触发器可以实现所有的约束功能。触发器可以引用其他表中的列。


触发器可以评估数据修改前后的表状态，并根据其差异采取对策，这也是约束无法实现的。


触发器为系统自动触发，而存储过程则需要强制激活。


五、总结



１、使用约束的系统开销最低，其次为使用默认值和规则，开销最高的是脆性器和存储过程；
２、功能最强的是触发器和存储过程，其次是默认值和规则，最后是使用约束；

前言
分布式数据库的数据一致性管理是其最重要的内核技术之一，也是保证分布式数据库满足数据库最基本的ACID特性中的 “一致性”(Consistency)的保障。在分布式技术发展下，数据一致性的解决方法和技术也在不断的演进，本文就以分布式数据库作为案例，介绍分布式数据库数据一致性的原理以及实际实现。
1、数据一致性
1.1 数据一致性是什么
大部份使用传统关系型数据库的DBA在看到“数据一致性”时，第一反应可能都是数据在跨表事务中的数据一致性场景。但是本文介绍的“数据一致性”，指的是**“数据在多份副本中存储时，如何保障数据的一致性”**场景。
由于在大数据领域，数据的安全不再由硬件来保证，而是通过软件手段，通过同时将数据写入到多个副本中，来确保数据的安全。数据库在同时向多个副本写入记录时，如何确保每个副本数据一致，称为“数据一致性”。
1.2 关系型数据库如何保障数据一致性
传统的关系型数据库对于运行环境–硬件要求都比较高，例如Oracle会建议用户使用小型机+共享存储作为数据库的运行环境，DB2 DPF也同样建议用户采用更好的服务器+高端存储来搭建数据库的运行环境。所以在数据存储安全的技术要求下，传统关系型数据库更多是依赖硬件的技术来保障数据的安全性。


因为关系型数据库的数据安全是基于硬件来保障，并且数据也不会通过同时存储多份来保障数据的安全，所以关系型数据库的用户默认认为数据存储是一致的。
1.3 分布式存储如何保障数据一致性
本文在讨论分布式存储时，主要指的是大数据产品中的分布式文件系统和分布式数据库，例如：SequoiaDB和HDFS。
用户在搞明白分布式存储的数据一致性原理时，必须要先明白为什么他们就需要数据一致性，和分布式存储的数据存储与关系型数据库的数据存储又有什么区别。
大数据技术的诞生，确确实实让系统的性能有新的突破，并且支持硬件以水平扩展的方式来获得线性增长的性能和存储。这些都是过去传统关系型数据库所无法提供的。另外，大数据技术也抛弃了运行环境必须足够好的硬性要求，而是允许用户通过批量廉价X86服务器+本地磁盘的方式搭建规模集群，从而获得比过去依赖硬件垂直扩展所提供的更强的计算能力和更多的存储空间。
大数据技术的核心思想就是分布式，将一个大的工作任务分解成多个小任务，然后通过分布式并发操作的方式将其完成，从而提高整个系统的计算效率或者是存储能力。而在分布式环境下，由于硬件的要求降低，必然需要大数据产品提供另外一个重要的功能–数据安全。


大数据产品在解决数据安全的方式上，都比较接近，简单来说，就是让一份数据通过异步或者同步的方式保存在多台机器上，从而保障数据的安全。
分布式存储在解决数据安全的技术难点后，又引入了一个新的技术问题，就是如何保障多个副本中的数据一致性。目前SequoiaDB是使用Raft算法来保证数据在多个副本中一致性。
2、Raft算法
2.1 Raft算法背景
在分布式环境下，最著名的一致性算法应该是Paxos算法，但是由于它实在过于晦涩难懂，并且实现起来极度困难，所以在2013年，Diego Ongaro、John Ousterhout两个人以易懂(Understandability)为目标设计了一套一致性算法Raft。Raft算法最大的特点在于简单易懂，并且实现起来简单
2.2 Raft算法概述
与Paxos不同，Raft强调的是易懂，Raft和Paxos一样只要保证n/2+1节点正常就能够提供服务。
众所周知当问题较为复杂时可以把问题分解为几个小问题来处理，Raft也使用了分而治之的思想。Raft算法重点解决三个子问题：选举(Leader election)、日志复制(Log replication)、安全性(Safety)。
Raft算法强化了Leader节点的功能，Follower节点的数据只能够从Leader中获取，所以Follower节点的实现就变得简单，只要负责和Leader保持通信，并且接受Leader推送的数据即可。
2.3 Raft算法原理
2.3.1 节点角色
Raft算法中，对节点的状态分为3种角色，分别是Leader(领导者)、Follower(追随者)和Candidate(候选者)。
Leader，负责处理来自客户端的请求，负责将日志同步到Follower中，并且保证与Follower之间的heartBeat联系;
Follower，当集群刚刚启动时，所有节点均为Follower状态，它的工作主要为响应Leader的日志同步请求，响应Candidate的请求，以及把请求到Follower的事务请求转发给Leader;
Candidate，选举Leader时负责投票，选举出来Leader后，节点将从Candidate状态变为Leader状态。

2.3.2 Terms
在分布式环境下，“时间同步”一直都是老大难的技术难题。Raft为了解决这个问题，将时间划分为一个一个的Term(可以理解为“逻辑时间”)来处理在不同时间段里的数据一致性。
Terms有以下原则

每个Term中，至多存在一个Leader
某些Term中，有可能存在由于选举失败，没有Leader的情况
每个节点自己维护本地的currentTerm
每个Term都是一个连续递增的编号
如果Follower的Term编号比别的Follower Term编号小时，该Follower Term编号将更新Term编号，以保持与其他Follower Term编号一致

2.3.3 选举
Raft的选举由定时器触发，每个节点的触发时间都不相同。
所有的节点在开始时状态都为Follower，当定时器触发选举后Term编号递增，该节点的状态由Follower转为Candidate，并且向其他节点发起RequestVote RPC请求，这时选举有3种情况可能发生：
发起RequestVote的节点收到n/2+1(过半数)个节点的投票，该节点将从Candidate状态变为Leader状态，开始向其他节点发送HeartBeat以保持Leader的正常状态
如果收到投票请求后，该节点发现发起投票的节点Term大于自己，则该节点状态从Candidate转为Follower，否则保持Candidate状态，并且拒绝该投票请求
选举期间发生了超时，则Term编号递增，重新发起选举


2.3.4 日志复制
日志复制主要的作用就是用来保证节点的数据一致性与高可用性。
当Leader被选举出来后，所有的事务操作都必须要经过Leader处理。这些事务操作成功后，将会被按顺序写入到LOG中，每个LOG都包含一个index编号。
Leader在LOG发生变化后，通过HeartBeat将新的LOG同步到Follower上，Follower在接收到LOG后，再向Leader发送ACK信息，当Leader接到大多数(2/n+1)Follower的ACK信息后，将该LOG设置为已提交，并且Leader将LOG追加到本地磁盘中。
同时Leader将在下一个HeartBeat中，通知所有的Follower将该LOG存储在各自的本地磁盘中。
2.3.5 安全性
安全性是用于确保每个节点都是按照相同的日志序列进行执行的安全机制。
如果当某个Follower在同步Leader的日志时失败，但是未来该Follower又可能被选举为Leader时，就有可能导致前一个Leader已经commit的日志发生覆盖，这样就导致了节点执行不同序列的日志。
Raft的安全性就是用于保证选举出来的Leader一定包含先前已经commit LOG 的机制，主要遵循的原则如下：
每个Term 只能选举一个Leader;
Leader的日志完整性，则当Candidate重新选举Leader时，新的Leader必须要包含先前已经commit的LOG;
Candidate在选举新的Leader时，使用Term来保证LOG的完整性;
3、分布式数据库数据一致性技术实现
以国产原厂的分布式数据库SequoiaDB为例，SequoiaDB在多副本的部署中，采用Raft算法保证数据在多副本环境中保持一致。
SequoiaDB集群中，总共包含3中角色节点，分别是协调节点、编目节点和数据节点。由于协调节点本身不存任何数据，所以只有编目节点和数据节点存在事务操作，换言之，编目分区组和数据分区组的副本同步采用Raft算法保证数据一致性。

3.1 编目节点和数据节点的事务日志介绍
编目节点和数据节点由于都是需要存储数据的，并且在集群部署中该，为了确保数据的安全，都是建议采用分布式的方式进行部署，所以在数据同步中，需要采用Raft算法的基本原理进行数据同步。
编目节点和数据节点在存储数据时，共包含两大部分，一个真实的数据文件，另一个是事务日志文件。



SequoiaDB的节点事务日志，默认情况下由20个64MB(总大小为1.25GB)的文件构成。节点的事务日志主要包含一个index编号和数据操作内容，index编号保持永远递增状态。
另外，SequoiaDB节点的事务日志不会永久保存，而是当所有的事务日志写满后，再重新从第一个文件开始进行覆盖写入。
3.2 编目分区组的数据一致性
由于编目分区组是保存SequoiaDB集群的元信息，数据同步要求高，所以编目分区组的数据一致性要求为强一致性，即每次向编目分区组执行事务操作时，必须要确保所有的编目节点操作成功，才计算该操作执行成功，否则该事务操作将在整个编目分区组中回退事务日志，以保证分区组内的数据一致性。
另外，编目分区组还有一个比较重要的特性，即编目分区组必须要存在主节点才能够正常工作，如果老的主节点宕机了，编目分区组暂时没有主节点，则该编目分区组不能够对外提供任何事务操作和数据查询操作。
3.3 数据分区组的数据一致性
数据分区组的数据一致性默认情况下为最终一致性性，即只要求主节点执行事务操作成功即视为操作成功，主节点将在未来异步同步ReplicaLOG到从节点上。
3.4 主从节点的事务日志同步
SequoiaDB的主从节点是通过事务日志同步来保证数据一致性的，并且主从节点的事务日志同步是单线程完成。
如果当主节点和从节点的LSN差距为一条记录，则主节点会主动将最新的事务日志推送给从节点。
如果主节点和从节点的LSN差距超过一条记录，则从节点会主动向主节点请求同步事务日志，主节点收到同步请求后，会将从节点的LSN号到主节点最新的LSN号对应的事务日志打包一次性发送给从节点。
3.5 从节点日志重放
当从节点获取到主节点推送过来的事务日志后，就会自动解析事务日志和重放。从节点在重放事务日志时，默认情况下会以10并发来重放事务日志。
从节点在执行并发重放日志时有条件限制，即在集合的唯一索引个数<=1的情况下，INSERT、DELETE、UPDATE、LOB WRITE、LOBUPDATE、LOB REMOVE操作可以支持并发重放事务日志。从节点在做并发重放时，是通过记录的OID进行打散并发执行，这样就可以保证对相同记录的操作不会由于并发重放导致数据不一致。
但是用户需要注意，从节点在重放事务日志时， DROP CL操作不能够支持并发重放。
4、SequoiaDB数据一致性应用
目前SequoiaDB数据分区组的数据一致性是基于集合级别进行配置的。用户在使用SequoiaDB过程中，可以随时调整数据一致性的强度。
4.1 创建集合时指定
在一个多副本的SequoiaDB集群中，集合默认的数据一致性行级别为“最终一致性”。用户可以在创建集合时显式指定该集合的“数据一致性强度”，例如可以在SequoiaDB Shell中执行以下命令
db.CSNAME.createCL(“CLNAME”,{ReplSize:3})
ReplSize参数填写范围


4.2 修改已经存在的集合
如果集合在创建时没有设置“数据一致性”ReplSize参数，用户也可以对已经存在的集合进行修改，在SequoiaDB Shell修改命令如下
db.CSNAME.CLNAME.alter({ReplSize:3})
ReplSize的取值范围和创建集合时一致。
4.3 如何查看集合的ReplSize参数
如果用户希望检查当前集合的RepliSize参数值，可以通过数据库快照进行查看，在SequoiaDB Shell查看命令如下
db.snapshot(SDB_SNAP_CATALOG,{}, {“Name”:null, “IsMainCL”:null,“MainCLName”:null, “ReplSize”:null})

打印信息如下
{
“MainCLName”:“test.main2”,
“Name”: “foo.bar2”,
“IsMainCL”: null,
“ReplSize”: null
}
{
“IsMainCL”: true,
“Name”: “test.main2”,
“MainCLName”: null,
“ReplSize”: null
}
{
“Name”: “foo.tt”,
“ReplSize”: 3,
“IsMainCL”: null,
“MainCLName”: null
}
5、总结
分布式的数据库，通过Raft算法来确保在分布式情况上数据的一致性，并且编目分区组和数据分区组对数据一致性要求又有所不同，编目分区组始终要求的是数据在多副本请情况下数据强一致性，而数据分区组则可以由用户在创建集合时来执行数据一致性的强度，强度越高，数据安全性越好，但是执行的效率就会相对较差，反之依然。
目前SequoiaDB在数据一致性场景上，用户的调整空间较大，可以根据不同的业务要求来调整数据一致性的强度，以满足业务或追求性能最优，或者数据最安全的技术要求。