SQL多用户访问数据库如何解决的冲突？

sql多用户访问数据库其实就是事务并发，会引起如下问题：

1、脏读：一个事务读取到了另外一个事务没有提交的数据

事务1：更新一条数据

事务2：读取事务1更新的记录

事务1：调用commit进行提交

此时事务2读取到的数据是保存在数据库内存中的数据，称为脏读。

读到的数据为脏数据

详细解释：

脏读就是指:当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，

另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个

事务读到的这个数据是脏数据，依据脏数据所做的 *** 作可能是不正确的。

2、不可重复读：在同一事务中，两次读取同一数据，得到内容不同

事务1：查询一条记录

事务2：更新事务1查询的记录

事务2：调用commit进行提交

事务1：再次查询上次的记录

此时事务1对同一数据查询了两次，可得到的内容不同，称为不可重复读。

3、幻读：同一事务中，用同样的 *** 作读取两次，得到的记录数不相同

事务1：查询表中所有记录

事务2：插入一条记录

事务2：调用commit进行提交

事务1：再次查询表中所有记录

此时事务1两次查询到的记录是不一样的，称为幻读

详细解释：

幻读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，

这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表

中插入一行新数据。那么，以后就会发生 *** 作第一个事务的用户发现表中还有没有修改的数据行，

就好象发生了幻觉一样。

处理以上隔离级别的问题，采用如下方是：

事务隔离五种级别：

TRANSACTION_NONE 不使用事务。

TRANSACTION_READ_UNCOMMITTED 允许脏读。

TRANSACTION_READ_COMMITTED 防止脏读，最常用的隔离级别,并且是大多数数据库的默认隔离级别

TRANSACTION_REPEATABLE_READ 可以防止脏读和不可重复读，

TRANSACTION_SERIALIZABLE 可以防止脏读，不可重复读取和幻读，（事务串行化）会降低数据库的效率

以上的五个事务隔离级别都是在Connection接口中定义的静态常量，

使用setTransactionIsolation(int level) 方法可以设置事务隔离级别。

如:con.setTransactionIsolation(Connection.REPEATABLE_READ)

注意：事务的隔离级别受到数据库的限制，不同的数据库支持的的隔离级别不一定相同

1 脏读：修改时加排他锁，直到事务提交后才释放，读取时加共享锁，读取完释放事务1读取数据时加上共享锁后（这 样在事务1读取数据的过程中，其他事务就不会修改该数据），不允许任何事物 *** 作该数据，只能读取，之后1如果有更新 *** 作，那么会转换为排他锁，其他事务更 无权参与进来读写，这样就防止了脏读问题。

但是当事务1读取数据过程中，有可能其他事务也读取了该数据，读取完毕后共享锁释放，此时事务1修改数据，修改 完毕提交事务，其他事务再次读取数据时候发现数据不一致，就会出现不可重复读问题，所以这样不能够避免不可重复读问题。

2 不可重复读：读取数据时加共享锁，写数据时加排他锁，都是事务提交才释放锁。读取时候不允许其他事物修改该数据，不管数据在事务过程中读取多少次，数据都是一致的，避免了不可重复读问题

3 幻读问题：采用的是范围锁RangeS RangeS_S模式，锁定检索范围为只读，这样就避免了幻影读问题。

云计算中的数据隔离要使用虚拟化技术。虚拟化技术是云计算的核心技术，通过虚拟化技术实现了计算和资源的共享，所有用户的数据都位于共享的环境之中，这就意味着不同用户的数据可能存放在一个共享的物理存储设备中，如果恶意用户通过不正当手段取得合法虚拟机权限，就有可能威胁到同一台物理存储设备上的其他虚拟机，进而威胁到其他用户数据的安全，采用数据加密的方式能够起到一定的保护作用，但是仍然不足以保证数据的安全性，而数据隔离技术能够保障用户间数据分开，防止上述事件的发生。

在云计算系统中对客户数据的存放可采用两种方式实现：一种方式是采用单独的存储设备，这种方式从物理层面来对客户的重要数据进行有效的隔离保护，但是这种方式缺点是对存储资源不能进行有效利用；另一种存储方式是采用共享的存储设备，这种方式采用了虚拟化技术，以共享存储的方式对用户的数据进行存储，这种方式能够节约存储空间并且统一管理，可以节省相关的管理费用，但是这种方式需要确保数据的隔离性，这就要求在存储设备上部署数据隔离的相关措施。 目前已经有几种相对成熟的数据库架构来帮助实现数据隔离。

共享表架构（Shared Schema Multi-Tenancy） 即相同的数据库实例和相同的数据库表被所有的软件系统客户共享使用，而数据的从属是通过字段来进行区分的。这种方式的优点是由于它最大化地利用了单个数据库实例的存储能力使得硬件成本非常低廉，其缺点是由于多个客户的数据共存于相同的数据库表内，因此需要额外的业务逻辑来隔离各个客户的数据，增加了开发的复杂度。此外，这种架构实现数据备份的成本也非常高，不但需要专门编写代码实现数据备份，而且在恢复数据时，需要对数据库表进行大量的删除和插入 *** 作，因为数据库表包含大量其他客户的数据，势必对系统性能和其他客户的体验带来影响。 分离数据库架构（Separated Database） 即每个软件系统客户单独拥有自己的数据库实例；相比共享表架构，由于每个客户拥有单独的数据库实例，这种架构可以高效便捷地实现数据安全性和数据备份，但是随之而来的缺点便是其硬件成本非常高昂。 分离表架构（Shared Database Separated Schema） 即软件系统客户共享相同的数据实例，但是每个用户单独拥有自己的由一系列数据库表组成的模式。分离表架构是一种折中的多用户方案，它的优点是实现数据分离和数据备份相对共享表架构更加容易一些，而且它的硬件成本也较分离数据库架构低。

在进行云存储设计部署的时候，系统架构师要对以上三种方式进行全面分析，综合各方面的因素来选择合适的多用户模式（Multi-Tenancy）架构。一般来说，系统服务的客户数量越多，则越适合使用共享表的架构；对数据隔离性和安全性要求越高，则越适合使用分离数据库的架构。在超大型的云系统中，一般都会采用复合型的多租户模式架构，以平衡系统成本和性能。其中比较典型的实例就是Salesforce.com公司，Salesforce.com最初是基于共享表架构进行搭建，但是随着新客户的不断增加，单纯的共享表架构已经很难满足日益增长的性能要求，Salesforce.com逐步开始在不同的物理区域搭建分布式系统。在全局上，Salesforce.com以类似于分离数据库的架构运行，在单个区域内，系统则仍然按照共享表架构运行。

官方文档-Multi-user Isolation

多用户隔离是对不同用户之间使用资源的隔离。在kubeflow v0.6以上的版本，kubeflow支持的在kubeflow部署中对用户创建的资源进行多用户隔离。这个功能额主要目的是是多个用户可以共享一个集群上的kubeflow但是不会影响彼此创建的资源。隔离机制还可以防止意外删除/修改部署中其他用户的资源。当然需要注意一点： kubeflow并没有提供一个安全的多用户隔离的机制，用户还是可以通过namespace来恶意渗透到其他用户的个人资料当中 。

kubeflow中的 profile 资源会与k8s中 namesapce 会拥有相同的名字。每一个用户都会创建一个自己的 profile 资源。一个用户可以与其他用户分享自己的 profile 。当一个用户分享自己的 profile 与其他用户时可以决定分享只读权限或者是可写权限。

一个profile的示例：

在kubeflow central dashboard中，我们可以看到 namespace 和 profile 是互相绑定的。

注意⚠️： 由于 profile 和Kubernetes 中的 namespace 是一一对应的，所以在以下文档中这个两个名词可能会进行混用。

Jupyter notebooks服务是第一个完全集成多用户隔离功能的服务，后面将以它作为例子来讲。

用户可以通过这个UI界面去创建一个新的Jupyter notebook server，而这个Jupyter notebook server的pod就会建立在这个'namespace'底下。用户对于自己的'namespace'是拥有着读和创建的权利，但是对于只读权限的 namespace ，就只能读而不能创建新的Jupyter notebook server。

kubeflow v0.6.2提供了在用户登录成功时自动创创建 profile 的功能。并且一个管理员用户（administrator）可以在kubeflow集群中为任何用户创建 profile 。

解释一下，管理员用户（administrator）就是Kubernetes集群中拥有管理员权限的用户，这个用户拥有在这个集群中创建任意资源的权利。

---