提供缓存作为服务是否是个好主意？

Question

我们有许多具有缓存需求的Web服务和Web应用程序应用程序，因此我们正在努力提出缓存策略，该策略可以帮助所有团队，无论他们的技术选择如何。我们使用过Memcached（未复制）＆amp;在每个服务器节点上本地运行的Couchbase（多主机）和应用程序使用Memcached协议在本地连接它们，但是我们计划使用通过REST API公开的集中式缓存集群，这些集群可以被运行在不同服务器节点上的所有应用程序使用。数据中心。以下是思考过程背后的原因：

1. 轻松维护群集而无需担心应用服务器 节点。
2. 用于访问缓存的单一协议（HTTP），无需担心 关于底层实现。（我们可能会使用Redis或Couchbase或 Aerospike集群）

但是我们不确定这个策略，因为我们担心由于HTTP而导致网络开销对性能造成影响。

有没有人尝试过这种策略？将缓存作为集中服务或本地缓存最好是一个好主意吗？

Answer 1

虽然HTTP和网络确实增加了延迟，但通常需要缓存，因为实际操作需要的时间要长得多。所以问题是：如果你为缓存访问添加1-2毫秒，这是否仍然显着缩短了未缓存的操作时间？如果答案是肯定的，并且您遵循一些常见的最佳实践，那么使用集中式缓存可能是一个好主意。

您可能希望研究HTTP服务的低延迟，高吞吐量服务器端框架，如Node.js或Go。此外，您可能会从缓存HTTP API中实现正确的ETag支持中受益。

另一种选择可能是集中缓存服务器而不将它们包装在HTTP层中。对于大多数现代Web框架，您提到的所有技术都有标准的缓存提供程序实现。

Answer 2

免责声明：我在Redis Labs工作，这是一家商业公司，负责管理Redis和Memcached集群。我的雇主Redis Labs已经制定了您想要肯定的战略业务：）

缓存是最接近的菜，但远程缓存有好处（例如，卸载数据库），即使延迟惩罚表明不同。在大多数情况下，与在应用程序中花费的时间相比，局域网延迟变得可以忽略不计，因此使用共享的网络连接缓存非常有意义。

要获得最佳性能，请使用自己的协议从应用程序直接与共享缓存进行交互。除非由缓存引擎本身提供，否则HTTP API可能会增加客户端应用程序请求的延迟。 OTOH，使用自定义层（例如REST API）正式确定您的应用程序对缓存的访问权限也有很多好处，因此您应该在延迟预算的上下文中评估成本。

您的策略是合理的，它可以在任何地方用于构建可扩展且高性能的应用程序。如果您需要进一步的建议，请随时打我。