php 遵循机制：使用什么策略？

Question

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

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

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

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

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

Answer 1

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

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

用户 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;

Answer 2

如果您希望您的网站能够扩展。

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

（如果您有 10,000 名关注者，那就是
10,000 个流插入信息
在，即可能有 10,000 个 SQL 调用）

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

如果这是一个好方法，那么如何
我可以从内部打开一个 php 脚本吗
PHP 脚本？

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

是否可以像（如果 php
脚本位于 url）执行 get on
该脚本所在的 url？

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

太棒了。回到 SQL :) 这将是
即使您关注 500 也很快
人们？ –

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