在尝试解决规模问题时，我遇到了一个有趣的困境。
目前我们的社交平台拥有非常典型的Feed。我们正在使用图形数据库，每次用户请求提要时，我们都会访问数据库。虽然现在这很好，但随着我们用户群的增长，它将停滞不前。输入Redis。
目前，我们会通过帖子ID将注释，喜欢等内容存储在JSON编码字符串中的各个Redis键中，并在有更新，添加或删除时更新它们。然后在代码中我们遍历帖子的DB结果并从Redis商店中提取数据。这导致多次调用Redis来构造每个帖子，这比每次触摸DB要好得多。面临的挑战是跟上评论数据的变化，例如评论者/ liker的头像，屏幕名称，关闭账户，新喜欢，与每个帖子相关的新评论等。
我正在尝试制定一种策略来处理这种最有效的方法。 Redis只会带我们到目前为止，因为我们将以每台机器约12 gig的内存达到顶峰。
讨论中的一个概念是为存储新帖子ID的每个用户使用信标。因此，当用户分享新内容时，他们所有已连接的朋友的信标都会获得帖子ID，这样当用户登录他们的Feed时，他们会看到Dirty需要更新，然后按照时间戳排序的Redis Set中按ID存储Feed。要检索Feed数据，我们可以通过ID执行单个查询，而不是完全遍历，这要快几百倍。这仍然无法解决交互用户的帐户信息，他们的喜欢和评论问题，这些问题一直在变化，但确实解决了部分构建Feed问题的问题。
另一个想法是将用户的整个提要（JSON编码）存储在MYSQL记录中，并在用户请求它并且信标显示脏提要时动态更新。否则它只是一个select和json解码来构建feed。同样，动态组件也是蜷缩在一起。
是否有人成功地应对了这一挑战，或者已经掌握了应对此问题的战略知识。
答案 0 :(得分：1)
您可能想要使用@solocommand所描述的mongodb，但您可能希望停止期望您更新＆＃34;按需数据。而是将用户的更改推送到＆＃34;写＆＃34; queue，然后根据需要更新数据库。然后，您可以从数据库（mongodb）加载并根据需要使用它，或更新其他redis记录。
迁移到消息传递系统Amazon SQS，IronMQ或RabbitMQ可以帮助您更好地扩展。您还可以使用redis队列作为基本消息总线。
答案 1 :(得分：1)
目前，我们通过帖子ID在JSON编码的字符串中存储评论，喜欢等内容，如
使用更高效的序列化程序，如igbinary或msgpack。我建议igbinary（检查http://kiss-web.blogspot.com/）
然后在代码中我们遍历帖子的DB结果并从Redis商店中提取数据。
请务必使用流水线技术以获得最佳性能。
这导致多次调用Redis构建每个帖子，这比每次触摸数据库要好得多。
不要低估数据库主键的功能。尝试使用您的数据库执行相同的操作（不是连接，而是通过键选择）：
SELECT * FROM comments WHERE id IN (1,2,3,4,5,6):
单个redis调用比单个数据库调用快，但与主键上的一个sql查询相比，执行大量redis调用（甚至是流水线调用） - 不是那么多。特别是当您为DB提供足够的缓冲区内存时。
您可以通过＆＃34;缓存＆＃34;来使用数据库和Redis。 redis中的数据库数据。你做了类似的事情：
这样你只能在redis中存储有用的数据。未使用的（旧）数据将仅保留在DB中。