我目前正在决定是管理自己的Varnish服务器还是使用Fastly这样的托管服务。这里最重要的决策因素之一是基于标签的高效缓存无效，因为我计划将Varnish放在我们的API前面，我们需要经常发出清除请求，使许多相关页面无效。
Fastly提供了代理密钥，而Varnish似乎提供了一个单独的模块，该模块有许多名称，包括Hashtwo、Hashninja和XKey。这些功能似乎是相同的。它们实际上是一样的吗？或者这两个功能之间是否存在一些关键的技术或效率差异，而这些差异在关于它们的博客文章中并不清楚？
代理密钥是Fastly对该功能的实现。我编写了我们当前的实现，但没有使用HashTwo/Hashninja/xkey，所以我不是实现之间差异的权威。Xkey作为vmod在https://github.com/varnish/libvmod-xkey.
代理密钥是Fastly服务的标准组成部分，但作为CDN，我们将其作为托管平台的一部分提供。它不是开源的，原因大多不充分；有一些关于这样做的讨论，但这不是一个很大的优先事项（部分原因是我们的Varnish是2.1.4的分支）。
单个密钥不允许超过1kb（因为为什么？），整个密钥列表不允许超过16kb。大约一年前，根据客户的要求，我们将上限提高到了这些值（以前总共为1kb）。密钥的数量没有限制，只要它们适合该空间（尽管我意识到这确实有效地绑定了密钥空间）。限制长度的基本原理是，关键清除会导致一定数量的线性时间操作，我们更喜欢保持有限制。如果我们目前的限制存在任何实际问题，我会感到惊讶。
我要注意的是，xkey在键的长度和数量上也受到限制，因为键也是通过头指定的，并且头的长度实际上受到为连接提供服务的线程的可用工作空间的限制。如果你运行自己的Varnish，这个长度是可调的，这对你来说可能不是一个实际的限制，但它确实存在。
我在扫描代码时注意到的另一个小区别是，xkey-vmod支持多个xkey标头，而Fastly Surrogate密钥取自第一个匹配的标头。在用于实现功能的数据结构方面存在一些差异（部分原因是我们运行了多租户Varnish），但在其他方面，功能似乎是相似的。
最后，我们（此时此刻）在全球拥有数百个Varnish装置集群。我们的部分基础设施必须通过我们的网络可靠地分发清除，并确保它们在全球范围内应用。如果您运行一个Varnish节点集群，您可能需要做一些额外的工作来使多个节点之间的缓存无效（尽管这对于小型集群来说不太可能是一个重大问题）。
xkey和hashtwo（一些营销材料中的hashninja）是相同的。
我认为Fastly产品的主要区别在于xkey没有对每个对象/URL的密钥长度或数量添加任何限制。据我所知，两者都做得很好。（完全披露：我在Varnish软件公司工作）