php - 使用 Redis 的大规模策略的新闻提要

Question

我在尝试解决规模问题时遇到了一个有趣的困境。

目前我们有一个社交平台，它有一个非常典型的提要。我们正在使用图形数据库，每次用户请求提要时，我们都会访问数据库。虽然现在这很好，但随着我们用户群的扩大，它会逐渐停止。输入 Redis。

目前，我们通过帖子 ID 将评论、点赞等内容存储在 JSON 编码字符串中的各个 Redis 键中，并在有更新、添加或删除时更新它们。然后在代码中，我们循环遍历帖子的数据库结果并从 Redis 存储中提取数据。这导致多次调用 Redis 来构建每个帖子，这比每次都接触数据库要好得多。挑战在于跟上不断变化的数据，例如评论者/点赞者的头像、屏幕名称、已关闭的帐户、新的喜欢、新的评论等与每个帖子相关的数据。

我正在尝试确定一种策略来以最有效的方式处理此问题。 Redis 只会带我们走这么远，因为我们将达到每台机器大约 12 gig 的 ram。

讨论的概念之一是为每个存储新帖子 ID 的用户使用信标。因此，当用户分享新内容时，他们所有连接的 friend 的信标都会获得帖子 ID，这样当用户登录他们的提要时，就会被视为需要更新的 Dirty，然后按 ID 将提要存储在按时间戳排序的 Redis 集中。要检索提要数据，我们可以通过 ID 执行单个查询，而不是快数百倍的完整遍历。这仍然没有解决交互用户的帐户信息、他们的喜好和不断变化的评论问题，但确实部分解决了构建提要问题。

另一个想法是将用户的整个提要(JSON 编码)存储在 MYSQL 记录中，并在用户请求时即时更新它并且信标显示一个脏提要。否则，它只是一个单一的选择和 json 解码来构建提要。同样，动态组件是一团乱麻。

有没有人成功地应对了这个挑战，或者有解决这个问题的策略的工作知识。

Answer 1

Currently we store things like comments, likes and such in individual Redis keys in JSON encoded strings by post ID

使用更高效的序列化程序，如 igbinary 或 msgpack。我建议 igbinary(检查 http://kiss-web.blogspot.com/ )

Then in code we loop through the DB results of posts and pull in the data from the Redis store.

请务必使用流水线以获得最佳性能。

This is causing multiple calls to Redis to construct each post, which is far better than touching the DB each time.

不要低估数据库主键的力量。尝试对您的数据库执行相同操作(不是加入，而是按键选择):

 SELECT * FROM comments WHERE id IN (1,2,3,4,5,6):

单个 redis 调用比单个 DB 调用更快，但与主键上的一个 sql 查询相比，进行大量的 redis 调用(甚至是流水线调用)——没那么快。尤其是当您为数据库提供足够的缓冲区内存时。

你可以通过在redis中“缓存”DB数据来使用DB和Redis。你做这样的事情:

1. 每次更新数据时，都是在数据库中更新并从 Redis 中删除。
2. 获取数据时，您首先尝试从 Redis 获取它们。如果在 Redis 中找不到数据，则搜索它们的 id DB 并插入到 Redis 中以备将来使用，但有一定的过期时间。

这样你就只在 redis 中存储有用的数据。未使用的(旧)数据将仅保留在数据库中。