接上篇文章，我们在讲解过常见的分布式存储系统以及常见的存储引擎等相关知识后们这篇文章将回归常见的模型以及数据库中的事务问题。文章我们将结合技术层面的相关知识，讲解分布式存储的相关应用。
常见的模型
1.文件模型：向上提供文件的存储，按照目录的形式去管理文件的，给上层的应用提供文件的基本操作，例如打开读写，查看目录这些操作。
2.关系模型：每个关系是一个表格由多行组成，给上层提供SQL数据库的访问特征。
3.键值模型：按行进行存储，每行提供了主键和值两个部分组成。SQL和noSQL
2.一个代表关系型数据库，一个代表非关系型数据库，两者各有优点和缺点：
SQL关系型数据库的挑战：
1、事务处理本来是为了更加方便的封装操作，但是由于现在的数据都是海量数据，而且数据都存放在不同的节点上，如果事务的多个操作在不同的节点上，保证事务的原子性就是一种挑战。
2、我们知道SQL为了同时操作多个表，支持表之间的联表操作，但是在海量数据面前，有时候联表操作并不是好的操作，海量数据有时候往往会利用那些冗余的数据。
3、在性能上，SQL底层是B树，B树的更新性能是没有LSM树这些性能好，如果碰到频繁的增添的时候，在存储引擎上还没有key-value这种系统好。
noSQL非关系型数据库的挑战：
1、缺少统一的标准，都是在针对特定的应用进行改进的
2、使用上及运维上比较复杂，没有形成一个统一的标准
3、这一类数据库一般用来缓存或者优化关系型数据库。
数据库中事务
为了让数据库更加高效的进行，数据库将多个操作合成了一个事务，并且让这个事务变成一个基本的操作，也就是说数据库的事务必须满足ACID属性
1、原子操作：对数据的修改是原子的，也就是说要么修改，要么不修改。
2、一致性：保持数据的一致性，即数据是正确完整的
3、隔离性：事务之间是隔离的，每一个事务在它没有完全执行完成之前，对其他的事务是不可见的
4、持久性：事务完成后，对数据库的操作是永久性的。
分布式数据库中的并发操作
多个事务并发操作的时候，这个时候很有可能对资源是有冲突的，例如一个事务要读某行，一个事务又要更新写这一行，那如何避免这种冲突呢？
看起来并发导致资源冲突和多线程的资源冲突很类似，第一个想到的是通过锁的方式来解决。
对于分布式数据库中并发管理有以下几种方式：
1、数据库锁
2、写时复制技术
3、多版本并发控制
1、就会涉及到数据库的并发控制了，数据库的并发操作主要是通过锁来完成的。
事务分成几种类型：读事务、写事务、读写事务
那么对应的锁也就有读锁，写锁，
对于读锁，允许对同一个元素加多个读锁
对于写锁，只能允许对一个元素加一个写锁，并且写事务将阻塞读事务
通过锁来控制和操作系统的线程是类似的，但是问题是可能会导致死锁，所以解决死锁需要靠回滚操作来完成。
2、写时复制技术
由于互联网中读事务是远大于写事务，通过写时复制操作，可以在读操作不同加锁来解决冲突的问题
主要是分为三步：
拷贝：把根节点到叶子节点拷贝
修改：对节点内容进行修改
提交：切换根节点的指针，指向新的根节点
那么对于读操作来说，如果读操作发生在第3步之前，呢么将直接读取老的节点，在3之后，将直接读取新的节点。
用这种方法可以解决读写的冲突，但是写写的冲突还是存在的，写写必须得互斥操作才行。
3、多版本控制
多版本控制也可以实现读事务部加锁，它的思想也比较简单，对每行数据维护多个版本，版本实际是数据行的删除修改的时间，当写一个数据时，出现了读请求，那么写没有完成，读的版本就是老的数据，通过版本检查，就可以实现获得自己需要的数据版本。
最后，需要定义将无用的版本进行删除回收操作。
转载请注明：http://www.0431gb208.com/sjszjzl/2592.html
