メッセージキュー
Message Queues
重い処理を後回しにするための『仕事の待ち行列』。ユーザーを待たせず受付だけ済ませ、裏のワーカーが順次処理する。リクエストの体感を速くする非同期処理の中核。
たとえ話: レストランの注文票
ウェイター(=アプリ)はお客さん(=ユーザー)から注文を受けたら、注文票をキッチンの回転ラックに刺すだけでテーブルを離れます。お客さんを立たせたまま料理ができるのを待たせはしません。
キッチンの料理人(=ワーカー)は、ラックから注文票を順に取って調理します。これがメッセージキューの働きです。受付(速い)と実処理(遅い)を切り離すことで、ユーザーを待たせません。
図を描画中...
具体例: ツイート投稿
ツイートを投稿すると、本来は『数百万人のフォロワー全員のタイムラインに配信』『通知送信』など重い処理が必要です。これを同期でやると、投稿ボタンを押してから数秒〜数十秒固まってしまう。
そこで投稿は即座に『完了』とし、フォロワーへの配信(fan-out)はキューに入れて裏で処理します。ユーザーから見れば一瞬で投稿完了。配信は数秒遅れて届く(結果整合性)。
ツールの違い
| ツール | 特徴 |
|---|---|
| Redis | 簡易なブローカー。速いがメッセージ消失の可能性あり |
| RabbitMQ | AMQPプロトコル。高機能だが自前でノード管理が必要 |
| Amazon SQS | マネージドで楽。ただし高レイテンシ・二重配信の可能性 |
つまずきポイント
- キューを挟むと『すぐ反映されない』(結果整合性)。投稿直後にフォロワー画面に出ていなくても正常。
- 二重配信(同じメッセージが2回届く)が起きうるツールもある。ワーカーは**冪等(同じ処理を2回しても結果が変わらない)**に作るのが安全。
- 何でもキューに入れればいいわけではない。一瞬で終わる処理や即時性が必要な処理は、同期の方がシンプルで速い。
📊 図解
非同期で即応答が返る流れ(シーケンス図)
ユーザーを待たせず受付だけ返し、重い処理は裏のワーカーが進めます。
図を描画中...