0707‘s Blog

Software Developer

首页 归档 标签

面试八股文-数据库事务，隔离级别

2024-10-24 10 min read # 面试八股文

本文主要介绍数据库事务属性与隔离级别的使用

ACID 属性

ACID 是事务的四个关键属性的缩写，确保数据库操作的可靠性。ACID 属性包括：

  1. 原子性（Atomicity）
  • 原子性意味着事务中的所有操作要么全部成功，要么全部失败。事务不可能部分执行，事务的操作要么全部提交（commit），要么全部回滚（rollback）。这保证了在系统崩溃的情况下，数据不会处于部分更新的状态。
  • 例如：如果一个事务需要将某个账户的余额从100减少到50，并将另一账户的余额从50增加到100，这两个操作必须要么同时成功，要么同时失败。
  1. 一致性（Consistency）
  • 一致性保证事务的执行不会破坏数据库的规则或约束条件。事务开始之前和结束之后，数据库必须保持在一致的状态。任何事务都必须从一致状态转换为另一个一致状态。
  • 例如：在银行转账中，转账后的账户余额总和必须与转账前一致，不能因为转账导致总金额丢失或增加。
  1. 隔离性（Isolation）
  • 隔离性确保并发执行的事务互不干扰，每个事务的执行结果不会被其他事务所看到，直到事务完成。即便多个事务同时执行，也要让它们看起来像是串行执行的一样。
  • 例如：在多用户环境中，多个用户同时进行数据库操作，一个用户的操作不应影响到其他用户的事务结果。
  1. 持久性（Durability）
  • 持久性保证了事务一旦提交，其结果将永久保存在数据库中，即使系统崩溃或电源中断也不会丢失数据。持久性通常通过将数据写入磁盘来保证。
  • 例如：如果用户完成了银行转账操作，即便系统在操作后崩溃，数据仍应正确地反映转账的结果。
    使用原子性，隔离性，持久性保证一致性。

事务的隔离级别

隔离性是ACID中的一个重要属性，它控制事务之间的可见性。数据库通过定义不同的隔离级别来平衡并发性能和数据一致性。SQL标准定义了四种隔离级别，每种隔离级别允许不同程度的并发干扰。
隔离级别及其可能的问题：

  1. 读未提交（Read Uncommitted）
  • 描述：最低的隔离级别，事务可以读取其他事务未提交的数据。
  • 可能问题：脏读（Dirty Read）——一个事务可以读取到另一个事务尚未提交的修改，如果后者回滚，则前者读取到无效数据。
  • 应用场景：很少使用，因为数据一致性无法保证。
  1. 读已提交（Read Committed）
  • 描述：一个事务只能读取到其他事务已提交的数据，防止脏读的发生。
  • 可能问题：不可重复读（Non-repeatable Read）——同一个事务中的两次相同查询可能会得到不同的结果，因为其他事务可能在它的中途修改并提交数据。
  • 应用场景：大多数数据库默认使用的隔离级别，如 Oracle。
  1. 可重复读（Repeatable Read）
  • 描述：一个事务在开始时对某个数据的读操作，在整个事务过程中保持一致。即使有其他事务修改并提交了该数据，本事务仍会看到它最初的值。
  • 可能问题：幻读（Phantom Read）——同一事务在不同时间段查询时，可能会发现数据集合不一致，例如第一次查询到的结果没有某条记录，但第二次查询时该记录出现了。
  • 应用场景：MySQL的默认隔离级别，解决了不可重复读，但可能存在幻读问题。
  1. 可串行化（Serializable）
  • 描述：最高的隔离级别，它通过强制事务串行化执行来防止所有并发问题。所有事务依次执行，确保没有并发访问冲突。
  • 可能问题：性能下降，因为并发能力几乎为零，事务必须等待其他事务执行完毕。
  • 应用场景：保证数据完全一致的场景，通常用于对数据一致性要求极高的系统。

事务隔离级别的影响

  1. 性能与一致性的平衡：
  • 隔离级别越高，事务之间的干扰越小，数据一致性越好，但性能开销越大。高隔离级别（如可串行化）会显著降低数据库的并发性能，因为事务之间需要等待。
  1. 隔离级别的选择：
  • 在实际应用中，常常根据具体需求来选择隔离级别。例如，在金融系统中，数据一致性要求较高，通常选择可重复读或可串行化；而在电商系统中，出于性能考虑，可能选择读已提交。
  1. 总结
  • ACID 属性：原子性、一致性、隔离性和持久性是事务管理的核心，确保数据库操作的可靠性和一致性。
  • 隔离级别：不同的隔离级别提供了对事务间并发的不同控制，选择适当的隔离级别需要在数据一致性和性能之间进行权衡。

电商系统中使用RC隔离级别

在电商系统中，使用**读已提交（Read Committed）隔离级别时，可能会遇到不可重复读（Non-repeatable Read）**的问题。不可重复读是指在同一个事务中，多次读取相同的数据时，数据内容可能发生变化，因为另一个事务可能已经修改并提交了该数据。
为了解决这个问题，在读已提交的隔离级别下，可以采用以下几种方法：

悲观锁（Pessimistic Locking）

悲观锁是一种假设冲突一定会发生的策略，所以会通过数据库的锁机制来防止其他事务对数据的修改。使用悲观锁可以确保数据在事务结束之前不会被其他事务修改，从而避免不可重复读问题。
在Java中，悲观锁通常通过数据库的 SELECT ... FOR UPDATE 语句实现。当一个事务读取数据时，会锁定该行记录，直到事务提交或回滚，其他事务无法修改被锁定的数据。

  • 优点：避免了数据修改带来的问题，保证了数据一致性。
  • 缺点：性能较差，特别是在高并发系统中，由于会对数据加锁，容易导致事务等待或死锁
    -- 事务A
    BEGIN;
    SELECT * FROM products WHERE product_id = 1 FOR UPDATE;
    -- 此时，事务B无法更新或读取 product_id = 1 的记录，直到事务A提交或回滚

乐观锁（Optimistic Locking）

乐观锁是一种假设数据冲突不会经常发生的策略，只有在事务提交时才检查数据是否被其他事务修改。乐观锁通常通过版本号或时间戳机制来实现。
在电商系统中，可以为每个记录增加一个版本号（version 字段），每次事务提交时，检查数据的版本号是否与读取时一致。如果版本号发生变化，说明有其他事务修改了数据，当前事务应回滚或重新尝试。

  • 优点：不会加锁，适合高并发场景；只有在冲突发生时才会处理，性能较好。
  • 缺点：需要手动管理版本号，冲突发生时需要重试操作。
// 读取数据时获取版本号
Product product = productRepository.findById(1);
int currentVersion = product.getVersion();

// 更新数据时检查版本号是否一致
int rowsUpdated = productRepository.updateProduct(product.getId(), newPrice, currentVersion);

if (rowsUpdated == 0) {
    // 版本号不一致，说明有并发修改，回滚或重新处理
    throw new OptimisticLockingFailureException("Product has been updated by another transaction.");
}
  1. 在应用层缓存数据
    在电商系统中，可以通过在应用层缓存数据来避免不可重复读问题。在同一个事务中，读取数据时将数据缓存起来，之后的操作都从缓存中获取数据，而不再重复从数据库读取。这种方式保证了在事务内的数据一致性。
  • 示例：将查询到的产品信息缓存到事务的上下文中，后续操作从缓存中获取数据，而不是直接查询数据库。
java复制代码// 缓存第一次读取的数据
Map<Integer, Product> productCache = new HashMap<>();
Product product = productRepository.findById(1);
productCache.put(1, product);

// 后续读取操作使用缓存中的数据
Product cachedProduct = productCache.get(1);
  • 优点：实现简单，能够在应用层解决不可重复读问题。
  • 缺点：适合只读场景或数据变化不频繁的情况，不能解决数据频繁变动时的一致性问题。
  1. 使用可重复读隔离级别
    如果业务逻辑要求在同一事务中多次读取数据时保持一致，考虑升级到**可重复读（Repeatable Read）**隔离级别。可重复读隔离级别可以解决不可重复读问题，保证在同一事务中，每次读取的数据一致。
    在MySQL等数据库中，可重复读隔离级别通过使用多版本并发控制（MVCC，Multi-Version Concurrency Control）来实现。MVCC允许事务读取数据的快照，即使其他事务修改并提交了数据，当前事务读取到的仍是开始时的数据版本。
  • 优点：天然解决不可重复读问题，能够保证数据一致性。
  • 缺点：可能会有**幻读（Phantom Read）**问题，且隔离级别提高会影响性能。
  1. 使用快照隔离（Snapshot Isolation）
    部分数据库（如 PostgreSQL）提供了快照隔离，它类似于可重复读，通过每个事务访问数据的快照来避免并发读写问题。在快照隔离中，事务读取数据时会看到事务开始时的数据版本，其他事务的修改在当前事务中是不可见的。
    快照隔离能够有效解决不可重复读问题，并且在处理幻读方面也有一定优势。
  • 优点：提供一致性视图，避免不可重复读问题，性能较好。
  • 缺点：并非所有数据库都支持，且需要额外的存储来保存多个版本的数据。

总结

在电商系统中使用读已提交隔离级别时，可以通过以下几种方式解决不可重复读问题：

  1. 悲观锁：通过数据库锁定，防止其他事务修改数据。
  2. 乐观锁：通过版本号或时间戳机制，在提交时检查是否有并发修改。
  3. 应用层缓存：在事务内缓存读取的数据，避免重复查询数据库。
  4. 可重复读隔离级别：通过提高隔离级别，保证数据一致性。
  5. 快照隔离：通过多版本并发控制（MVCC），为事务提供一致的快照数据。
    根据具体业务需求和性能要求，可以选择合适的方式来解决不可重复读问题。
Powered by Gridea RSS