セッションの概念は、私が自分で書いた PHP 7 開発フレームワークにはもう存在しません
ユーザーにはキャッシュ+Cookieを使って問題を解決してほしい
実際に知りたいのは、ユーザーのログインを維持するだけです
Cookie を使用して対称的に暗号化して保存し、PHP を使用して復号化してテーブルを検索します
実際には、セッションでユーザー UID を記録することと、テーブルを検索することの間に本質的な違いはありません
閑話休題
Cookie はユーザーのハッシュ化されたパスワードとユーザー名を保存します。毎回ログインをシミュレートすることも不可能ではありません。
実際、データベースまたはキャッシュされたデータはセッションの実用性に匹敵するはずです結局のところ、セッションには回復メカニズムがあります。毎日 100,000 人が Web サイトにログインすると、セッションメカニズムによって引き起こされる I/O ボトルネックはデータベースのボトルネックよりも過酷になる可能性があります。
また余談
ショッピングカートの実装に関しては、実際にはキャッシュ
キーVALUEショッピングカートの内容
を直接呼び出すことが可能です。
あまりにもランダムで信頼性が低いため、セッションを今も使用することにどのような意味があるのか教えていただければ幸いです
セッションの概念は、私が自分で書いた PHP 7 開発フレームワークにはもう存在しません
実際に知りたいのは、ユーザーのログインを維持するだけです
Cookie を使用して対称的に暗号化して保存し、PHP を使用して復号化してテーブルを検索します
実際には、セッションでユーザー UID を記録することと、テーブルを検索することの間に本質的な違いはありません閑話休題
Cookie はユーザーのハッシュ化されたパスワードとユーザー名を保存します。毎回ログインをシミュレートすることも不可能ではありません。
結局のところ、セッションには回復メカニズムがあります。毎日 100,000 人が Web サイトにログインすると、セッションメカニズムによって引き起こされる I/O ボトルネックはデータベースのボトルネックよりも過酷になる可能性があります。
また余談
ショッピングカートの実装に関しては、実際にはキャッシュ
キーVALUEショッピングカートの内容
を直接呼び出すことが可能です。あまりにもランダムで信頼性が低いため、セッションを今も使用することにどのような意味があるのか教えていただければ幸いです
1. たとえ暗号化されていても、セキュリティ上のリスクがあるため、ユーザーのパスワードなどの情報を Cookie に含めないでください。
2. キャッシュを使用する必要があるため、Redis に直接アクセスして、製品情報とユーザーのショッピング カートを Redis のハッシュ テーブルに配置することをお勧めします。
大丈夫、それが休息の意味です。
便利なので今でもセッションを使用しています
あと、ログインをシミュレートするたびにテーブルをチェックしないでください。最近ログインしたユーザー情報を保存するには、redis などを使用することをお勧めします。