mirai_D_zoro的博客

每个事务都在等待集合中的另一事务，由于这个集合是一个有限集合，因此一旦在这个等待的链条上产生了环，就会产生死锁。自旋锁和轻量锁属于系统锁，他们目前没有死锁检测机制，只能靠内核开发人员在开发过程中谨慎的使用锁，避免死锁发生。数据库中的常规锁，对申请锁的顺序没有严格的限制，在申请锁时也没有严格的查验，因此不可避免的就会产生死锁。pg数据库采用一种全局死锁检测的方法就是，每个进程启动后会启动一个定时器，定时调用死锁检测函数，检测是否有死锁产生，如果有死锁则进行相应的处理来解除死锁。

数据库采用MVCC方式进行并发控制，读写并不会互相阻塞，但是写之间仍然存在冲突。如果还是采用常规锁那样加锁，则会耗费大量共享内存，进而影响性能。所以行锁通过元组级常规锁和xmax结合的方式实现。一般先通过xmax进行可见性判断，如果出现冲突，则等待的一方申请元组级常规锁，这样就能避免申请过多的锁。

常规锁是数据库中实现的锁，它和自旋锁及轻量锁不同，自旋锁和轻量锁属于系统锁，主要用于保护数据库系统中的一些关键变量，服务于数据库内核的实现；常规锁属于事务锁，主要用于协调各种不同事务对数据库对象如表、页、元组等的并发访问。

pg数据库中，存在有大量的共享内存，进程并发访问这些共享内存的时候，就需要加锁保护，所以提供了轻量锁来提供对共享内存访问的保护。早期版本的轻量锁是由自旋锁实现的，但是，对于频繁以共享模式获取的锁，自旋锁的开销过高，特别是在尝试获取实际上为空闲的共享锁时，会出现不必要的自旋等待。当前版本做了优化，针对未被独占锁定的锁提供无等待的共享锁获取，并利用原子操作来获取和释放锁。

数据库在发生故障时，内存中的脏数据库可能还没有刷入磁盘，所以有部分数据是丢失的，此时直接启动数据库可能就会因为数据的不一致而导致数据库启动失败。但是，由于WAL日志都已经写入磁盘，因此就需要在启动时借助WAL日志恢复数据使数据库处于一致状态。数据库在重启时会调用startupXog函数进行故障恢复。

数据库中除了实际存储的数据之外，还存在许多事务相关的日志，如WAL日志，CLOG日志。MultiXact日志等，每次包含DML操作的事务都会产生这些日志，随着时间的推移，如果不进行清理，日志会一直增大下去，最终可能会占满磁盘，而且会导致数据库性能的下降。为了避免这种情况的发生，这就需要我们定期的清理这些日志并保证数据已经完全落盘，数据库提供了checkpoint功能来实现。

数据库运行过程中，数据一般是会保存在内存和磁盘中，为保证数据的安全性，防止数据库崩溃时数据不丢失，一般都是要保证数据实时落盘的，但是又由于磁盘随机IO读写速率与内存相比慢很多，如果每个事务的数据都要等到写入到磁盘才算完成，其性能会非常的差。为了解决这种问题，数据库提供预写式日志方式，即WAL日志，事务中每次写入只需要保证WAL日志落盘即可，不必再关心数据是否真的落盘，这样即使数据库崩溃，由于WAL日志已经落盘，仍旧可以通过WAL恢复数据的。

pg中有嵌套事务的概念，它的基本思想是嵌套事务中存在一个事务树。从根开始，每个事务都可以建立更低层次的子事务，子事务被嵌套在父节点的控制区域之内。为此，pg引入了SUBTRANS日志，记录每个事务的父事务ID。SUBTRANS日志通过SUBTRANS日志管理器来管理。SUBTRANS日志管理器管理着一个SLRU缓冲池，是类似于提交日志管理器的管理器，存储着每一个事务的父事务ID。它是嵌套事务实现的一个基础部分。一个主事务的父事务是INVALID的，每一个子事务都会有一个直接的父事务。

CLOG日志记录的是事务的最终状态。CLOG日志管理器管理者CLOG日志缓冲池，该日志缓冲池基于SLRU缓冲池实现。

MultiXact日志时数据库用来记录组合事务ID的日志。正常情况下，当事务更新一个元组或者对一个元组加锁时，其xmax字段会填入操作该元组的事务ID值，但是当多个事务同时操作一个元组时（如更新元组事务和元组加锁事务），元组的xmax就无法同时记录两个及以上的事务ID了，这时就会分配一个MultiXactID，然后将事务ID保存到MultiXact日志中，这样需要时就能通过MultiXactID就能查到其对应的事务ID了。

每个段都有一个段号，通过段号找到对应的文件，相反的如果知道日志的页面号，就可以找到该页面所在的段文件及该页在段文件中的偏移，当需要对这些文件进行操作时，需要先将其读入内存中，在内存中则以SLRU缓冲池的形式存在。因为往磁盘中写入是以块为单位的，而大多数情况是一个日志记录比一个块小多了，为了降低写入日志带来的IO开销，数据库中就设置了日志缓冲区，缓冲区以页为单位，当日志缓冲区满了之后就以块为单位写入磁盘。pg中的日志管理主要包括两种日志，一种是XLOG日志，记录的是事务对数据更新的过程和事务的最终状态。

SQL标准考虑的并行事务之间避免的现象脏读一个事务读取了另一个未提交的并行事务写的数据。比如事务A和B同时操作一张表tb1，A向表中插入一条数据，但是没有提交，这时事务B读取该表时，读到了事务A插入的数据。不可重复读一个事务重新读取前面读取过的数据，发现该数据已经被另一个已经提交的事务修改过。比如事务A和B同时操作一张表tb1,事务A读取表中数据“1”， 然后事务B将表中的数据“1”更新成“2”，然后事务A再次读取该表，读到了数据“2”。这就是不可重复读。幻读。

事务ID是事务的全局唯一标识，在事务存活期间能够唯一标识一个事务或子事务。它是一个32位无符号整数，最大取值为2^32-1。0： 代表不正确的事务ID号1： 代表Bootstrap的txid，在数据库初始化时使用。2： 冻结事务ID，该ID值对所有事务都可见根据数据库的MVCC原理，其中一条就是： 每个事务只能看到事务ID比当前事务ID小且没有被删除的元组。所以事务ID在判断元组可见性方面有着至关重要的作用。

两阶段提交主要用于分布式数据库中，分布式数据库本质上是将数据分布到不同的主机上，以实现大数据量的存储。例如greenplum数据库就是基于pg的分布式分析型数据库。分布式数据库主要有两个关注点：分布式执行计划，分布式事务。而分布式事务就是本章要将的两阶段提交。读操作需要保证在不同的主机上读到一致的数据。需要保证事务在不同主机上的原子性，不能出现某个主机上写数据成功，另一个主机上写数据失败的情况。两阶段提交就是针对写操作，将事务的提交分为两个阶段，当数据写入不同的主机时，要么全部提交，要么全部回滚。

数据库的子事务是指一个事务内部又包含了其他的事务，这些被包含的事务，我们称之为子事务。正常的事务中，一旦出现错误整个事务将回滚，期间所作的所有操作都将被撤销。对于一些比较大的事务，已经执行了许多的操作后，到临结束时出现错误，从而导致整个事务回滚，这在一些复杂的并发场景中，是很不友好的。而在事务中加入子事务，一旦出现错误，只需要回滚当前的子事务即可，并且回滚子事务不会影响到父事务的状态，能够提升业务的性能。因此子事务常被用于复杂的并发场景中，可以显著的提高数据库的性能和并发业务处理能力。

事务管理系统一般是指数据库中事务处理相关的几个模块的统称。事务管理系统主要包括三个大模块： 事务管理器、锁管理器和日志管理器。

这样数据库就装上了，默认用户是postgres,默认数据目录是/var/lib/pgsql/data但是如果不想使用默认的数据目录和用户，可以自定义初始化并安装，我的实现是这样的pg_hba.conf文件中的匹配原则是从文件头开始匹配，匹配到第一条符合要求的规则后就不会再继续匹配。接下来就可以创建表，开启愉快的数据库之旅了。