それは、この HTTP リクエストの戻り結果をデータベース操作の結果と関連付けたいかどうか、およびユーザー対話設計がこの操作にかかる時間を許容できるかどうかによって異なります。

この「/blog」インターフェイスを設計するときは、HTTP が 200 を返すときの意味を明確に示す必要があります。ビジネス シナリオがバックエンドへのデータ配信のみを考慮し、バックエンドがデータベースに正しく保存されているかどうかを考慮しない場合は、HTTP リクエストを直接終了できます。エンド ユーザーにこの正確な送信結果を取得してもらいたい場合は、インタラクション レベルを考慮して適切なインタラクション効果を設計する必要があります。2 ～ 6 秒待つと、ユーザー エクスペリエンスは悪くなくなります (AJAX リクエスト シナリオを参照)。新しいページのシナリオ）まだ注意してください）。 Redis への 3 回の書き込みにはほとんど時間がかかりません。HTTP リクエスト自体のリンク遅延に比べれば大したことはありません。

特定のビジネスシナリオを詳細に分析する必要があります。特に時間のかかる操作が発生した場合は、フロントエンドで操作リクエストを送信した後に結果をローテーションすることも解決策です。

ページの表示とデータベースの操作結果に相関があるかどうかを確認します。相関関係がある場合は、データベース操作が完了するまで待ってから戻ることができます。非同期キューに直接返すこともでき、成功後に結果がプッシュされます。結局のところ、それはすべてあなたのニーズ次第です。