数据库事务总结

数据库事务总结

数据库事务

Tags: Database Transaction

---

锁机制

悲观锁

假设更新冲突会发生，所以不管冲突是否真的发生，都使用锁，这样会带来很大的性能损失
悲观锁是很常见的数据库锁方式，尤其是传统数据库，很多带事务的NewSQL数据库也都是使用的悲观锁。

表锁

对数据库整张表进行加锁，在加锁期间，整张表都是不允许使用的。

行锁

针对当前修改的一行数据进行加锁，在加锁期间，还是可以读写其他行数据。

页锁

和数据库内部存储相关，Mysql innodb引擎默认页大小为16KB，数据库在进行数据读取的时候，都是按照页进行读写的，这样可以提升效率，而且可以进行数据缓存，加速数据查询。
页锁就是对整个页进行加锁，同时对范围内数据进行加锁，避免该页数据被其他事务访问。能够显著降低细粒度行锁导致的冲突。

共享锁

允许读取数据，但是不允许修改数据

更新锁

共享锁和排它锁的结合，意味着在做一个更新的时候，一个共享锁在扫描完成符合条件的数据后可能会转化成为排它锁

• 扫描获取更新数据时候，是一个更新锁
• 如果将写入更新，这个时候，事务升级到排它锁，否则转变成共享锁

排它锁

使用锁的时候，任何其他事务都无法修改数据，仅使用NoLock提示或者是未提交读隔离级别时才会进行读取操作

乐观锁

不会锁住任何东西，不依赖数据库事务机制，完全是应用系统层面的东西，比如依靠版本字段来进行对比。
新式的NoSQL数据库以及NewSQL数据库，绝大部分使用的都是乐观锁。

版本号/时间戳

客户端需要进行数据更新，都必须提供版本号或者时间戳，查询的时候，也必须基于版本号或者时间戳进行查询，这样只能查询小于该版本号或者时间戳的数据，以此防止多版本之间的相互影响。
但是该方式受限于全局唯一的版本号生成速度，或者是时间戳精度。
特别是当时间戳发生跳变的时候，很容易出现幻读的情况。

Vector Clock

向量时钟适合于多版本同时提供数据读写操作，同时写入数据导致不一致问题。
向量时钟运行规则如下：
假设有A,B,C三副本都可以写入：

时间	操作	副本A时钟向量	副本2时钟向量	副本3时钟向量
t0	初始状态，一切都很正常	[A:0, B:0, C:0]	[A:0, B:0, C:0]	[A:0, B:0, C:0]
t1	副本A写入100，并且同步到B,C	[A:1, B:0, C:0]	[A:1, B:0, C:0]	[A:1, B:0, C:0]
t2	副本B写入200，并且开始同步到AC	[A:1, B:1, C:0]	[A:1, B:1, C:0]	[A:1, B:1, C:0]
t3	副本C写入300，但是只同步到A,B有问题	[A:1, B:1, C:1]	[A:1, B:1, C:0]	[A:1, B:1, C:1]
t4	副本B写入400	[A:1, B:1, C:1]	[A:1, B:2, C:0]	[A:1, B:1, C:1]
t5	B的数据开始进行同步，但是这个时候产生了冲突

B的数据，比B1新，但是比C1旧，这种情况下就不知道如何选择了。向量时钟并没有给出解决办法，只是提出了冲突检测办法。
向量时钟核心规则：

• 1、 每次修改数据，本节点的版本号 加1，例如上述 step 8中 向B写入，于是从B:1 变成 B:2, 其他节点的版本号不发生变更。
• 2、 每次同步数据(这里需要注意，同步和修改是不一样的写操作哦), 会有三种情况：
  a： 本节点的向量版本都要比消息携带过来的向量版本低（小于或等于） 如本节点为 [A:1, B:2,C:3]}， 消息携带过来为 [A:1, B:2,C:4] 或 [A:2, B:3,C:4]等。 这时候合并规则取每个分量的最大值。
  b: 本节点的向量版本都要比比消息携带过来的向量版本高，这时候可以认为本地数据比同步过来的数据要新，直接丢弃要同步的版本。
  c: 出现冲突，如上述t5，有的分量版本大，有的分量版本小，无法判断出来到底谁是最新版本。就要进行冲突仲裁。

一般的冲突解决办法：

• 向量时钟中再添加一个时间维度，有冲突的时候比较时间，时间新的取胜。

一致性Hash

在Amazon DynamoDB中得到使用。
传统的数据分布是按照Hash取模的方式进行的，在一个节点故障的时候，或者节点数量发生变化的时候，所有的数据都要重分布，这样就会导致数据库长时间不可用。
在一致性Hash中，Hash取模不是按照节点数量的，而是一个比节点数量大很多的值，比如65535等，然后这些值构成一个环形，数据就分布在这65535个虚拟节点中。当有一个节点故障的时候，虚拟节点会按照固定顺时针方向映射到下一个物理节点；当有新节点进入的时候，会在环形中 获取虚拟节点。这样一来，只有部分数据会发生变化，不用重新分布所有数据，大大提升了数据可用性。
一致性哈希算法背后的基本思想是对对象和缓存使用相同的哈希函数。
不仅哈希对象，机器也能利用其优点，即机器得到哈希函数的范围的一个区间，相邻的机器可以接管其邻居的一部分区间如果其邻居离开，也可以抛弃他们自己的一部分区间如果新节点加入且映射到相邻的区间。一致性哈希方法进一步的优点是，客户端应用程序可以计算出联系哪个节点以请求或写一块数据，且不必须有元数据服务器，如谷歌文件系统（GFS）有这样一个中心化的（虽然是集群）元数据服务器，它包含存储服务器和数据分区（在GFS中称为chunk；见[ GL03，页2 ]）之间的映射关系。
一个物理节点能够容纳多少虚拟节点，可以通过CPU，内存，磁盘容量等 方式计算出来。
当数据存在副本的时候，数据必须同时写入多个副本才算成功，比如5副本，则必须至少写入3副本才算成功&#x