INSERT 的并发场景
Concurrency scenarios with INSERTs
我正在 PHP + PostgreSQL 中设计一个预订系统。
我无法找到基于 INSERT 操作的并发问题的干净解决方案。
数据库系统主要由这些表组成：
CREATE TABLE booking (
booking_id INT,
user_id INT,
state SMALLINT,
nb_coupons INT
);
CREATE booking_state_history (
booking_state_history_id INT,
timestamp TIMESTAMP,
booking_id INT,
state SMALLINT);
CREATE TABLE coupon_purchase(
coupon_purchase_id,
user_id INT,
nb INT,
value MONEY)
CREATE TABLE coupon_refund(
coupon_refund_id INT,
user_id,
nb INT,
value MONEY)
CREATE TABLE booking_payment(
booking_payment_id INT,
user_id,
booking_id,
nb INT,
value MONEY)
必须使用用户之前购买的优惠券支付预订费用。部分优惠券可能已退款。所有这些操作都存储在两个相应的表中以保留历史记录并能够计算优惠券余额。
约束条件：优惠券余额任何时候都不能为负数
当使用优惠券支付时，预订完成。
然后会发生以下操作：
BEGIN;
(1) Check there are enough coupons remaining to pay the booking. (SELECT)
(2) Decide which coupons (number and value) will be used to pay the booking
(mainly, higher cost coupon used first. But that is not the issue here.)
(3) Add records to booking_payment (INSERTs)
(4) Move the booking to state="PAID" (integer value representing "PAID") (UPDATE)
(5) Add a record to booking_state_history (INSERT)
COMMIT;
这些操作需要是原子的以保持数据库信息的一致性。
因此使用允许 COMMIT 或 ROLLBACK 的事务，以防失败、DB 异常、PHP 异常或操作过程中的任何其他问题。
场景一
由于我处于并发访问环境（网站）中，所以没有什么能阻止用户（例如）在进行预订付款的同时要求优惠券退款。
场景二
他还可以在两笔不同的交易中同时触发两笔并发预订付款。
因此可能会发生以下情况：
场景一
(1)完成后，用户触发退还优惠券，后续优惠券余额已不足以支付预订费用。
当它 COMMITs 时，余额变为负数。
注意：
即使我在新的 (6) 步骤中重新检查优惠券余额，也有可能在 (6) 和 COMMIT.[=12 之间同时发生优惠券退款=]
场景二
两个并发的预订支付交易，支付的优惠券总数太多，导致全局余额无法保持正值。只有其中之一会发生。
交易 1 和交易 2 正在检查余额并查看足够的优惠券以用于步骤 (1) 中各自的付款。
他们继续他们的行动并 COMMIT。新余额为负且与约束冲突。
注意：
即使我在新的 (6) 步骤中重新检查优惠券余额，交易也看不到另一个交易尚未提交的操作。
所以他们盲目地进行 COMMIT.
我想这是一个常见的并发情况，但我在互联网上找不到解决这个问题的模式。
我想在 COMMIT 之后重新检查余额，这样我就可以手动 UNDO 所有操作。但这并不完全安全，因为如果在提交后发生异常，UNDO 将不会完成。
有解决这个并发问题的想法吗？
谢谢。
你的问题归结为"what should be the synchronization lock"的问题。从您的问题来看，预订似乎不是特定项目的预订。但是假设用户正在预订特定的酒店房间，因此您需要解决两个问题：
- 防止超额预订（例如为两个人预订同一件事）
- 防止平行账户状态误算
因此，当用户到达 he/she 即将点击 确认 按钮时，这是您可以实现的可能场景：
开始交易
锁定用户条目以阻止并行进程
SELECT * FROM user FOR UPDATE WHERE id = :id
重新检查账户余额，如果资金不足抛出异常/回滚
锁定要预订的项目以防止超额预订
SELECT * FROM room FOR UPDATE WHERE id = :id
重新检查预订可用性，如果项目已经预订则抛出异常/回滚
创建预订条目并从用户帐户中扣除资金
提交事务（将释放所有锁）
如果您的情况不需要检查超额预订，只需跳过/忽略第 4 步和第 5 步。
以下是我实施的解决方案。
注意:我只是处理了下面的优惠券转让部分，但预订状态更改和booking_state_history相同。
主要思想是将这部分处理保留为临界区。
当要插入 booking_payment、coupon_purchase 或 coupon_refund 时，我通过更新锁定专用的 table 来防止其他事务做同样的事情给定 user_id.
这样，只有影响此给定 user_id 的同类处理的交易才会被锁定。
初始化
DROP TABLE coupon_purchase;
DROP TABLE coupon_refund;
DROP TABLE booking_payment;
DROP TABLE lock_coupon_transaction;
CREATE TABLE coupon_purchase(
coupon_purchase_id SERIAL PRIMARY KEY,
user_id INT,
nb INT);
CREATE TABLE coupon_refund(
coupon_refund_id SERIAL PRIMARY KEY,
user_id INT,
nb INT);
CREATE TABLE booking_payment(
booking_payment_id SERIAL PRIMARY KEY,
user_id INT,
booking_id INT,
nb INT);
CREATE TABLE lock_coupon_transaction (
user_id INT,
timestamp TIMESTAMP);
INSERT INTO coupon_purchase
(user_id, nb) VALUES
(1, 1),
(1, 5);
INSERT INTO coupon_refund
(user_id, nb) VALUES
(1, 3);
INSERT INTO lock_coupon_transaction
(user_id, timestamp) VALUES
(1, current_timestamp);
事务 1
BEGIN;
UPDATE lock_coupon_transaction SET timestamp=current_timestamp WHERE user_id='1';
WITH coupon_balance AS (
SELECT
t1.nb_purchased_coupons -
t2.nb_refunded_coupons -
t3.nb_booking_payment_coupons AS total
FROM
(SELECT COALESCE(SUM(nb),0) AS nb_purchased_coupons FROM coupon_purchase WHERE user_id='1' ) t1,
(SELECT COALESCE(SUM(nb),0) AS nb_refunded_coupons FROM coupon_refund WHERE user_id='1' ) t2,
(SELECT COALESCE(SUM(nb),0) AS nb_booking_payment_coupons FROM booking_payment WHERE user_id='1' ) t3
)
INSERT INTO booking_payment
(user_id, booking_id, nb)
SELECT 1::INT, 1::INT, 3::INT
FROM coupon_balance
WHERE (total::INT >= 3::INT);
INSERT 0 1
事务 2
BEGIN;
UPDATE lock_coupon_transaction SET timestamp=current_timestamp WHERE user_id='1';
// Transaction is locked waiting for a COMMIT or ROLLBACK from transaction 1.
事务 1
COMMIT;
COMMIT
事务 2
// Transaction 1 lock has been released so transaction 2 can go on
WITH coupon_balance AS (
SELECT
t1.nb_purchased_coupons -
t2.nb_refunded_coupons -
t3.nb_booking_payment_coupons AS total
FROM
(SELECT COALESCE(SUM(nb),0) AS nb_purchased_coupons FROM coupon_purchase WHERE user_id='1' ) t1,
(SELECT COALESCE(SUM(nb),0) AS nb_refunded_coupons FROM coupon_refund WHERE user_id='1' ) t2,
(SELECT COALESCE(SUM(nb),0) AS nb_booking_payment_coupons FROM booking_payment WHERE user_id='1' ) t3
)
INSERT INTO coupon_refund
(user_id, nb)
SELECT 1::INT, 3::INT
FROM coupon_balance
WHERE (total::INT >= 3::INT);
INSERT 0 0
COMMIT;
COMMIT
INSERT 无法完成，因为帐户中的资金不足。这是预期的行为。
前一个事务在第二个事务进行时提交。所以事务 2 可以看到事务 1 所做的所有更改。
这样就没有并发访问优惠券处理的风险。
我正在 PHP + PostgreSQL 中设计一个预订系统。 我无法找到基于 INSERT 操作的并发问题的干净解决方案。
数据库系统主要由这些表组成：
CREATE TABLE booking (
booking_id INT,
user_id INT,
state SMALLINT,
nb_coupons INT
);
CREATE booking_state_history (
booking_state_history_id INT,
timestamp TIMESTAMP,
booking_id INT,
state SMALLINT);
CREATE TABLE coupon_purchase(
coupon_purchase_id,
user_id INT,
nb INT,
value MONEY)
CREATE TABLE coupon_refund(
coupon_refund_id INT,
user_id,
nb INT,
value MONEY)
CREATE TABLE booking_payment(
booking_payment_id INT,
user_id,
booking_id,
nb INT,
value MONEY)
必须使用用户之前购买的优惠券支付预订费用。部分优惠券可能已退款。所有这些操作都存储在两个相应的表中以保留历史记录并能够计算优惠券余额。 约束条件：优惠券余额任何时候都不能为负数
当使用优惠券支付时，预订完成。
然后会发生以下操作：
BEGIN;
(1) Check there are enough coupons remaining to pay the booking. (SELECT)
(2) Decide which coupons (number and value) will be used to pay the booking
(mainly, higher cost coupon used first. But that is not the issue here.)
(3) Add records to booking_payment (INSERTs)
(4) Move the booking to state="PAID" (integer value representing "PAID") (UPDATE)
(5) Add a record to booking_state_history (INSERT)
COMMIT;
这些操作需要是原子的以保持数据库信息的一致性。
因此使用允许 COMMIT 或 ROLLBACK 的事务，以防失败、DB 异常、PHP 异常或操作过程中的任何其他问题。
场景一
由于我处于并发访问环境（网站）中，所以没有什么能阻止用户（例如）在进行预订付款的同时要求优惠券退款。
场景二
他还可以在两笔不同的交易中同时触发两笔并发预订付款。
因此可能会发生以下情况：
场景一 (1)完成后，用户触发退还优惠券，后续优惠券余额已不足以支付预订费用。 当它 COMMITs 时，余额变为负数。 注意： 即使我在新的 (6) 步骤中重新检查优惠券余额，也有可能在 (6) 和 COMMIT.[=12 之间同时发生优惠券退款=]
场景二
两个并发的预订支付交易，支付的优惠券总数太多，导致全局余额无法保持正值。只有其中之一会发生。 交易 1 和交易 2 正在检查余额并查看足够的优惠券以用于步骤 (1) 中各自的付款。 他们继续他们的行动并 COMMIT。新余额为负且与约束冲突。 注意： 即使我在新的 (6) 步骤中重新检查优惠券余额，交易也看不到另一个交易尚未提交的操作。 所以他们盲目地进行 COMMIT.
我想这是一个常见的并发情况，但我在互联网上找不到解决这个问题的模式。
我想在 COMMIT 之后重新检查余额，这样我就可以手动 UNDO 所有操作。但这并不完全安全，因为如果在提交后发生异常，UNDO 将不会完成。
有解决这个并发问题的想法吗？
谢谢。
你的问题归结为"what should be the synchronization lock"的问题。从您的问题来看，预订似乎不是特定项目的预订。但是假设用户正在预订特定的酒店房间，因此您需要解决两个问题：
- 防止超额预订（例如为两个人预订同一件事）
- 防止平行账户状态误算
因此，当用户到达 he/she 即将点击 确认 按钮时，这是您可以实现的可能场景：
开始交易
锁定用户条目以阻止并行进程
SELECT * FROM user FOR UPDATE WHERE id = :id重新检查账户余额，如果资金不足抛出异常/回滚
锁定要预订的项目以防止超额预订
SELECT * FROM room FOR UPDATE WHERE id = :id重新检查预订可用性，如果项目已经预订则抛出异常/回滚
创建预订条目并从用户帐户中扣除资金
提交事务（将释放所有锁）
如果您的情况不需要检查超额预订，只需跳过/忽略第 4 步和第 5 步。
以下是我实施的解决方案。
注意:我只是处理了下面的优惠券转让部分，但预订状态更改和booking_state_history相同。
主要思想是将这部分处理保留为临界区。 当要插入 booking_payment、coupon_purchase 或 coupon_refund 时，我通过更新锁定专用的 table 来防止其他事务做同样的事情给定 user_id.
这样，只有影响此给定 user_id 的同类处理的交易才会被锁定。
初始化
DROP TABLE coupon_purchase;
DROP TABLE coupon_refund;
DROP TABLE booking_payment;
DROP TABLE lock_coupon_transaction;
CREATE TABLE coupon_purchase(
coupon_purchase_id SERIAL PRIMARY KEY,
user_id INT,
nb INT);
CREATE TABLE coupon_refund(
coupon_refund_id SERIAL PRIMARY KEY,
user_id INT,
nb INT);
CREATE TABLE booking_payment(
booking_payment_id SERIAL PRIMARY KEY,
user_id INT,
booking_id INT,
nb INT);
CREATE TABLE lock_coupon_transaction (
user_id INT,
timestamp TIMESTAMP);
INSERT INTO coupon_purchase
(user_id, nb) VALUES
(1, 1),
(1, 5);
INSERT INTO coupon_refund
(user_id, nb) VALUES
(1, 3);
INSERT INTO lock_coupon_transaction
(user_id, timestamp) VALUES
(1, current_timestamp);
事务 1
BEGIN;
UPDATE lock_coupon_transaction SET timestamp=current_timestamp WHERE user_id='1';
WITH coupon_balance AS (
SELECT
t1.nb_purchased_coupons -
t2.nb_refunded_coupons -
t3.nb_booking_payment_coupons AS total
FROM
(SELECT COALESCE(SUM(nb),0) AS nb_purchased_coupons FROM coupon_purchase WHERE user_id='1' ) t1,
(SELECT COALESCE(SUM(nb),0) AS nb_refunded_coupons FROM coupon_refund WHERE user_id='1' ) t2,
(SELECT COALESCE(SUM(nb),0) AS nb_booking_payment_coupons FROM booking_payment WHERE user_id='1' ) t3
)
INSERT INTO booking_payment
(user_id, booking_id, nb)
SELECT 1::INT, 1::INT, 3::INT
FROM coupon_balance
WHERE (total::INT >= 3::INT);
INSERT 0 1
事务 2
BEGIN;
UPDATE lock_coupon_transaction SET timestamp=current_timestamp WHERE user_id='1';
// Transaction is locked waiting for a COMMIT or ROLLBACK from transaction 1.
事务 1
COMMIT;
COMMIT
事务 2
// Transaction 1 lock has been released so transaction 2 can go on
WITH coupon_balance AS (
SELECT
t1.nb_purchased_coupons -
t2.nb_refunded_coupons -
t3.nb_booking_payment_coupons AS total
FROM
(SELECT COALESCE(SUM(nb),0) AS nb_purchased_coupons FROM coupon_purchase WHERE user_id='1' ) t1,
(SELECT COALESCE(SUM(nb),0) AS nb_refunded_coupons FROM coupon_refund WHERE user_id='1' ) t2,
(SELECT COALESCE(SUM(nb),0) AS nb_booking_payment_coupons FROM booking_payment WHERE user_id='1' ) t3
)
INSERT INTO coupon_refund
(user_id, nb)
SELECT 1::INT, 3::INT
FROM coupon_balance
WHERE (total::INT >= 3::INT);
INSERT 0 0
COMMIT;
COMMIT
INSERT 无法完成，因为帐户中的资金不足。这是预期的行为。
前一个事务在第二个事务进行时提交。所以事务 2 可以看到事务 1 所做的所有更改。
这样就没有并发访问优惠券处理的风险。