作者简介：
有的小伙伴对于放宽“持久性”不屑一顾——他们认为如果数据库丢失了更新操作的能力那还叫数据库吗？然而。。。。。
5.4. Relaxing Durability 放宽“持久性”约束
之前我们已经讨论了有关“一致性”的内容（大部分时候当人们谈论有关数据库事务的ACID属性的时候，其实就说的是一致性的内容），一致性的关键就是通过组成一个个原子（Atomic）、相互隔离的工作单元的方式把一个个请求序列化。然而，大部分人对于放宽“持久性”不屑一顾——他们认为如果数据库丢失了更新操作的能力那还叫数据库吗？
然而，事实证明，有些时候，你可以通过损失一些“持久性”来获得更好的性能。如果一个数据库大部分时候都运行在内存，更新的内容也是直接写入内存的，然后定期把数据变更写入磁盘中，这样的话，就大大的提高了请求的响应速度。但是这样做的风险就是，如果server挂了，那么在最后一次flush之前的还放在内存的那些更新将会全部丢失。
有一个例子，相信大家都知道，那就是保存user-session状态的时候，上面的这种方案就值得考虑。一个大的网站，有很多的用户，这些用户在登入以后会保存一些自己正在做的一些事情，这些信息作为临时信息使用某种会话（session state）的方式被保存起来。那么就会有很多的活动在此状态下，创建大量的请求，从而影响网站的响应速度。这里有个需要说明的就是，这些会话信息即使丢了也不是什么大不了的事情，与整个网站的响应速度相比这点小麻烦是没什么的。这就给了我们一个选择“非持久化写入”方案的机会。通常，我们可以在每次发出请求时，指定其所需的持久性。这样的话一些比较重要的更新操作我们就可以要求强制直接写入磁盘。
另外一个放宽持久性的例子就是从物理设备上抓取遥测数据（telemetric data）。在这种案例下，你会优先考虑频繁快速的抓取数据，那怕付出因为服务器挂掉而丢失最近的更新的代价。
还有一类的有关持久性的权衡问题，是由复制数据（replicated data）引发的。就是当一个节点负责处理更新操作，但是在更新操作还没有复制到其他的节点的时候就发生了故障，这个时候就出现了 复制持久（replication durability）故障。比如当我们使用主从复制的分布式模型的时候就会出现这种情况，比如当现在的master出现故障，然后一台slave节点被选为新的master，如果master确实出了故障，那些还没有传递到副本上的写入操作将会丢失。假如之前的那个出问题的master恢复好以后重新归来的时候，那么之前的更新就会和发生故障的这段时间产生的更新相冲突。我们把这种情况视为“持久化”（durability problem）问题，就是既然master已经恢复了，你以为你的更新已经成功了，然而master的那次失败却把更新给丢失了，唉！
如果你有足够的自信可以让master在出故障后迅速恢复，那么你可以考虑出故障时不用自动切换到slave。另一个方法就是，确保主节点在收到一部分副本对更新数据的确认之后，再告知用户它已接纳了这个更新。然而，很明显，这个会降低更新速度。而且一旦从节点（slave）出现了问题，那么整个集群就用不了了。所以，再说一遍，在权衡的时候，要考虑持久性的重要程度！与处理持久性的基本手段类似，我们也可以为单个请求指定它所需的持久性。
