我们有许多具有缓存需求的网络服务和网络应用程序应用程序，因此我们正在尝试提出缓存策略，以帮助所有团队，无论他们的技术选择如何。我们已经使用了在每个服务器节点上本地运行的 Memcached(未复制)和 Couchbase(多主)，应用程序使用 Memcached 协议(protocol)在本地连接到它们，但 future 我们计划使用通过 REST API 公开的集中式缓存集群，它可以被使用在数据中心的不同服务器节点上运行的所有应用程序。以下是这一思考过程背后的原因:
- 轻松维护集群，无需担心应用服务器 节点。
- 用于访问缓存的单一协议(protocol)(HTTP)而无需担心 关于底层实现。(我们可能使用 Redis 或 Couchbase 或 Aerospike 集群)
但我们不确定这种策略，因为我们担心 HTTP 的网络开销会影响性能。
有人试过这个策略吗？将缓存作为集中式服务还是本地缓存是最好的选择？
最佳答案
虽然 HTTP 和网络确实会增加延迟，但通常您需要缓存，因为实际操作需要更长的时间。所以问题是:如果将缓存访问时间增加 1-2 毫秒，是否仍会显着缩短未缓存的操作时间？如果答案是肯定的，并且您遵循一些常见的最佳实践，那么拥有一个集中式缓存可能是个好主意。
您可能想要研究 HTTP 服务的低延迟、高吞吐量服务器端框架，例如 Node.js 或 Go。此外，您可能会受益于实现适当的 ETag在您的缓存 HTTP API 中支持。
另一种选择可能是集中缓存服务器而不将它们包装在 HTTP 层中。您提到的所有技术都有标准的缓存提供程序实现，可用于大多数现代 Web 框架。
关于caching - 提供缓存即服务是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29791632/