Twitter图片存储系统blobstore

Blobstore是twitter的图片存储系统，主要参考twitter员工博客及其译文，译文基本是按照字面进行翻译，部分地方理解有些问题，比如文中提到的“每秒上千万张吞吐量的图片请求”，而英文原文是hundreds of thousands of，翻译为上千万显然是很误导读者的；本文主要谈谈我对blobstore的理解，如有问题请指出。

相比facebook的haystack、以及taobao的TFS这两个图片存储系统，Blobstore的优势在于，设计之初就考虑到支持多数据中心（或理解成多机房、多集群），我理解的blobstore的架构如下图所示。

Blob Management

Blobstore的多个集群的数据存储是独立的，各自管理自己的数据。Blob manager是集群中的主控节点，管理所有的storage nodes，负责为写请求分配Storage node，并负责将读请求路由到对应的storage node，blob manager使用类似一致性哈希的策略（可配置）分配storage node，这样能保证有节点增加或退出时，需要迁移的数据量最小。storage Node以fat file的形式管理文件，这点与haystack、tfs策略相同，主要思路是将多个小文件存储在大文件中，减少元数据。多个集群间会同步数据，一旦数据被同步到所有的集群，所有的客户端就可以实现就近访问数据，Blobstore借助消息中间件kestrel来实现数据同步。

Blob manager上的节点分配策略是可配置的，具体策略配置在全局的zookeeper集群上，blob manager从zookeeper获取策略，并应用到集群，这样能保证多个集群应用到一致的策略管理集群。

Front end

Front end是Blobstore的访问代理，是一组apache/nginx服务器，接收到请求应用（客户端）的请求时，Front end会将请求转发至最近的集群；通过增加Front end代理，blobstore内部的任何升级可以做到对应用完全透明。

Meta store

Meta store是一个跨数据中心部署的KV存储引擎，主要存储文件（或对象、blob）到集群的映射关系，比如某个文件存储到cluster1后，存储该文件的storage node就会告诉meta store，该文件已经存储到cluster1了（集群中storage node数量通常非常多，由它来异步通知meta store是非常合适的）；meta store存在的主要原因还是为了减少跨数据中心的访问，比如front end访问最近的集群没有找到文件，则它需要逐个重试所有的集群来找文件；但如果有了meta store，一旦在最近的集群找不到，可以先在meta store上查询到文件存在于哪些集群，然后直接到包含文件的最近集群去获取文件。

Data transfer

Blobstore数据迁移方面的细节文章中没有说明，如果以文件为单位来进行迁移，会造成迁移的量巨大，迁移过程会产生大量随机IO，另外在迁移完成后，会导致fat file出现大量的碎片空间，不知twitter是如何解决这些问题的。