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

Question

我们有许多具有缓存需求的Web服务和Web应用程序应用程序,因此我们正在努力提出缓存策略,这可以帮助所有团队,无论他们的技术选择如何.我们已经在每个服务器节点上使用本地运行的Memcached(非复制)和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）正式化您的应用程序对缓存的访问也有很多好处，因此您应该根据延迟预算来评估成本。

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