トランザクションの分離レベルと、起きる問題を説明できますか

3 つの読み取りの問題

• ダーティリードほかのトランザクションが、まだコミットしていない書き込みを読んでしまうこと。相手が取り消すと、無かった値を読んだことになります
• ノンリピータブルリード (ファジーリードとも言います) 同じ行を 2 回読むと、その間にほかのトランザクションがコミットした更新で、値が変わっていること
• ファントムリード同じ条件で 2 回読むと、その間に行が足されたり消されたりして、条件に合う行の集まりが変わっていること

さらに、1 つずつ順に流したどの順番とも合わない結果になる、直列化異常という問題もあります。

4 つのレベル

SQL の標準では、Read Uncommitted、Read Committed、Repeatable Read、Serializable の順に、防ぐ問題が増えます。Serializable は、1 つずつ順に流したのと同じ結果を約束する、いちばん強いレベルです。

ただし、DB ごとに既定と動きが違います。

• PostgreSQL 既定は Read Committed です。Read Uncommitted を指定しても Read Committed と同じ動きになり、Repeatable Read でもファントムリードは起きません
• MySQL (InnoDB) 既定は Repeatable Read です

なので、「この DB の既定はどれで、そのレベルで何が起きるか」を、使う DB の文書で確かめます。

在庫を守る

在庫が 1 個の商品を 2 人が同時に買うと、2 人とも「残り 1」と読んで、2 人とも買えてしまうことがあります。読んでから書くまでの間に、相手の更新が割り込むからです。

1 つ目の手は、読むときに行をロックすることです (悲観ロック)。

BEGIN;
SELECT stock FROM items WHERE id = 7 FOR UPDATE;
-- stock が 1 以上なら
UPDATE items SET stock = stock - 1 WHERE id = 7;
COMMIT;

FOR UPDATE を付けると、ほかのトランザクションは、この行をロックしようとするとコミットまで待たされます。

2 つ目の手は、version の列で「読んだときから変わっていないか」を書くときに確かめることです (楽観ロック)。

UPDATE items
SET stock = stock - 1, version = version + 1
WHERE id = 7 AND version = 3 AND stock > 0;
-- 更新した行が 0 なら、誰かが先に変えたので、やり直すか断る

トレードオフ

• 分離レベルを上げる食い違いは減りますが、待ちや、DB による取り消し (直列化の失敗) が増え、やり直しの処理が要ります
• 行ロック確実ですが、取り合いが多いと待ちが長くなり、ロックの順番によってはデッドロック (互いに相手を待って止まること) も起きます。同時に同じ行を触ることが多い場面に向きます
• 楽観ロック待たずに済みますが、ぶつかったときにやり直すか断る処理が要ります。ぶつかることが少ない場面に向きます

在庫を減らすだけなら、WHERE stock > 0 を付けた 1 本の UPDATE で、減らせたかを見る、という簡単な手で足りることもあります。

話すときは、自分が関わったサービスで「同時に押されたら困る処理」を 1 つ挙げ、どの手で守ったかを話します。