在数据库并发操作环境中，多个事务同时尝试更新相同的数据可能导致冲突。PostgreSQL 提供了一系列机制来处理这些并发更新冲突，以确保数据的一致性和完整性。

一、并发更新冲突的场景

当两个或多个事务同时尝试对同一行数据进行修改时，就可能发生并发更新冲突。常见的场景包括：

1. 同时修改同一行的不同列
2. 同时对同一列进行不同的值更新

二、PostgreSQL 中的并发控制机制

PostgreSQL 主要使用 MVCC（多版本并发控制，Multiversion Concurrency Control ） 来处理并发事务。MVCC 允许事务读取到符合其隔离级别需求的数据版本，而不需要加锁阻塞其他事务的读操作。然而，在写操作时，仍可能出现冲突。

（一） 封锁机制

PostgreSQL 使用多种类型的锁来控制对数据的并发访问。常见的锁类型包括：

1. 共享锁（Shared Lock）：允许其他事务也获取共享锁，但阻止获取排他锁。常用于读取操作。
2. 排他锁（Exclusive Lock）：阻止其他事务获取任何类型的锁，常用于写入操作。

锁的粒度可以是行级（Row-Level）、页级（Page-Level）和表级（Table-Level）。

（二） 事务隔离级别

PostgreSQL 支持四种事务隔离级别：

1. 读未提交（Read Uncommitted）：这是最低的隔离级别，一个事务可以读取到其他事务未提交的数据修改，可能导致脏读、不可重复读和幻读等问题。
2. 读已提交（Read Committed）：事务只能读取已经提交的数据，避免了脏读，但仍可能出现不可重复读和幻读。
3. 可重复读（Repeatable Read）：在一个事务内多次读取相同的数据会得到相同的结果，避免了不可重复读，但可能出现幻读。
4. 串行化（Serializable）：最高的隔离级别，通过严格的并发控制确保事务的串行执行，避免了脏读、不可重复读和幻读。

三、并发更新冲突的解决方法

（一） 重试机制

一种简单的方法是当冲突发生时，让事务进行重试。示例如下：

DO
$$
DECLARE
    conflict_detected BOOLEAN := FALSE;
BEGIN
    LOOP
        -- 尝试执行更新操作
        UPDATE products SET price = 100 WHERE id = 1;

        -- 检查是否有冲突（例如，通过检查受影响的行数）
        IF NOT FOUND THEN
            conflict_detected := TRUE;
        ELSE
            EXIT;
        END IF;

        -- 若有冲突，等待一段时间并重试
        IF conflict_detected THEN
            PERFORM pg_sleep(1);
        END IF;
    END LOOP;
END;
$$;

在上述示例中，如果更新操作没有影响到任何行（表示可能存在冲突），则设置一个标志，等待一段时间后重试。

（二） 使用乐观并发控制

乐观并发控制假设并发冲突很少发生。在这种方式中，事务在更新数据时不进行加锁，而是在提交时检查数据是否被其他事务修改。如果没有冲突，事务成功提交；如果有冲突，事务回滚并根据需要重试。

-- 获取数据的初始版本
SELECT price AS original_price FROM products WHERE id = 1;

-- 进行业务处理和修改
UPDATE products SET price = 100 WHERE id = 1 AND price = original_price;

在上述示例中，更新操作仅在数据未被其他事务修改的情况下成功。

（三） 使用悲观并发控制

悲观并发控制则假设并发冲突很可能发生，在事务执行期间获取所需的锁来阻塞其他可能冲突的事务。

BEGIN;

-- 获取排他锁
LOCK TABLE products IN SHARE ROW EXCLUSIVE MODE;

-- 进行数据更新
UPDATE products SET price = 100 WHERE id = 1;

COMMIT;

（四） 应用版本字段

给表添加一个版本字段来跟踪数据的更改。

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    price DECIMAL(10, 2),
    version INT DEFAULT 0
);

在更新数据时，同时递增版本字段：

UPDATE products SET price = 100, version = version + 1 WHERE id = 1 AND version = <expected_version>;

如果更新影响的行数为 0，表示存在冲突，因为预期的版本与实际的版本不一致。

（五） 基于时间戳的冲突解决

为每行数据添加一个时间戳字段，记录数据的最后修改时间。

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    price DECIMAL(10, 2),
    last_modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

在更新时，仅更新时间戳比当前事务读取的时间戳更早的数据：

UPDATE products SET price = 100 WHERE id = 1 AND last_modified <= <read_timestamp>;

四、实际应用中的考虑因素

（一） 性能影响

1. 不同的冲突解决方法对数据库性能有不同的影响。例如，使用封锁可能导致其他事务的等待，增加系统的阻塞时间，从而影响并发性。而乐观并发控制在冲突很少发生时性能较好，但在冲突频繁时可能导致大量的事务重试，增加了总体的执行时间。
2. 应用版本字段或基于时间戳的方法可能需要额外的存储空间来维护版本或时间戳信息，并在更新时进行额外的判断和处理。

（二） 业务逻辑适应性

1. 某些业务场景可能更适合某种特定的冲突解决方法。例如，如果业务对数据的一致性要求非常高，不能容忍任何不一致的情况，那么悲观并发控制或串行化隔离级别可能是更好的选择。
2. 对于冲突不太频繁且对响应时间要求较高的场景，乐观并发控制可能更合适。

（三） 数据分布和访问模式

1. 如果数据的访问是高度并发的，并且多个事务经常同时访问相同的数据行，那么需要更加谨慎地选择冲突解决方法，以避免过度的阻塞和冲突。
2. 对于数据分布较为均匀，冲突概率较低的情况，可以采用相对简单和高效的方法，如乐观并发控制。

五、示例分析

假设我们有一个在线商店的库存管理系统，其中有一个 inventory 表来存储商品的库存数量。

CREATE TABLE inventory (
    product_id INT PRIMARY KEY,
    quantity INT,
    last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

现在有两个并发的事务：

事务 1：

BEGIN;
SELECT * FROM inventory WHERE product_id = 1;
-- 假设读取到的数量为 10
UPDATE inventory SET quantity = 5 WHERE product_id = 1 AND last_updated <= <read_timestamp>;
COMMIT;

事务 2：

BEGIN;
SELECT * FROM inventory WHERE product_id = 1;
-- 假设也读取到的数量为 10
UPDATE inventory SET quantity = 8 WHERE product_id = 1 AND last_updated <= <read_timestamp>;
COMMIT;

如果这两个事务几乎同时执行，可能会发生冲突。

如果我们采用基于时间戳的冲突解决方法：

1. 事务 1 读取数据时获取了当前的时间戳（T1）。
2. 事务 2 读取数据时获取了稍晚的时间戳（T2）。

当事务 1 尝试更新时，如果自它读取以来没有其他事务修改数据（即 last_updated <= T1），则更新成功。

当事务 2 尝试更新时，如果发现数据的 last_updated 大于 T2（说明在事务 2 读取之后被修改过），则更新失败，事务 2 可以选择回滚并重试，或者根据业务逻辑进行其他处理。

🎉相关推荐

• 🍅关注博主🎗️ 带你畅游技术世界，不错过每一次成长机会！
• 📚领书：PostgreSQL 入门到精通.pdf
• 📙PostgreSQL 中文手册
• 📘PostgreSQL 技术专栏