Beaver 论文阅读笔记

Haystack 架构

图片下载流程

图片上传流程

1. Haystack Directory
2. Haystack Cache
3. Haystack Store
4. Recovery from failure

Haystack Directory

Haystack Directory 一共有四个作用

1. Directory 提供从逻辑磁盘到物理磁盘的对应关系，Web servers 用这个对应关系进行上传图片和生成网页请求的 URL。
2. Directory 帮助完成通过逻辑磁盘进行写入和通过物理磁盘读取的负载均衡。
3. Directory 决定一个图片请求是通过 CDN 还是 Cache。
4. Directory 确认这些只读的逻辑磁盘的原因，是因为操作原因还是这饿磁盘到达了他们的最大储存空间。

当我们增加了一个储存空间，只有这个新的储存空间才可以接受上传的图片，当这个储存空间满了之后，我们也把这个存储空间设定为只读。我们下一节再讨论这个操作的后果。

Haystack Cache

我们可以将 Haystack cache 看作一个分布式的哈希表，键就是图片的 id， 对应的值就是图片的位置。如果 cache 不能立刻回复 CDN 或者用户，那么 Haystack Cache 需要从 Haystack Store 去获取图片。

Cache 只有在满足两个条件的时候才会缓存图片。

1. 当请求是直接从用户来的
2. 当请求的图片存储在可写磁盘里面

设立第一个条件的原因是：在 CDN 之后设定缓存是效率很低的。因为如果 CDN 没有命中的话，内部缓存也基本不可能命中

设立第二个条件的原因是： 图片在上传完之后是最可能被访问的，并且当磁盘只进行读取或者写入的时候，销量较高。

Haystack Store

Store 可以快速获取到图片只用对应的逻辑磁盘和文件位移。这个是整个 Haystack 设计的要点。通过图片名称，位移和大小就可以获取图片，不需要磁盘操作。

Store会为每一个物理磁盘保留一个文件描述符和一个内存里的哈希表。这个哈希表的 key 是图片 id，值是元数据。这个对于获取图片很重要。

Store 将物理磁盘表现为一个包含一个 superblock 的大文件。这个 superblock 跟着一系列的needles。一个needle代表一个存在 haystack 里面的图片。下面的图片描述了很多的 fields 在每一个 needle 里面。

为了可以快速的获得 needles，每一个 Store 会为他的磁盘们维护一个在内存里面的数据结构。这个数据结构就是一个 map，key就是(key, alternate key), value 就是其他信息比如 flags, size。下面我们来讲一下在图片的读写删除操作的时候，Store 是如何维护这个 map 的。

Photo Read

当 cache 请求一个图片，它需要提供 id，key，alternate key，cookie。 cookie 是一个数字，被嵌入到URL里面。cookie 是一个被随机赋予的值，当图片被上传的时候。cookie 可以有效的避免对于猜测可用的URL攻击。

当 Store 接到了一个请求，Store 就会去查询存在内存的元数据。如果图片没有被删除，就去找适当的磁盘文件，之后读取整个的 needle。当验证完cookie和数据的完整性后，Store 就会获取这个图片返回到 Cache。

Photo Write

当上传图片到 Haystack，web server 会提供逻辑磁盘的id，key，alternate key，cookie和数据给 Store。

needle 只可以被附加到物理磁盘文件，与此同时更新内存里面的 map。这种只可以附加的操作禁止了一些复杂操作。所以 haystack 不允许覆盖 needle，为了更新图片，只能增加一个新的 needle 与相同的 key 和 alternate key。如果新的 needle 被写到了与原来就图片不一样的逻辑磁盘里面，Directory 更新他的元数据，并且在未来不会再获取到旧的数据。如果新的数据被写到同一个逻辑磁盘里面，那么 Store 就会添加一个新的 needle 到对应的物理磁盘。Haystack 会根据他们的 offset 区分这些重复的 needle。最新的版本就是 offset 最大的那个。

Photo Delete

Delete 操作比较简单，只是在内存和磁盘上将对应的图片打上删除的flag。之后在访问到该资源的时候就会返回错误。

The Index File

如果每次在重启的时候都要从磁盘中读取并建立相应的map，这样的操作是相当费时的。Store可以帮我们维持一个index file。

index file 就像一个存档点，用来帮助我们快速的定位对应的needles。一个index file的排序就像磁盘的文件有一个superblock，之后跟着很多的index，这些index对应着needles。

但是有一个问题就是Index file的更新是异步的，这导致我们重启的时候有一些index可能是旧的。比如当我们删除图片的时候，我们index file的更新如果滞后，如果这时候server down了，那么在index file这个文件可能是没有被删除的。还有如果当我们添加了一个图片的时候，磁盘上回存上图片，但是index file可能没有来得及更新。所以为了解决这个问题，我们有两个问题要解决，第一needles的存在并不依赖于index。第二index并不能反映出删除的图片。对于第一个问题，我们将没有index的文件叫做orphans。我们在index file里面的最后一个记录肯定是第一个orphans的前面一个。后面的就都是orphans。我们可以先读取index file，之后再把所有没有记录的文件读到内存里面。对于第二个问题就是当我们读取到整个的needle的时候 ，我们需要对删除flag进行判断。如果store在读取整个needel之后发现这个文件对应的是删除状态就要返回错误。