我们需要对我们的 API 请求执行速率限制。我们有很多网络服务器，速率限制应该在所有服务器之间共享。此外，速率限制需要一定数量的临时存储(我们希望将用户配额存储一段时间)。
我们有一个很好的速率限制实现，通过使用 SETEX 与 Redis 一起工作。在这个用例中，我们需要将 Redis 也用作存储(根据 SETEX 调用中设置的过期时间)。此外，缓存需要在所有服务器之间共享，并且我们无法在每个 Web 服务器上使用内存缓存之类的东西来处理速率限制，因为速率限制是针对每个用户的 - 所以我们希望有为此目的消耗了大量内存。所以这个过程是 Redis 集群的一个很好的用例。
问题是 - 执行速率限制的同一个 Web 服务器也有一些其他的缓存需求。它从 DB 中获取一些东西，然后将结果缓存在两层中:第一层缓存在内存中的 LRU-cache(在实际服务器上)，第二层层又是 Redis——这次用作仅缓存(无存储)。如果项目从内存中的 LRU-cache 中被逐出，它会被传递以保存在 Redis 中(这样即使内存中发生缓存未命中，仍然会有一个缓存-命中，因为感谢 Redis)。
我们是否应该使用相同的 Redis 实例来满足这两种需求(一方面需要存储的速率限制器，另一方面不需要缓存层)？我想我们可以使用包含存储(不是仅缓存选项)的单个 Redis 实例，并且只将其用于两种需求？如果我们的每台服务器都与两个 Redis 实例通信(一个仅用作缓存，另一个还具有存储选项)，从性能方面来说会更好吗？
最佳答案
我总是建议将您的设置划分为不同的数据角色。将它们结合起来听起来很巧妙，但在实践中可能会很痛苦。在您的情况下，您有两个不同的“数据角色”:缓存数据和存储数据。这是两个主要的区别类别，这意味着使用两个不同的实例。
在您的特定情况下，当出现问题或需要升级时，从操作的角度来看，隔离它们会更容易。您将避免混合服务，以免缓存中的问题导致您的“存储”层出现问题 - 反之亦然。
Redis 的使用趋向于扩展到更多领域。如果您现在养成专用 Redis 端点的习惯，您将能够在未来更好地增加您的使用，而不是在事情变得有点困难时不得不重构和重组它。
关于caching - Redis:使用两个实例还是只使用一个实例(缓存和存储)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33581155/