あなたが私をフォローしていること、そして私があなたをフォローしていることを知るために Weibo をフォローする根拠は何ですか?データベースを設計する方法-PHPチュートリアル-php.cn

Weibo をフォローすると、あなたが私をフォローしていること、そして私があなたをフォローしていることを知るための根拠は何ですか?データベースをどのように設計するか?
タイトルの通り、Weiboを作りたいのですが、操作方法やPHPでの書き方が不安です。。

------解決策---------
テーブル構造はおそらく二重リンクリストのようなものです
------解決策---------
2 つのフィールドを持つテーブルを作成します:
フォロワーID
フォローしている人の ID
------解決策-----
Weibo はとても人気があると思います。そろそろスマホの発展に追いつくべきですよ笑
-----解決策---------
mysql については話しません。これらはすべてホットなデータです。実際にある程度の規模の Weibo であれば、mysql をチェックすると死んでしまいます。

Redis を使用する場合は、n 個のリストまたはセット、またはハッシュテーブル + リストを使用します。名前はプリフィックス + フォロワーの ID で、コンテンツはフォロワーの ID のリストまたはコレクションです。類似:

所有者:1 = {3,1,5,8,12,64...}
所有者:2 = {32,56,22,11,4...}
...

実際、設計の最も難しい点は、フォロワーが Weibo を送信し、彼のファン全員がこのメッセージを受信する必要があることです。これをどのように実装するかを考えたことがありますか?
特に何百万人ものファンがいるスター。解決策は 2 つあります:

1 データはフォロワーによって積極的にプッシュされます
2. フォロワーがファンに通知をプッシュし、ファンがデータをプルします

しかし、これは、彼がメッセージを送信するとき、何千万人もの人々がこのメッセージテーブルにアクセスする必要があること、または彼がメッセージを送信するとき、何千万人のファンのメッセージテーブルにデータを書き込む必要があることを意味します。

redis のデータ構造は単純すぎるため、それを使用してテーブルを完全に構築することもできますが、実際には mongo を使用するのが適しています。

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

引用:

実際、設計の最も難しい点は、フォロワーが Weibo を送信し、彼のファン全員がこのメッセージを受信する必要があることです。これをどのように実装するかを考えたことがありますか?
特に何百万人ものファンがいるスター。解決策は 2 つあります:

1 データはフォロワーによって積極的にプッシュされます
2. フォロワーがファンに通知をプッシュし、ファンがデータをプルします

しかし、これは、彼がメッセージを送信するとき、何千万人もの人々がこのメッセージテーブルにアクセスする必要があること、または彼がメッセージを送信するとき、何千万人のファンのメッセージテーブルにデータを書き込む必要があることを意味します。

redis のデータ構造は単純すぎるため、それを使用してテーブルを完全に構築することもできますが、実際には mongo を使用するのが適しています。

私はこれを理解することができなかったので、崇拝することしかできません
-----解決策---------

引用:

引用: 実際、設計の最も難しい点は、フォロワーが Weibo を送信し、彼のファン全員がこのメッセージを受信する必要があることです。これをどのように実装するかを考えたことがありますか?
特に何百万人ものファンがいるスター。解決策は 2 つあります:

1 データはフォロワーによって積極的にプッシュされます
2 フォロワーのメッセージテーブルからデータを取得します

しかし、これは、メッセージを送信したり、メッセージを送信したりするには、何千万人ものユーザーがこのメッセージリストにアクセスする必要があることを意味します...

実際、私も新浪微博で建築家からのこの記事を読みました。彼は、彼のアイデアに基づいて収納構造を設計する方法についての私の考えに基づいて述べただけなので、完全に正しいわけではないかもしれません。

最初の解決策は、全員が独自のメッセージテーブルを持つことです。フォロワーがメッセージを送信すると、そのメッセージにはフォロワー ID、メッセージの内容、送信時間が含まれる場合があります。ここでの最大の問題は、数千万のテーブルにデータを書き込むことです。

2 番目のオプションでは、全員のメッセージは各自のメッセージテーブルにのみ保存され、メッセージの送信後に書き込まれます。その後、すべてのフォロワーがこのテーブルから定期的にデータを取得します。または、メッセージを送信するときに、すべてのフォロワーに通知を送信します (たとえば、1 を送信すると、フォロワーはデータを取得するためにメッセージテーブルに来ます)。この方法では、多数のファンがいる場合、このテーブルの同時読み取り操作が非常に多くなります。

簡単に言えば、どちらのオプションにも長所と短所があります。しかし、最適化の余地はまだたくさんあります。新浪微博は両方のソリューションを使用しました。そして、その過程で経験も積みました。

最初のソリューションでは、ユーザーをアクティビティレベルに応じていくつかのレベルに分割し、プッシュの順序をユーザーのアクティビティレベルに応じて決定するバッチプッシュ戦略を採用しています。バッチでプッシュすると、負担がある程度軽減されます。

2 番目のソリューションでは、冗長な複数のデータロードバランシング方法を使用して、そのテーブルの同時読み取り操作のバランスをとります。たとえば、メッセージテーブルがありますが、このメッセージテーブルには n 個のコピーが n 個のサーバーに保存されており、内容はまったく同じです。メッセージを送信するときは、これらのサーバーのテーブルにデータを同時に書き込むか、バッチで書き込みます。その後、さまざまなファンが特定の戦略に基づいてどのサーバーから読み取るかを決定します。ここでは、ユーザーのアクティビティをパラメータとして使用することもできます。アクティビティの高いファンはサーバー a にアクセスして読み取ります (バッチで書き込む場合、サーバー a のメッセージテーブルが最も優先されます)

よく検討した結果、選択肢は 2 つだけのようですが、たとえば、データを読み取るときにキャッシュレイヤーを追加すると、各ユーザーが発行した最新のメッセージのみが保存されます。データは定期的にアーカイブされます。
------解決策----------------------
本当に難しいのはサーバーのアーキテクチャだと思います設計、実装ではありません。どんなに優れた手法であっても、サーバーのアーキテクチャを調整し、負荷のバランスをとることによってのみ、データ量の増加に対処することはできません。
-----解決策---------
人に分かるようなことは言えませんか？ ?

引用:

引用:引用: 実際、設計の最も難しい点は、フォロワーが Weibo を送信し、彼のファン全員がこのメッセージを受信する必要があることです。これをどのように実装するかを考えたことがありますか?
特に何百万人ものファンがいるスター。解決策は 2 つあります:

1 データはフォロワーによって積極的にプッシュされます
2 フォロワーのメッセージテーブルからデータを取得します

しかし、これは、彼がメッセージを送信すると、何千万人もの人々がアクセスする必要があることを意味します...

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

引用:

人にわかるようなこと言えないの？引用: 引用: 引用: 実際、設計上の最も難しい点は、フォロワーが Weibo を送信し、彼のファン全員がこのメッセージを受信する必要があることです。これをどのように実装するかを考えたことがありますか?
特に何百万人ものファンがいるスター。解決策は 2 つあります:

1 データはフォロワーによって積極的にプッシュされます
2 それはフォロワー次第です...

話が逸れました