PHP では、同時に同じアカウントにログインできるのは 1 人だけです

php では、同時に同じアカウントにログインできるのは 1 人だけです

これは QQ に似ています。2 台のコンピュータからログインすると、1 台のコンピュータがもう 1 台を排除し、他の場所からのログイン情報を要求します。

php 同時に同じアカウントにログインできるのは 1 人だけであることを認識する方法 1

1. 実装原則

1. ユーザーがコンピューター A にログインすると、セッション情報が Redis に保存され、session_id が mysql データベースに保存されます。

2. 同じユーザーがコンピューター B にログインします。ユーザー名とパスワードを確認した後、データベースからユーザー情報を読み取り、コンピューター A にログインしているユーザーの session_id を取得し、セッションが期限切れかどうかを確認します。レディスで。

3. 有効期限が切れた場合、openfire はプロンプト情報をプッシュする必要はありません。有効期限が切れていない場合は、PHP が openfire を使用してメッセージをプッシュした後、ユーザーがコンピューター A にログインしている Redis のセッションを削除します。削除後、コンピューター B にログインしているユーザーの個人情報をセッションに追加し、コンピュータ B でセッションにログインしているユーザーの個人情報を削除し、ユーザーがコンピュータ B にログインしているセッションを削除します。ここでは、最初にプッシュを送信してからセッションをクリアする必要があります。コンピュータ A のユーザーは、xmpp によって送信されたメッセージを受信しません。

注:

Openfire は Java cms の一種であり、作成するユーザー テーブルは、Openfire に付属するユーザー テーブルとの間に何らかの接続 (携帯電話番号、電子メール アドレスなど) を確立する必要があります。情報のプッシュを促進します。

同じ session_id が同じメディアにログインしている必要があります。現時点では、データベースを更新してメッセージをプッシュする必要はありません。

以下は、インストールプロセスと注意すべき点を簡単に紹介します。

2. インストールに使用するツール

# yum install php php-fpm nginx mysql mysql-server redis php-redis php-devel php-pdo php-mysql

セッション保存方法の変更:

# vim /etc/php-fpm.d/www.conf   

;php_value[session.save_handler] = files   //注释掉旧的
;php_value[session.save_path] = /var/lib/php/session

php_value[session.save_handler] = redis  //添加以下内容
php_value[session.save_path] = "tcp://127.0.0.1:6379"

サービスの開始後、次の内容がセッションが redis に正常に保存されたことを示している場合

redis Telnet ビューセッション

openfire のダウンロード アドレス: http://www.igniterealtime.org/downloads/

# rpm -ivh ./*.rpm   //下载的是rpm安装包

openfire が起動したら、http://ip:9090 にアクセスして段階的に設定します。注意すべき点の 1 つはデータベースのエンコーディングです。

php 同時に同じアカウントにログインできるのは 1 人だけであることを認識する方法 2

まず、いくつかの違いがあります:
1. nosql でセッションをキャッシュしない
2. session_id を mysql に保存しないでください
実装ロジック:
1. たとえば、アカウント番号が admin の場合、テーブル フィールド login_count にはログイン数が記録されます。 2. ログイン後、login_count をセッションに記録します。 3. フレームワークエントリファイルまたは権限検証で、セッションのlogin_countとmysqlのlogin_countが
であるかどうかを確認します。 等しい、等しい場合は現在のユーザー、等しくない場合は終了して例外をスローします (ここで ajax であるかどうかが判断された場合は json を送信し、そうでない場合はプロンプト ページに直接ジャンプします)。 アプリケーションシナリオ:
クライアント A がログインすると、セッションの login_count は 1 になり、データベースの login_count も 1 になります。 クライアント B もアカウントにログインすると、login_count は 2 に更新され、セッションの login_count も 2 になります。同様に、クライアント A がインターンシップ ロジックのポイント 3 の検証ルールに合格しない場合、クライアント A は終了します。 ;
短所:
mysql での login_count の変更をリアルタイムで監視すると、mysql リソースが無駄になります。mysql フィールドが更新される限り、このフィールドをキャッシュすることができます。
最後に:
この実装方法はアクティブです。ログインしているクライアントは、圧縮されているかどうかを積極的に監視します。一方、最初の実装方法は受動的です。次のクライアントが自身を圧縮するのを待ちます。