如果这是一个非常愚蠢的问题，请原谅我。我一直在谷歌搜索过去的一小时，似乎无法在任何地方找到答案。
我们的应用程序需要每小时左右查询一次CMS数据库，以更新其所有非用户特定的CMS内容。我想将这些数据存储在一个地方，让所有工作人员都可以访问它 - 每个工作人员都必须每小时调用一次API。此外，我希望此缓存在节点工作程序崩溃时持续存在。由于我们对节点很新，我预测我们可能会有其中的一些。
我将处理所有缓存过期逻辑。我只想要一个可以在用户之间共享的存储，可以处理工作程序崩溃和重新启动，并且处于应用程序级别 - 而不是用户级别。所以用户会话对此没有好处。
Redis甚至是我正在寻找的东西吗？遗憾的是，无论如何，在我们的网络层安装mongo可能为时已晚。发布/订阅看起来很有前途，但看起来它似乎是为消息传递而不是共享缓存。也许我读错了。
非常感谢堆栈溢出！我保证在我注册后成为一名好公民。
答案 0 :(得分：1)
Redis是解决您问题的绝佳解决方案。不知道你为什么考虑pub / sub。听起来不像工作人员需要在更新缓存时得到通知，他们只需要能够读取写入缓存的最新值。您可以使用redis中的简单字符串值存储在一致的密钥下。
总之，您将拥有一个每小时更新一次redis密钥（例如cms-cache-stuff）的流程。每当需要缓存信息时，需要该数据的每个工作人员都只需从redis获取cms-cache-stuff。
此解决方案将在缓存刷新过程崩溃或工作程序崩溃时继续存在，因为redis中的密钥将始终包含数据（尽管如果刷新过程未重新启动，该数据将过时）。
如果出于某些原因，你不希望工作人员不断地从redis中读取（为什么不呢？它足够快）你仍然可以在cms-cache-stuff中存储最新的缓存数据然后通过pub发布消息/ sub给你的工作人员让他们知道缓存已更新，这样他们就可以再次阅读cms-cache-stuff。这为您提供了持久性和恢复性，因为崩溃的工作人员可以在启动时再次阅读cms-cache-stuff，然后开始在发布/订阅频道上进行监听以获取其他更新。
单独的Pub / sub对于缓存是没有用的，因为它没有提供持久性。如果工作人员崩溃而没有收听频道，则会丢弃这些消息。
答案 1 :(得分：0)
因为我怀疑我的问题是一个超级基本的noob错误，甚至很难解释得很好得到“duh”答案。我使用的是the connect-redis package，它实际上是为会话设计的，而不是缓存。一旦有人指出node_redis client，我就可以轻松地设置并做我想做的事。
非常感谢 - 希望将来能帮助一些redis noob！