ウェブサイトのセッション管理に DDB を使用することを考えています。ユーザーがログインすると、セッション ID がデータベースと Cookie に保存され、リクエストごとにデータベースで Cookie からのセッション ID がチェックされます。まだ設計段階にいます。
ログイン中にセッションが作成されたが、結果整合性のために次のリクエストでそのセッションが見つからないというシナリオを防ぐには、強い整合性が必要だと思います。ただし、強整合性は低速であり、すべてのリクエストにこれを使用すると、レイテンシのオーバーヘッドが大幅に増加するように思えます。
私の懸念は正しいでしょうか？
最終的な整合性はセッション管理に十分ですか?
DDB はセッションには適していませんか? もしそうであれば、より適したデータストアは何ですか?
------------------------
DynamoDB のユースケースの 1 つは、正しくセッション ストアとして特定されたとおりです。
一部の言語 (PHP など) には、SDK にセッションごとに準備完了のハンドラーがあります。お使いの言語に対応したハンドラーがない場合は、ここで PHP の実装を確認してください。
一貫性に関しては、強力な一貫性またはトランザクション一貫性の使用のいずれかです。さらに、セッションのロック ステータスを含む属性を追加すると、セッションの衝突を防ぐことができます。
セッション ハンドラーとして Redis を使用することも検討できます。AWS には、これを提供する ElastiCache を備えたマネージド サービスがあります。
4
まだレイテンシの要件はありませんが、強い一貫性を使用するためにすべてのリクエストにさらに数秒かかることも望ましくありません。そんなことは起こりますか？
– ワンピース
2020 年 9 月 3 日 10:46
アプリケーションによっては、それほど時間がかかることはありません。一般に、これが実装されているのを見たとき、これを true に設定するロックステータスを持つ属性を追加します。あなたはその時だけ泣きます終了時に DynamoDB に送信されます。これは、プロセス全体で 2 回の書き込みと 1 回の読み取りになります。 :)
– クリス・ウィリアムズ
2020 年 9 月 3 日 11:28
セッションの衝突とはどういう意味ですか?私のセッションはランダムに生成された UUID によって識別されるため、衝突は発生しないと考えています。ロックはどのように機能しますか? 2 回の書き込みと 1 回の読み取りが何なのかわかりません。
– ワンピース
2020 年 9 月 7 日 5:57
アプリケーションによっては、非同期リクエストがある場合、読み取りと書き込みの両方を同時に行おうとすることで衝突が発生する可能性があり、その結果、一方が他方をオーバーライドする可能性があります。これが、ロック セッションが存在する理由です。フローは、セッションの読み取りが 1 回、書き込みが 1 回でロックされ、タスクが完了したら書き込みが 1 回行われ、最新のセッション データが追加されます。
– クリス・ウィリアムズ
2020 年 9 月 7 日 6:26
