memcache を使用してチャット ルームを実装する可能性についての議論。

memcache を使用してチャット ルームを実装する可能性について説明します。
私は突然このトピックを思いつきました。もちろん、複雑にすることは不可能です。memcache を介してテキストを使用してチャット アプリケーションを実装する可能性についてのみ検討します。
まず、私たちの目の前にあるのは、このキーを維持する方法です。それを達成することは可能ですか?

-----解決策------ ---------- ---
チャットの内容や雑談情報を記録する必要があるため
、各データは単一の値ではなく「構造体」である必要があります

チャットの内容は変更できないため、キーには実際的な意味はなく、インクリメントするだけです
最大でも時間の値が必要です
------解決策----------------------
キャッシュする必要があるものはそれほど多くありませんチャットルーム。
------解決策------------------
Python チャット ルームを勉強しました... 1 回フォローしてください
------解決策----------------------
来て学んでください、私にはこの分野の経験がありませんエリア。
------解決策---------
元々チャットルームは面倒なものです。資本金はどれくらいかかりますか?

この分野の経験がない場合でも、それを達成する方法はたくさんあります。チャット データをデータベース、ローカル ファイル、または memcache に保存し、プッシュを使用してデータを表示します。ソケットでも実現できると聞きました。 テストもしていません。どちらがより効率的かはわかりません。
------解決策---------

話し合う

元々、チャット ルームは面倒なものです。資本金はどれくらいかかりますか?

この分野の経験がない場合でも、それを達成する方法はたくさんあります。チャット データをデータベース、ローカル ファイル、または memcache に保存し、プッシュを使用してデータを表示します。ソケットでも実現できると聞きました。 テストもしていません。どちらがより効率的かはわかりません。

-----解決策---------
Webは分かりませんが、実行できますfcgi 単独で行う チャットサーバーが利用可能です。
------解決策---------

話し合う

引用:
元々、チャット ルームは面倒なものです。資本金はどれくらいかかりますか?

この分野の経験がない場合でも、それを達成する方法はたくさんあります。チャット データをデータベース、ローカル ファイル、または memcache に保存し、プッシュを使用してデータを表示します。ソケットでも実現できると聞きました。 テストもしていません。どちらがより効率的かはわかりません。


長時間の接続には WebSocket を使用すると便利です。

------解決策---------

話し合う

Web についてはわかりませんが、fcgi を別のチャット サーバーとして実行することは可能です。

------解決策---------
ブラウザまたはフラッシュ自体がサーバーでない場合、オープンなポートがあれば、テクノロジーを推進することが現実になる可能性があります。

http はリクエスト/レスポンスです。 URI の場合はリクエストできます。

QQ だと思いますが、すべてのユーザーは友人のポートを持っています。
これを実現するには 2 つの方法があります。1 つは中央データベースにデータを保存する方法で、もう 1 つはユーザーが話し、それをグループにブロードキャストする方法です。


------解決策------------------
memcached の代替?
Redis では、データはメモリに置かれますが、ハードディスク上の永続的なストレージもサポートしています。通常の構成では、パフォーマンスは memcached の約 10 倍です (私自身はインターネット上のデータをテストしていませんが、 5回以上確認済みです）。

また、チャットルームの作成も可能で、同様のコードがredis公式サイトにありますが、これはtwiiterを模倣した完全にredisで作られたページです。プロジェクト名は "retwis" のようです

以前にデザインを見たことがあるのですが、通常、キーは username_time のようなハッシュ値で、次に md5 などです...
------解決策---------

話し合う

ブラウザまたはフラッシュ自体がサーバーでない限り、プッシュ テクノロジは、開いているポートがある場合にのみ実現できます。

http はリクエスト/レスポンスです。 URI の場合はリクエストできます。

QQ だと思いますが、すべてのユーザーは友人のポートを持っています。
これを実現するには 2 つの方法があります。1 つは中央データベースにデータを保存する方法で、もう 1 つはユーザーに話してもらい、それをグループにブロードキャストする方法です。

------解決策---------
キーとしてのタイムスタンプ

mem の値にはサイズ制限があります

キーは時々生成でき、内部形式は json

です。たとえば、
5 分ごとにキー
および次にこれを入れます 5 分以内のチャット記録が mem に入れられます

その後、ユーザーはログインして現在のタイムスタンプに基づいてクエリを実行します
それが可能かどうかはわかりません
------解決策------------------
そうですね、現在の経験から判断すると、単一のサーバーを使用してチャット ルームに短い接続を使用すると、より多くのアクセスを達成できるのは不適切だと思います。

Nginx + PHP-FCGI を備えた 16 コア 16G サーバーを想定すると、これほど長い接続では、信頼性の高い同時実行性はおそらく 3W に達する可能性があります。最大ユーザー数は 3W です。 (3W は私が自分でテストしたものです。私はクソ野郎です...しかし、Zhang Yan のブログも参照しました。私は中国における nginx の先駆者です。) しかし、短い接続の場合、それはリクエストとバックの最大数に依存します。 1 秒あたりの Nginx の最大リクエスト数

以下は、nginx と redis の個別のリクエスト機能テストです:
nginx、テスト コンテンツとして phpinfo.php を使用します

PHP コード

./webbench -c 10000 -t 30 "http://127.0.0.1/test.php"
Webbench - シンプル Web ベンチマーク 1.5
著作権 (c) Radim Kolar 1997-2004、GPL オープン ソース ソフトウェア。

ベンチマーク: GET http://127.0.0.1/test.php
10,000 クライアント、30 秒で実行。

速度=230470ページ/分、46263036バイト/秒。
リクエスト: 115235 件が成功、0 件が失敗しました。
<br><font color="#e78608">------解決策----------------------</font><br>これまで一度もやったことがありませんし、そう思いますとても役に立つプレッシャーです。 。 <br><br>

ディスカッション

そうですね、現在の経験から判断すると、単一サーバーで実行する場合、長い接続を使用するのは適切ではないと思います。 、短い接続を使用してチャット ルームを作成すると、より多くの訪問を達成できます。