【系统架构设计（39）】数据库控制技术

一、并发控制

1、事务ACID特性

事务的ACID特性是数据库系统可靠性的根本保障，这四个特性共同确保了数据操作的完整性和一致性。

原子性要求事务中的所有操作要么全部成功执行，要么全部失败回滚，这就像银行转账操作：要么转账成功，要么保持原状，绝不会出现钱被扣除但对方账户没有增加的情况。一致性确保事务执行前后数据库都处于一致状态，即使发生故障也不会破坏数据的完整性约束。

隔离性通过控制并发事务之间的相互影响，防止一个事务的中间状态被其他事务看到，从而避免数据不一致。持久性则保证事务提交后对数据库的修改永久保存，即使系统崩溃也不会丢失已提交的数据。这四个特性相互配合，构成了数据库事务处理的理论基础。

 

2、并发问题

并发执行事务时会产生三种典型的并发问题，这些问题会严重影响数据的一致性和可靠性。

丢失更新

两个事务同时读取同一数据并修改，后执行的事务更新会覆盖先执行事务的更新。例如，在库存管理系统中，两个销售员同时处理同一商品的销售，都读取到库存为100件，分别扣减5件和8件，最终库存可能变成92件而不是87件，导致库存数据不准确。

不可重复读

同一事务内多次读取同一数据时结果不一致。在财务报表生成过程中，如果统计程序在计算过程中其他事务修改了相关数据，就会导致报表数据前后不一致，影响决策的准确性。

读"脏"数据

事务读取了其他未提交事务的中间结果。例如，在银行系统中，如果转账事务在扣款后、入账前发生回滚，而其他事务在此期间读取了扣款后的余额，就会得到错误的"脏"数据。
 

3、封锁协议

封锁协议通过锁机制控制并发访问，是解决并发问题的核心手段，不同的封锁协议针对不同的并发问题提供了相应的解决方案。

锁类型

• S锁（共享锁）：读锁，多个事务可同时持有，用于读取操作
• X锁（排他锁）：写锁，独占锁，用于修改操作

封锁协议

• 一级封锁协议：修改数据前加X锁，直到事务结束才释放，防止丢失更新
• 二级封锁协议：在一级基础上，读取数据前加S锁，读完后释放，防止读"脏"数据
• 三级封锁协议：读取数据前加S锁，直到事务结束才释放，防止不可重复读
• 两段锁协议：事务分为加锁阶段和解锁阶段，保证可串行化

一级封锁协议：丢失更新加锁

一级封锁协议通过加写锁（排他锁，即X锁）的方式解决丢失更新问题，写锁的特性是同一时刻只能有一个事务持有。

事务T1对数据A加写锁，获取对数据A的独占修改权，此时其他事务不能对A加写锁。T1读取A=10，进行A=A-5的修改并写回，然后释放对A的写锁。事务T2尝试对A加写锁时，由于A已被T1加写锁，所以进入等待状态。当T1释放写锁后，T2获取写锁，读取A=5（T1修改后的值），进行A=A-8的修改并写回，最后释放写锁。

通过这种加写锁机制，避免了两个事务同时修改同一数据导致的丢失更新问题。T2在T1未释放写锁时只能等待，保证了T1的修改操作不会被T2覆盖，确保数据修改的顺序性和完整性。

 

二级封锁协议

一级封锁协议没有解决读脏数据的问题，因为T2没有加写锁，二级封锁协议在此基础上增加了读锁机制。

一级封锁协议规定事务在修改数据前必须先对其加X锁，直到事务结束才释放，但此协议仅针对数据修改操作要求加锁，对于单纯的读操作，并没有要求加锁。当事务A对数据加X锁进行修改时，事务B若只是读取数据，按照协议不需要加锁就能读取。若事务A修改数据后未提交便回滚，而事务B在此期间读取了事务A修改后的数据，那么事务B就读到了"脏"数据。

二级封锁协议在此基础上，增加了事务在读取数据前先加S锁（共享锁），读完后释放的要求，能防止读"脏"数据。因为当事务A对数据加X锁时，事务B无法加S锁进行读取，需等待事务A释放X锁，从而避免了读"脏"数据问题。

 

三级封锁协议：解决不可重复读问题

一级、二级封锁协议没能解决不可重复读问题，三级封锁协议通过延长S锁的持有时间来解决这个问题。

一级封锁协议只针对数据修改操作要求加锁，对于单纯的读操作不需要加锁。在事务T1读取数据后，事务T2可以在T1再次读取之前对数据进行修改并提交，导致T1两次读取结果不一致，出现不可重复读问题。

二级封锁协议虽然加S锁可防止读"脏"数据，但读完即释放S锁，无法阻止其他事务在该事务两次读取间隙对数据进行修改。当事务T1第一次读取数据加S锁，读完释放后，事务T2可以加X锁修改数据，T1再次读取时数据已变，不能保证可重复读。

三级封锁协议要求事务在读取数据前加S锁且直到事务结束才释放。这使得在事务执行期间，数据一直被锁定，其他事务不能修改，保证多次读取结果一致。例如在统计报表数据读取过程中，能保证多次读取数据相同，避免其他事务中途修改数据影响统计结果。
 

死锁处理

• 预防：有序封锁、一次封锁
• 解除：检测死锁后选择事务回滚

 

二、数据库安全性

数据库安全性是一个多层次的安全防护体系，从用户身份验证到操作审计，每个环节都至关重要。

安全措施

• 用户标识和鉴定：验证用户身份，防止非法访问
• 存取控制：根据用户角色授予不同权限，控制数据访问
• 密码保护：加密存储和传输密码
• 视图保护：通过视图限制数据访问范围
• 审计：记录所有操作，便于事后监督

用户标识和鉴定是安全防护的第一道防线，通过验证用户身份来决定是否允许其进入系统。现代数据库系统通常采用用户名-密码组合验证，有些系统还引入了随机数检验、生物识别等更高级的验证方式，大大提高了系统的安全性。

存取控制机制根据用户的角色和身份，授予不同的操作权限。这种基于角色的访问控制（RBAC）不仅能够精细控制用户对数据库的操作，还能简化权限管理。例如，财务人员只能访问财务相关的表，而系统管理员则拥有更广泛的权限。

 

三、数据库备份与恢复

1、冷热备份

冷备份和热备份各有优劣，需要根据业务需求选择合适的备份方式。

冷备份

在数据库正常关闭、停止运行的状态下，将数据库的相关文件全部复制备份。优点是备份速度快，归档方便，恢复相对容易；缺点是只能恢复到备份完成的时间点，备份过程中数据库不能进行其他操作，影响业务连续性。

热备份

在数据库正常运行、持续提供服务的状态下，对数据库中的数据文件进行备份。优点是备份时数据库仍可被正常使用，不影响业务，恢复速度快；缺点是对备份操作的准确性要求极高，维护难度大。

 

2、备份类型

完全备份、差量备份和增量备份各有特点，合理的组合使用能够平衡备份效率和恢复复杂度。

完全备份

对数据库中的所有数据进行完整拷贝，涵盖全部表、视图、存储过程等对象。优点是恢复时简单直接，只需还原备份文件即可；缺点是备份时间长、占用存储空间大。

差量备份

以最近一次完全备份为基准，仅备份自那次全备后发生变化的数据。优点是备份数据量相对全备小，备份时间短；缺点是恢复时需要先恢复最近全备，再加上最后一次差量备份，过程相对复杂。

增量备份

备份自上一次备份之后变化的数据。优点是每次备份数据量小，节省时间和空间；缺点是恢复时较繁琐，需按顺序依次恢复全备及后续所有增量备份。

日志文件作用

事务日志记录数据库的所有改变操作，在恢复数据时，可依据日志文件，按操作顺序重演或回滚事务，能将数据库恢复到特定时间点状态。

 

3、备份故障与解决

不同类型的故障需要不同的恢复策略，UNDO和REDO操作是故障恢复的核心机制。

故障类型与处理机制对比表

故障类型	故障原因	处理方法与机制	恢复目标
事务本身的可预期故障	由事务自身逻辑问题导致	在程序中预先设置Rollback语句，当检测到故障触发条件时，事务自动回滚	撤销已执行的操作，回到事务开始前状态
事务本身的不可预期故障	因算术溢出、违反存储保护等意外情况引发	由数据库管理系统的恢复子系统借助日志文件处理，撤销事务对数据库的修改	撤销已做修改，保证数据一致性
系统故障	系统层面出现问题	常采用检查点法，数据库系统定期设置检查点记录数据库状态，系统重启时自动依据检查点信息，对未完成事务进行撤销（UNDO），对已提交但未完全写入磁盘的事务进行重做（REDO）	恢复数据库到一致状态
介质故障	外存物理损坏	利用日志文件重做业务，先恢复备份数据，再依据日志中记录的操作，对已提交事务进行重做	将数据库恢复到故障发生前的状态

UNDO和REDO操作对比表

操作类型	适用场景	操作原理与机制	恢复效果
撤销事务(UNDO)	针对故障发生时未完成的事务	将这类事务放入Undo操作，依据日志反向执行操作，撤销已做修改	回到事务开始前状态
重做事务(REDO)	对于故障发生前已提交的事务	通过Redo操作，依据日志重新执行这些事务的操作，确保数据完整和一致	完成事务的持久化