持久的消息¶

这条消息是关于Spersistent的，以及为什么你不应该使用它，即使它仍然存在于Varnish4.x中。从Varnish 6开始，只有在编译时显式启用它时才会出现。

TL；DR：¶

在狭隘和定义不明确的情况下，-persistent工作得很好，但通常情况下，运行它会带来更多麻烦，而我们目前没有解决这一问题的开发资源。

如果你认为你有这些情况，你需要

打电话 configure 使用 --with-persistent-storage 编译前
使用存储引擎名称 deprecated_persistent ，请使用a：：
```
-sdeprecated_persistent,<options>
```
启动Varnish时的参数

才能使用它。

当我们为Varnish添加-Spersistent时，它是为了回应一群真正想要它的特定客户，并由他们赞助。

持久化存储模块与非持久化模块是完全不同的VAX，因为它带来了所有丑陋的一致性问题。

让我给你举个例子。

设想一个由一些使用禁止的Varnish服务器组成的集群。

如果没有持久存储，如果它们中的一个关闭并重新启动，所有旧的缓存对象都会消失，根据定义，所有被禁止的对象也会消失。

使用永久存储，我们不仅必须存储仍然有效的禁令和缓存的对象，并痛苦地保持两者的同步，因此禁令将与对象一起恢复，我们还必须担心在停机期间丢失禁令，因为这些可能会禁止我们将在启动时恢复的对象。

惊喜：直接进入数据库/文件系统一致性领域。

但我们知道这一点，我想我有一个很好的策略来处理这件事。

在某种意义上，我做到了。

与数据库和文件系统相比，Varnish有一个优势，即我们实际上可以释放对象，而不会造成灾难。如果我们不这样做会更好，但我们可以简单地丢弃看起来不一致的东西，这样我们就会安全。

我们的策略是创建一个“日志结构文件系统”，这是一个曾经很有前途的概念，但很快就被证明很难很好地实现。

有趣的是，今天SSD中的ARM芯片很可能实现了LFS以实现损耗均衡，但功能集大大减少：所有的“文件”都是一个扇区长的，文件名是整数，并且没有子目录或重命名操作。另一方面，还有关于闪存阵列状态的额外簿记。

LFS由两个主要部分组成：读和写的位，这是非常微不足道的，以及提供可用空间的位，而不是。

起初我们甚至没有做第二部分，因为在Varnish对象到期，如果他们这样做足够快，空间将神奇地变得可用。这对我们的初始用户来说已经足够好了，他们只是偶尔使用禁令，所以这也很酷。

换句话说，经典的20%的努力，80%的收益。

不幸的是，我们找不到时间和金钱来完成另外80%的努力，这将带来最后20%的好处，因此，Spersistent最终陷入了困境。

今天，我们决定正式弃用-persistent，并开始警告人们不要使用它，但我们现在将它留在源代码中，以便保持持久存储所需的接口正常工作，希望我们以后可以再次使用它们。

因此，如果您真的想使用永久存储，并且您知道自己在做什么，则可以使用：

-s不推荐使用_Persistent

我已经警告过你了。

保尔-亨宁，2014-05-26