情况：
我目前正在为社交网站设计一个供稿系统，每个用户都有一个朋友活动的供稿。我有两种可能的方法来生成Feed，我想问一下哪种方法最适合扩展。
所有用户的事件都收集在一个中央数据库表event_log中。用户在表friends中与朋友配对。我们使用的RDBMS是MySQL。
标准方法：
当用户请求其Feed页面时，系统会通过内部加入event_log和friends来生成Feed。然后缓存结果并在5分钟后设置为超时。通过改变此超时来实现缩放。
假设方法：
任务在后台运行，对于event_log中的每个新的未处理项，它会在数据库表user_feed中创建条目，将该事件与发起事件的用户的所有朋友配对。一个表行将一个事件与一个用户配对。
标准方法的问题是众所周知的 - 如果很多人的缓存同时到期会怎么样？该解决方案也不能很好地扩展 - 简要说明供稿尽可能接近实时更新
我眼中的假设解决方案似乎好多了;所有处理都是脱机完成的，因此没有用户等待生成页面，也没有连接，因此数据库表可以跨物理机进行分片。但是，如果用户有100,000个朋友并在一个会话中创建了20个事件，则会导致将2,000,000行插入数据库。
问题：
问题归结为两点：
答案 0 :(得分：1)
我认为你的假设系统会产生太多数据;首先，在全球范围内，user_feed的存储和索引要求似乎随着用户群变得越来越大，互联性越来越大而呈指数级增长（两者都可能是社交网络所希望的）;其次要考虑的是，如果在一分钟内，每个用户都输入了一条新消息，每个消息都有100个朋友 - 那么你的后台线程就有10万个插件要做，可能会很快落后。
我想知道你的两个提议的解决方案是否可以在后台线程更新表last_user_feed_update之间进行折衷，该表包含每个用户的单行和上次更改用户提要的时间戳。
然后，虽然刷新源需要完整的连接和查询，但是对last_user_feed表的快速查询将告知是否需要刷新。这似乎可以缓解标准方法的最大问题，同时避免存储大小困难，但后台线程仍有很多工作要做。
答案 1 :(得分：0)