> For the complete documentation index, see [llms.txt](https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/lecture-11-cache-consistency-frangipani/11.8-frangipani-zong-jie.md).

# 11.8 Frangipani总结

前面我介绍了这些主要的内容：

* Petal是什么
* 缓存一致性
* 分布式事务
* 分布式故障恢复

论文还讨论了一下性能，但是过了20年之后的今天，很难理解这些性能数据。因为作者在一个与今天非常不同的硬件，非常不同的环境测试的性能。笼统来说，作者展示的性能数据表明，随着越来越多的Frangipani工作站加入到系统中，系统并没有明显变慢。即使新加入的工作站在频繁的执行文件系统操作，并不会影响现有的工作站。这样的话，系统可以提供合理的扩展性，因为它可以在不减慢现有工作站的前提下增加更多的工作站。

回过头来看，尽管Frangipani有大量有意思且值得记住的技术，但是它对于存储系统的演进并没有什么影响。部分原因是，Frangipani的目标环境是一个小的工作组，人们坐在桌子上的工作站前共享文件。这样的环境现在还存在与某些地方，但是却不是分布式存储的主要应用场景。真正的应用场景是一些大型的数据中心、大型网站、大数据运算，在这些场景中，文件系统的接口相比数据库接口来说，就不是那么有用了。比如，在大型网站的环境中，人们非常喜欢事务，但是人们在非常小的数据下才需要事务，这些小的数据也就是你会存储在数据库中的数据，而不是你会存储在文件系统中的数据。所以这里的一些技术，你可以在一些现代的系统中看到类似的设计，但是通常出现在数据库中。

另一个大的场景是为大数据运算存储大的文件，例如MapReduce。实际上GFS某种程度上看起来就像是一个文件系统，但是实际上是为了MapReduce设计的存储系统。但是不论对于GFS也好，还是大数据运算也好，Frangipani关注在工作站的本地缓存和缓存一致性，反而不是很有用。如果你读取10TB的数据，缓存基本上没什么用，并且会适得其反。所以，随着时间的推移，Frangipani在一些场合还是有用的，但是并不符合在设计新系统时候的需求。