Redisデータベースはセッションを保存して現在のユーザー情報を保存します
5843 ワード
HTTPプロトコルの無状態特性(業務処理に対する記憶能力がない)は、後続の処理に前の情報が必要である場合、前の情報を再送しなければならない.これにより、リンク転送ごとにデータ量が増加する.HTTPプロトコルのこの欠点を克服するために,HTTPリンク状態を維持するための2つの技術CookieとSessionが出現した.
一.Cookie
Cookieはサーバ側で生成され、User-Agent(一般的にwebブラウザ)に送信され、ブラウザはCookieのkey/valueをあるディレクトリの下のテキストファイルに保存し、次回同じサイトを要求するとそのCookieをサーバに送信する(ブラウザがCookieを有効にするように設定されていることを前提とする).Cookie名と値はサーバ側が独自に定義することができ、JSPに対してはSessionidに直接書き込むこともでき、サーバはそのユーザが正当なユーザであるかどうか、再ログインが必要であるかどうかなどを知ることができる.
Cookieの用途
Cookiesの最も典型的な応用は、登録ユーザーがすでにウェブサイトにログインしているかどうかを判定することであり、ユーザーは次回このウェブサイトにアクセスする際にユーザー情報を保持してログイン手続きを簡素化するかどうかを提示される可能性があります.これらはCookiesの機能です.もう一つの重要な応用場面は「ショッピングカート」のような処理です.ユーザーは、最終支払時に情報を抽出するためにCookiesに書き込まれる同じWebサイトの異なるページで異なる商品を選択する場合があります.
Cookie生存サイクル
Cookieは、ユーザーが次回サーバとのセッションにログイン情報を保持することができ、言い換えれば、次回同じサイトにアクセスすると、ユーザー名とパスワードを入力する必要がなくログインしていることに気づく(もちろん、ユーザーが手動でCookieを削除することは排除されない).また、一部のCookieは、ユーザーがセッションを終了したときに削除され、プライバシーを効果的に保護することができます.
Cookieは生成時にExpire値を指定されます.これがCookieの生存周期です.この周期でCookieは有効で、周期を超えるとCookieはクリアされます.一部のページでは、Cookieの生存期間を「0」または負の値に設定しているため、ページを閉じるとすぐにCookieが消去され、ユーザー情報が記録されず、より安全になります.
二.Session
Sessionとは、端末ユーザがインタラクティブシステムと通信する時間間隔を指し、通常、登録からシステムへのログアウトまでの時間と、必要に応じて操作空間がある可能性がある.Sessionは実際には特定の時間概念である.
セッションの生成
クライアントがサーバにアクセスすると、サーバは必要に応じてSessionを設定し、セッション情報をサーバに保存するとともに、Sessionを示すSessionIdをクライアントブラウザに渡し、ブラウザはこのSessionIdをメモリに保存し、期限切れのないCookieと呼ぶ.ブラウザが閉じると、このCookieは消去され、ユーザーのCookie一時ファイルには存在しません.以降はブラウザが要求するたびにこのパラメータ値を追加し,サーバはこのSessionIdに基づいてクライアントのデータ情報を取得する.Sessionの作成プロセスブラウザであるウェブサイトサーバにログインする場合、まず対応するCookieファイルを探し、最初のアクセスが当然Cookieファイルがないため、要求ヘッダにCookieのような内容がない、すなわち要求ヘッダにCookie:JSESIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXのような内容がない、このとき要求がサーバに到着すると、サーバは要求ヘッダにJESSIONID値がないことを見て、Sessionオブジェクトを生成し、あるアルゴリズムによってこのSessionのidに値を付与し、SessionIdとSessionオブジェクトをHashMapに入れ、このSessionIdをクライアントに送り返します.すなわち、応答のヘッダに1行あります.Set-Cookie:JSESIONID=XXXXXXXXXXXXXXXXXX、ブラウザで解析すると、JESSIONIDと値がCookieに記録されます.Sessionの役割ブラウザで再度このサイトの別のページを要求する時、ブラウザはCookieがあるかどうかを検査して、この時Cookieがある(Cookieが期限切れではないことを前提として)、自動的にCookieの内容を要求の頭の中に添付して、つまり要求の頭の中で1行を添付しました:Cookie:JESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX、サーバは要求を受信するとJSESIONIDの値に基づいてSessionIdの値を知ることができ、tomcatでは2つの値が同じである.その後、このSessionIdに基づいて対応するSessionを見つけることができ、Sessionでログインした後に設定したいくつかの値が空であるかによって、このユーザが登録しているかどうかを判断することができる.ユーザが安全にログインすると(session.invalidate()を呼び出す)、サーバはSessionを破棄し、新しいJESSIONIDを生成してクライアントに返信し、ブラウザは応答を受信するとCookieのJESSIONIDを新しい値に変換し、ユーザが再びこのサーバにアクセスすると、要求に自動的に新しいJESSIONIDを追加する値がサーバに送信され、このときサーバはJESSIONIDによって対応していないSessionを探しているので,新しいセッションであることがわかり,サーバはSessionオブジェクトを生成し,クライアントから送られてきたJESSIONの値をこのSessionのidに与える.クライアントがCookieを無効にした場合、サーバはセッションの内容をクライアントに対応させることができません.
redisデータベース
redisは、オープンソースでC言語で記述され、ネットワークインタラクションをサポートし、メモリベースでも持続可能なKey-Valueデータベースです.redisは高度なkey:valueストレージシステムであり、valueは5つのデータ型をサポートしている:1.文字列(strings)2.文字列リスト(lists)3.文字列セット(sets)4.秩序文字列セット(sorted sets)5.ハッシュ(hashes)メモリ型データベースの利点に鑑み、各クライアントのSession情報をキャッシュデータベースに保存することが多い.
クライアント1回目のログインインスタンスクライアント1回目のログイン時のサーバSelvetの処理(javaコード)を解析する
次に、AccessTokenTool.create()関数の実装を見てみましょう.
この関数は主に次の関数を呼び出してredisに情報を格納します.
我々はpublic boolean setex(String key,int seconds,String value)関数に注目し,ランダム関数RandomUtils.genUUID()から生成されたUUIDがKey値として取り込まれ,カスタムdefalut_time有効時間およびユーザID useridはvalueとしてredisサーバに格納される.setex関数はjedis(java操作redisサーバのサードパーティライブラリ)をカプセル化する関数です.これにより、現在ログインしているユーザの情報は、redisサーバであるUUID/useridにキー値ペアとして保存される.そのうちACCESS_TOKENとUUIDもキー値ペアでJSONオブジェクトに保存され、jsonObjectを介してクライアントに送信されて保存される.クライアントが接続を切断していない場合、要求パケットを2回目に送信すると自動的にACCESS_TOKENはパケットにカプセル化され、サーバに対応するselvetによってACCESS_を解析する.TOKENのUUIDは、UUIDをキー値としてredisデータベースから対応するvalue、すなわちSessionを取り出し、そのユーザであるか否かを比較する.redisからSessionの関数をとる
一.Cookie
Cookie Lou Montulli 1993 3 。
Cookieはサーバ側で生成され、User-Agent(一般的にwebブラウザ)に送信され、ブラウザはCookieのkey/valueをあるディレクトリの下のテキストファイルに保存し、次回同じサイトを要求するとそのCookieをサーバに送信する(ブラウザがCookieを有効にするように設定されていることを前提とする).Cookie名と値はサーバ側が独自に定義することができ、JSPに対してはSessionidに直接書き込むこともでき、サーバはそのユーザが正当なユーザであるかどうか、再ログインが必要であるかどうかなどを知ることができる.
Cookieの用途
Cookiesの最も典型的な応用は、登録ユーザーがすでにウェブサイトにログインしているかどうかを判定することであり、ユーザーは次回このウェブサイトにアクセスする際にユーザー情報を保持してログイン手続きを簡素化するかどうかを提示される可能性があります.これらはCookiesの機能です.もう一つの重要な応用場面は「ショッピングカート」のような処理です.ユーザーは、最終支払時に情報を抽出するためにCookiesに書き込まれる同じWebサイトの異なるページで異なる商品を選択する場合があります.
Cookie生存サイクル
Cookieは、ユーザーが次回サーバとのセッションにログイン情報を保持することができ、言い換えれば、次回同じサイトにアクセスすると、ユーザー名とパスワードを入力する必要がなくログインしていることに気づく(もちろん、ユーザーが手動でCookieを削除することは排除されない).また、一部のCookieは、ユーザーがセッションを終了したときに削除され、プライバシーを効果的に保護することができます.
Cookieは生成時にExpire値を指定されます.これがCookieの生存周期です.この周期でCookieは有効で、周期を超えるとCookieはクリアされます.一部のページでは、Cookieの生存期間を「0」または負の値に設定しているため、ページを閉じるとすぐにCookieが消去され、ユーザー情報が記録されず、より安全になります.
二.Session
Sessionとは、端末ユーザがインタラクティブシステムと通信する時間間隔を指し、通常、登録からシステムへのログアウトまでの時間と、必要に応じて操作空間がある可能性がある.Sessionは実際には特定の時間概念である.
セッションの生成
クライアントがサーバにアクセスすると、サーバは必要に応じてSessionを設定し、セッション情報をサーバに保存するとともに、Sessionを示すSessionIdをクライアントブラウザに渡し、ブラウザはこのSessionIdをメモリに保存し、期限切れのないCookieと呼ぶ.ブラウザが閉じると、このCookieは消去され、ユーザーのCookie一時ファイルには存在しません.以降はブラウザが要求するたびにこのパラメータ値を追加し,サーバはこのSessionIdに基づいてクライアントのデータ情報を取得する.Sessionの作成プロセスブラウザであるウェブサイトサーバにログインする場合、まず対応するCookieファイルを探し、最初のアクセスが当然Cookieファイルがないため、要求ヘッダにCookieのような内容がない、すなわち要求ヘッダにCookie:JSESIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXのような内容がない、このとき要求がサーバに到着すると、サーバは要求ヘッダにJESSIONID値がないことを見て、Sessionオブジェクトを生成し、あるアルゴリズムによってこのSessionのidに値を付与し、SessionIdとSessionオブジェクトをHashMapに入れ、このSessionIdをクライアントに送り返します.すなわち、応答のヘッダに1行あります.Set-Cookie:JSESIONID=XXXXXXXXXXXXXXXXXX、ブラウザで解析すると、JESSIONIDと値がCookieに記録されます.Sessionの役割ブラウザで再度このサイトの別のページを要求する時、ブラウザはCookieがあるかどうかを検査して、この時Cookieがある(Cookieが期限切れではないことを前提として)、自動的にCookieの内容を要求の頭の中に添付して、つまり要求の頭の中で1行を添付しました:Cookie:JESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX、サーバは要求を受信するとJSESIONIDの値に基づいてSessionIdの値を知ることができ、tomcatでは2つの値が同じである.その後、このSessionIdに基づいて対応するSessionを見つけることができ、Sessionでログインした後に設定したいくつかの値が空であるかによって、このユーザが登録しているかどうかを判断することができる.ユーザが安全にログインすると(session.invalidate()を呼び出す)、サーバはSessionを破棄し、新しいJESSIONIDを生成してクライアントに返信し、ブラウザは応答を受信するとCookieのJESSIONIDを新しい値に変換し、ユーザが再びこのサーバにアクセスすると、要求に自動的に新しいJESSIONIDを追加する値がサーバに送信され、このときサーバはJESSIONIDによって対応していないSessionを探しているので,新しいセッションであることがわかり,サーバはSessionオブジェクトを生成し,クライアントから送られてきたJESSIONの値をこのSessionのidに与える.クライアントがCookieを無効にした場合、サーバはセッションの内容をクライアントに対応させることができません.
redisデータベース
redisは、オープンソースでC言語で記述され、ネットワークインタラクションをサポートし、メモリベースでも持続可能なKey-Valueデータベースです.redisは高度なkey:valueストレージシステムであり、valueは5つのデータ型をサポートしている:1.文字列(strings)2.文字列リスト(lists)3.文字列セット(sets)4.秩序文字列セット(sorted sets)5.ハッシュ(hashes)メモリ型データベースの利点に鑑み、各クライアントのSession情報をキャッシュデータベースに保存することが多い.
クライアント1回目のログインインスタンスクライアント1回目のログイン時のサーバSelvetの処理(javaコード)を解析する
public JsonObject process(RequestParam param) throws Exception {
//param
String userName = param.getValue("user_name");// RequestParam ；
String pwd = param.getValue("pwd");// RequestParam
Assert.notNull(userName, "user_name can't be null!");
Assert.notNull(pwd, "Pwd can't be null!");
TUser user = UserBusiness.queryUserByUserName(userName);// mysql ；
if (user == null) {
return respError("user not exist!");
}
if (!user.getPassword().equalsIgnoreCase(pwd)) {
return respError("password wrong!");
}// ；
JsonObject jsonObject = respRightOboxs(user.getUserId());// ；
jsonObject.addProperty(ACCESS_TOKEN, AccessTokenTool.create(user.getUserId()));// SessionID（ AccessTokenTool.create() ）；
return jsonObject;
}
次に、AccessTokenTool.create()関数の実装を見てみましょう.
public static String create(int userId) {
String uuid = RandomUtils.genUUID();
RedisCache.getJedisCache().setex(uuid, defalut_time, String.valueOf(userId));
return uuid;
}
この関数は主に次の関数を呼び出してredisに情報を格納します.
public boolean setex(String key, int seconds, String value) {
boolean result = false;
ShardedJedis sJedis = null;
try {
sJedis = borrowResource();
String status = sJedis.setex(key, seconds, value);
if ("OK".equalsIgnoreCase(status)) {
result = true;
}
returnResource(sJedis);
} catch (Exception e) {
returnBrokenResource(sJedis);
LogService.error("JedisCache.setex falid", e);
}
return result;
}
我々はpublic boolean setex(String key,int seconds,String value)関数に注目し,ランダム関数RandomUtils.genUUID()から生成されたUUIDがKey値として取り込まれ,カスタムdefalut_time有効時間およびユーザID useridはvalueとしてredisサーバに格納される.setex関数はjedis(java操作redisサーバのサードパーティライブラリ)をカプセル化する関数です.これにより、現在ログインしているユーザの情報は、redisサーバであるUUID/useridにキー値ペアとして保存される.そのうちACCESS_TOKENとUUIDもキー値ペアでJSONオブジェクトに保存され、jsonObjectを介してクライアントに送信されて保存される.クライアントが接続を切断していない場合、要求パケットを2回目に送信すると自動的にACCESS_TOKENはパケットにカプセル化され、サーバに対応するselvetによってACCESS_を解析する.TOKENのUUIDは、UUIDをキー値としてredisデータベースから対応するvalue、すなわちSessionを取り出し、そのユーザであるか否かを比較する.redisからSessionの関数をとる
public byte[] get(byte[] key) {
byte[] result = null;
ShardedJedis sJedis = null;
try {
sJedis = borrowResource();
result = sJedis.get(key);
returnResource(sJedis);
} catch (Exception e) {
returnBrokenResource(sJedis);
LogService.error("JedisCache.get falid", e);
}
return result;
}