1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Redisで同時実行性問題を解消した話

Posted at

問題の背景

MySQLだけではなぜ防げなかったのか?

MySQLで抽選ごとの「最大当選可能数」と「現在の当選者数」を管理していた。

アクセスが集中すると、複数のユーザーがほぼ同時に抽選処理を実行。
あるリクエストが「現在の当選者数」を読み取り、「まだ上限に達していない」と判断してから、実際に当選者数をインクリメントして書き込むまでのごくわずかな時間差があった。
この間に別のリクエストも同様に「まだ上限に達していない」と判断し、結果的に両方のリクエストが当選処理を行ってしまう競合状態が発生。
データベースレベルでの適切なロックや、アプリケーションレベルでの排他制御が施されていなかったため、当選者数が上限を超過する事態を招いた。

図で見るとこんな感じ

image.png

Redisを使っても上記の図のような挙動に

$remaining = Redis::incr('present_win_count');
$total_win_count = Redis::get('total_win_count')
if ($remaining < $total_win_count) {
    // 当選処理
} else {
    // 落選処理
}

上記のように一回Redisからpresent_win_count値を取得→当選処理を行うと結局Mysqlを使ったデータ処理と同じフローになる。

解決策

RedisとLuaスクリプト

Luaスクリプトを使うと全体をアトミックに(不可分な操作として)実行。
つまり、スクリプトの実行が開始されたら、それが完了するまで他のどのコマンドも割り込むことができない。

以下のロジックをLuaスクリプトとして記述し、Redisサーバー上で実行。

  1. 現在の当選者数を取得
  2. 取得した当選者数が、あらかじめ設定された最大当選可能数未満かチェック
  3. もし上限未満であれば、当選者数を1増加させ、当選したことを記録
  4. 上限に達していれば、落選処理

image.png

感想

Redisはこれまでキャッシュ用途にしか使っていなかった。
シングルスレッド特性とLuaスクリプトの組み合わせによって、同時実行制御といったユースケースにも十分に対応できることを実感した。
今回の経験は、Redisの可能性を再認識し、今後より多様な場面で活用していきたいという気づきにつながった!

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?