提供缓存即服务是个好主意吗？

Question

我们有许多具有缓存需求的Web服务和Web应用程序应用程序，因此我们试图提出一种缓存策略，该策略可以帮助所有团队，无论他们的技术选择如何。 我们已经使用了在每个服务器节点上本地运行的Memcached（未复制）和Couchbase（多主服务器），并且应用程序使用Memcached协议在本地连接到它们，但未来，我们计划使用通过REST API公开的集中式缓存集群，供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）来规范您的应用对缓存的访问也有很多好处，因此您应该在延迟预算的情况下评估成本。

您的策略是合理的，可用于构建可扩展和高性能的应用程序。 如果您需要进一步的建议，请随时与我联系。