我们需要对API的请求执行速率限制。我们有很多Web服务器，并且应该在所有这些服务器之间共享速率限制。此外，速率限制需要一定量的临时存储（我们希望在一段时间内存储用户配额）。
我们有一个很好的速率限制实现，可以使用SETEX与Redis配合使用。在这个用例中，我们还需要使用Redis存储（根据SETEX调用设置的到期时间一段时间）。此外，需要在所有服务器之间共享缓存，并且我们无法在每个Web服务器上使用类似内存缓存的内容来处理速率限制，因为速率限制是针对每个用户的 - 因此我们希望为此目的消耗了大量内存。因此，此过程是Redis群集的一个很好的用例。
事情是 - 执行速率限制的同一个Web服务器，也有一些其他缓存需求。它从DB中获取一些内容，然后将结果缓存为两层：首先，在内存中LRU-cache（在实际服务器上），第二层再次是Redis - 这次使用仅作为缓存（无存储）。如果项目从内存中LRU-cache被逐出，它将被传递以保存在Redis中（这样即使在内存中发生缓存未命中，仍然会有缓存命中，因为感谢Redis的）。
我们是否应该同时使用相同的Redis实例（一方面需要存储的速率限制器另一方面需要缓存层）？我想我们可以使用一个包含存储的Redis实例（不仅仅是缓存选项）而只是用于满足这两种需求？对于我们的每个服务器，与两个Redis实例进行对话 - 一个用作仅缓存还是一个还具有存储选项的实例 - 会不会更好，性能更好？
答案 0 :(得分：0)
我总是建议将您的设置划分为不同的数据角色。结合它们听起来很整洁，但在实践中可能是一个真正的痛苦。在您的情况下，您需要两个不同的数据角色＆＃34;缓存数据和存储数据。这是两个主要的区分类别，这意味着使用两个不同的实例。
在您的特定情况下，当出现问题或需要升级时，从操作角度来看，隔离它们会更容易。您将避免混合服务，以便缓存中的问题导致您的＆＃34;存储＆＃34;层 - 或反向。
Redis的使用往往会扩展到更多领域。如果您养成了专用Redis端点的习惯，那么现在您将能够更好地扩展您的使用，而不是在事情变得有点粗糙时不得不重构和重组。