0

我正在尝试建立一个类似推特的关注机制。用户采取行动。我们列出所有用户的关注者，然后用一些信息填充他们的所有流。由于这可能需要一些时间（如果您有 10,000 个关注者，即 10,000 个流要插入信息，即可能有 10,000 个 SQL 调用），我想确保这是在后台完成的，而采取行动的用户可以去继续他的生活。

所以，我正在考虑的策略是这样的：

  • 用户采取行动。
  • php 脚本打开另一个 php 脚本，它将完成所有工作，这可能需要一两秒钟。
  • 同时，采取行动的用户可以继续他们的生活，他们的脚本只是继续，而且速度很快。

想法？我也尝试过使用队列，比如 SQS，但这种方法听起来也可以吗？另外，它的优势（对我来说）是更容易在本地测试并且更容易在非 ec2 主机上运行。

如果这是一个好方法，我将如何从 php 脚本中打开 php 脚本？是否可以像（如果 php 脚本位于 url）那样简单地获取该脚本所在的 url？

4

2 回答 2

3

描述这种方式听起来像是您想为关注该用户的每个人复制/复制第一个用户的帖子？这将是一场数据存储的噩梦。

你应该从另一个角度来看待它。考虑以下模型：

用户 A 发布了他早餐吃的东西。这与他的用户 ID 一起存储在一个表中。

用户 B 看着他的“流”。这是一个动态创建的帖子列表。此时用户 B 正在关注 50 个人。用户 B 的脚本将获取他关注的任何人的前 50 个最新帖子，并在他的“信息流”上为他显示这些帖子

使用此模型，每次无聊的早餐更新您永远不会有超过一个用户的帖子。此外，关注者的数量不会增加发布推文所需的处理时间。我的意思是推特。

澄清

你只需要做一些标准化。因此，您将拥有一个 users 表、一个 users_following 表和一个 posts 表。该查询类似于：

SELECT posts.* FROM users_following
         LEFT JOIN posts ON posts.user_id = users_following.followed
         WHERE users_following.follower = $idOfUserB
         ORDER BY posts.created LIMIT 50;
于 2010-09-21T13:55:45.737 回答
0

如果您希望您的网站完全扩展。

  • 首先，您需要使用消息队列，例如redis /beanstalkd/gearmand。
  • 其次，您需要使用例如 redis/memcached在内存中进行操作。确保您有足够的内存将活动数据集保存在内存中。

（如果您有 10,000 个关注者，则有 10,000 个流可以插入信息，即可能有 10,000 个 SQL 调用）

10,000 个 SQL 调用覆盖了失败的鲸鱼。对于这样的应用程序，我不会使用 MySQL（或者至少将它与 memcached 一起使用），而是使用 redis。将活动数据集保存在内存中。保持数据模型尽可能简单。

如果这是一个好方法，我将如何从 php 脚本中打开 php 脚本？

不要那样做。通过 lpush将消息添加到 redis 的阻止列表，并通过 blpop(daemon process) 读取它们。我将首先填充在线用户列表，然后填充离线用户列表。离线用户不介意延迟，因为他们不在线。您可以在关注该人的所有用户列表中引用密钥，并通过 mget 获取所有密钥。

是否可以像（如果 php 脚本位于 url）那样简单地获取该脚本所在的 url？

再次不要调用 url，而是使用消息队列。调用 url 会给你带来不必要的开销。

惊人的。回到 SQL :) 即使您关注 500 人，这也会很快吗？——</p>

SQL 会给你在高负载下失败的鲸鱼大量时间。至少你需要memcached！但我会改用redis。

于 2010-09-22T00:31:46.280 回答