例如，考虑像Facebook或Twitter这样的东西。所有用户推文/帖子都会无限期保留（因此它们最终必须存储在静态数据库中）。同时，它们可以快速更改（例如，回复，喜欢等），因此需要某种缓存层（例如，每当用户使用时，您显然无法直接写入数据库＆＃34;喜欢＆＃34;一个帖子。）
在这种情况下，数据库/缓存层是如何设计和实现的？他们是如何联系在一起的？
例如，通常是从整体实现数据库开始，然后添加缓存层后缀吗？
另一种方式呢？换句话说，首先将大部分功能实现到缓存层，然后编写另一个层，定期将缓存刷新到数据库（在其活动已经关闭的某个时刻）？在这种情况下，对于当前/快速变化的数据，整个应用程序基本上将存储在缓存中。
或者根据访问/更新频率实现某种缓存排序算法？
当用户访问频率较低的数据（当前不在缓存中）时，应该如何处理？只需完全绕过缓存/直接查询数据库，还是应该先将所有数据缓存到用户之前？
在这种情况下，设计具有缓存层的数据库模式是否有意义，还是应该独立设计？
我不一定要求直接回答所有这些问题，但他们只是想知道我来自哪里。
我发现了很多关于实现数据库的信息/书籍，并且实现了彼此独立的缓存层，但没有关于将它们结合在一起使用它们的大量信息。
任何信息，建议，一般模式，文章，书籍，将不胜感激。在这里找到一些方向很难。
由于
答案 0 :(得分：2)
可能不是最好的解决方案，但我使用Openresty进行个人项目，我使用shared memory zones缓存，以避免连接到Redis之类的开销，然后使用Redis作为后端DB。 / p>
当用户加载资源时，它会检查共享的dict，如果它没有，那么它会从Redis加载它并在回来的路上将它写入缓存。
如果创建或更新了资源，它将被写入缓存，并且也会排队到共享的dict队列。
后台工作人员在等待队列中的新项目，将它们写入Redis然后将事件发送到其他服务器以使其缓存中的资源无效（如果有的话），或者甚至在需要时预先缓存它。