ロードバランシングとスティッキーセッション
私が理解していることによると、スティッキーセッションの使用は、ユーザーを同じバックエンドにルーティングすることであるため、たとえば、再ルーティングされるたびに再度ログインする必要はありません。また、ショッピングカートがある場合は、ログインしません。アイテムなどを失うこともあります。ただし、状態をバックエンドサーバーに保存しないことをお勧めします。この場合、セッションをDBまたはメモリ内のDBに保存することをお勧めします。あれは正しいですか ？もしそうなら、例えば、DBに状態を保存するときにスティッキーセッションを使用することに意味はありますか？
スティッキーセッションの目的は、通常、バックエンドがアップしている場合、ユーザーが常に同じバックエンドに誘導されるようにすることです（通常、ユーザーがダウンしている場合は、他のバックエンドに移動する必要があります）。
そのことを念頭に置いて、バックエンドに障害が発生したり、再起動したり、なくなったり、アップグレードされたり、問題が発生したりすると、ユーザーは別のバックエンドに移動することになります。したがって、セッションデータをバックエンドにのみ保存すると、ユーザーはセッションデータを失います。 （再ログオン、カートの紛失など）。
したがって、すべての場合において、セッションはバックエンド間で複製するか（バックエンドのメモリに保持する場合）、Redis、Memcached、RDBMSなどのセッションストアに保持する必要があります。そうでない場合、サービスレベルは比較的低くなります。
バックエンドの外部のセッションストアにセッションを保持している場合でも、スティッキーセッションは必要ですか？
それは本当にあなたの環境、アーキテクチャ、デザインなどに依存します。それはあなたにとって理にかなっているかもしれませんし、必要でないかもしれません。
スティッキーセッションの使用を正当化する可能性のあるセッション以外のものがあるかもしれません。ファイルを処理するWebサービスがあるとします。ユーザーがファイルをアップロードし、複数のバックエンドの1つによって処理されています。最初の呼び出しに続いて、ファイルの処理のステータスを確認するために追加の呼び出しが行われます。ステータスのリクエストは、ファイルを処理しているバックエンドに送信する必要があります。スティッキーセッションはそれを助けるでしょう。もちろん、バックエンドが停止すると、ファイル処理は停止し、次のステータス要求は「ジョブはもう存在しません！」のようなものを返します。
もちろん、ステータスの更新をデータベース（Redisなど）に保存して、ステータスリクエストを任意のバックエンドに送信することもできます。しかし、それはより複雑であり、より複雑であることが常に保証されるわけではありません。
一般に、セットアップが非常に小さく、ユーザーベースが小さい場合、スティッキーセッションは、セッションストアを備えたより複雑なインフラストラクチャよりも一般的に優れています。おそらく高い稼働時間を維持するために、複数のバックエンドを実行していることになります。したがって、外部セッションストアがある場合は、そのHAも作成する必要があります...システムの複雑さが増します。
それが私がITで気に入っていることです-すべてについて、それは異なります...