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