mysql - 现代 Web 应用程序如何对大量快速变化的数据实现缓存和数据持久化？

Question

例如，考虑像 Facebook 或 Twitter 这样的网站。所有用户推文/帖子都将无限期保留(因此它们最终必须存储在静态数据库中)。同时，它们可以快速变化(例如回复、点赞等)，因此需要某种缓存层(例如，您显然不能在每次用户“喜欢”帖子时都直接写入数据库) .

在这种情况下，数据库/缓存层是如何设计和实现的？它们是如何联系在一起的？

例如，是否通常先实现整个数据库，然后再添加缓存层？

反过来呢？换句话说，首先将大部分功能实现到缓存层，然后编写另一层定期将缓存刷新到数据库(在其事件停止时的某个时刻)？在这种情况下，对于当前/快速变化的数据，整个应用程序基本上都存储在缓存中。

或者可能实现某种基于访问/更新频率的缓存排序算法？

当用户访问频率较低的数据(当前不在缓存中)时，应该如何处理？完全绕过缓存/直接查询数据库，还是应该在将所有数据发送给用户之前缓存所有数据？

在这种情况下，设计数据库模式时考虑缓存层是否有意义，还是应该独立设计？

我不一定要直接回答所有这些问题，但它们只是让我了解我的出发点。

我找到了很多关于实现数据库和实现彼此独立的缓存层的信息/书籍，但没有找到很多关于将它们结合使用/将它们捆绑在一起的信息。

任何信息、建议、一般模式、文章、书籍，将不胜感激。只是很难在这里找到一些方向。

谢谢

Answer 1

可能不是最好的解决方案，但我在使用 Openresty 的个人项目中使用了他们的 shared memory zones缓存，避免连接到 Redis 之类的东西的开销，然后使用 Redis 作为后端数据库。

当用户加载资源时，它会检查共享字典，如果未找到则从 Redis 加载资源并在返回途中将其写入缓存。

如果资源被创建或更新，它会被写入缓存，并且还会排队到共享字典队列中。

后台工作人员等待队列中的新项目，将它们写入 Redis，然后将事件发送到其他服务器，以使缓存中的资源无效(如果有的话)，或者甚至在需要时预先缓存它。