varnish - Varnish Hashtwo/Xkey和FaSTLy的 "Surrogate Keys"是否相同？

Question

我目前正在决定是管理自己的Varnish服务器还是使用FaSTLy之类的托管服务。此处最重要的决策因素之一是有效的基于标记的缓存无效化，因为我计划将Varnish置于API的前面，并且我们将需要经常发出使多个相关页面无效的清除请求。

快速提供Surrogate Keys，而Varnish似乎提供了带有许多名称的separate module，包括Hashtwo，Hashninja和XKey。这些功能似乎是相同的。它们实际上是否相同，或者这两个功能之间在博客上关于它们的不清楚的关键技术或效率差异？

Answer 1

代理键是FaSTLy对该功能的实现。我编写了当前的实现，但是没有使用HashTwo/Hashninja/xkey，所以我不是实现之间区别的权威。 Xkey在https://github.com/varnish/libvmod-xkey上作为vmod公开可用。

代理 key 是FaSTLy服务的标准部分，但作为CDN，我们将其作为托管平台的一部分提供。它不是开源的，这主要是没有充分的理由的。对此进行了一些讨论，但这并不是一个重要的优先事项(部分是因为我们的Varnish是来自2.1.4的fork)。

单个 key 不允许超过1kb(因为为什么？)，并且整个 key 列表不允许超过16kb。大约一年前，我们根据客户要求提高了这些值的限制(以前是1kb)。 key 的数量没有限制，只要它们适合该空间即可(尽管我意识到这确实有效地限制了 key 空间)。限制长度的基本原理是按键清除会导致一定数量的线性时间操作，而我们希望保持一定的时间。如果我们当前的限制有任何实际问题，我会感到惊讶。

我要指出的是，xkey的长度和键数也受到限制，因为键也是通过 header 指定的，并且 header 的长度实际上是由为连接服务的线程可用的工作空间限制的。如果您运行自己的Varnish，则此长度是可调的，这对您而言可能不是实际的限制，但确实存在。

我注意到扫描代码的另一个次要区别是xkey vmod支持多个xkey header ，而FaSTLy Surrogate Keys是从第一个匹配的 header 中获取的。在用于实现功能的数据结构方面存在一些差异(部分是由于我们运行 Multi-Tenancy Varnish的事实)，但其他方面的功能看起来很相似。

最后，我们(此时)在全局范围内拥有数百个Varnish安装的集群。我们的基础架构的一部分必须与通过我们的网络可靠地分发清除并确保在全局范围内应用清除有关。如果运行Varnish节点集群，则可能必须做一些额外的工作才能使多个节点之间的缓存无效(尽管对于小型集群而言，这不太可能是一个重大问题)。