Twitter的跨数据中心图片存储系统Blobstore
Posted onTwitter的跨数据中心图片存储系统Blobstore
Twitter**的跨数据中心图片存储系统Blobstore**
发表于**3小时前| 962次阅读|来源CSDN编译|6**条评论|作者王鹏**
摘要：Google、Facebook以及Twitter这些网络巨头都面临着同样的问题：如何构建跨数据中心服务？现在数以百万计的用户开始使用Twitter来分享照片，这些都离不开Twitter图片存储系统Blobstore的支持，该系统不仅引入了新的特性和功能，而且不断提升了用户体验，本文主要解析了该跨数据中心的图片存储系统。
【CSDN报道】Twitter一直没有自己的图片存储系统，此前系统从2011年6月开始内置采用Photobucket的服务，另外，也支持Instagram等第三方图片应用上传到Twitter系统中。随着Twitter整体由开放转向封闭，切断第三方图片上传，同时自行提供图片系统是势所必然的。
12**月11日，Twitter工程博客发表[文章](http://engineering.twitter.com/2012/12/blobstore-twitters-in-house-photo.html)，介绍了9月份已经上线使用的图片存储系统Blobstore的底层架构。其中比较引人注目的是，Blobstore支持多数据中心同步。GigaOM的文章指出，这与[Google Spanner](http://www.csdn.net/article/2012-09-19/2810132-google-spanner-next-database-datacenter)是异曲同工的。**
CSDN**进行了编译整理，文章如下：**
Blobstore**的设计目标**
Blobstore是由Twitter开发的一个低成本和可扩展的的存储系统，可以用来存储图片以及其他的二进制对象（称为“blob”）。在开始构建Blobstore时，Twitter有三个设计目标：
· 低成本：可以大大减少花费在添加图片到Tweet中的时间和成本。
· 高性能：图片延迟保持在几十毫秒之内，同时保证每秒上千万张吞吐量的图片请求。
· 易于操作：随着Twitter基础设施的不断增长，能够扩展操作开销。
Blobstore**是如何进行工作的？**
当用户推送一张照片，我们把照片发送到一组Blobstore前端的服务器。前端服务器解析后会给该照片一个特定的写地址，接下来将其转发到具体的服务器进行实际的数据存储。我们可以把这些存储服务器称之为存储节点，它们把照片信息存储到一个磁盘上，然后通知元数据存储——图像已经存储完毕并记录所需要的信息以便进行照片检索。元数据存储库，这是一个非关系型键/值存储集群，它可以自动的进行多数据中心（multi-data-center）的同步功能，更重要的是可以跨所有的Twitter的数据中心，进而在Blobstore上提供的一致性的视图数据。
Blobstore核心是Blob Manager，它运行在前端，用于存储节点以及索引集群。Blob Manager充当系统中心“协调员”的角色，对集群进行管理。它是所有前端信息（决定应该把文件存储到哪个地方）的源。不仅如此，它还负责更新映射，在增加存储节点或者由于添加失败节点被移除时，协调数据的迁移。
还有一点比较重要，就是依靠Kestrel。这是Twitter现有的异步队列服务器，主要用来处理任务，比如说复制图像以及确保数据中心中数据的完整性。
Twitter确保一旦图像上传成功，用户就可以立即从数据中心中进行读取，而且绝对是最原始的图像。而且在如此之短的时间内，图像已经复制到Twitter所有其他的数据中心之内，并且可以从这些数据中心进行读取。此功能主要依赖于Blobstore内的多数据中心元数据存储对文件的中央索引。Twitter高度关注短时间内一个图像是否被已经被写入它最初的数据中心，他们使用路由请求，确保该Kestrel队列能够进行数据复制。
Blobstore**的组成**
如何进行数据的创建工作？**
当Blobstore收到一个图像请求时，我们需要先确定其位置再进行访问数据。虽然有一些方法可以解决这个问题，但是每一种都有自己的优点和缺点。其中有一个途径就是通过映射或者Hash每个图像，通过一些特有的方法分配到一个给定的服务器之上，不过这种方法有一个相当大的缺点，就是在管理图像的流动时要复杂得多。例如，要从Blobstore中添加或删除一个服务器，那么就需要为受到变更影响的每个独立的图像再计算一个新的位置。很显然，这大大增加了运营的复杂性，因为数据的移动会产生大量的记录。
另一个方法，我们可以为个人的数据块创建了一个固定大小的容器称之为“virtual bucket”，第一步我们先把这些图像映射到该容器之上，然后我们再把容器映射到独立的存储节点上，这样我们就保持virtual bucket的总数量不变（对整个集群的寿命来说这是很好的方法）。那么为了确定一张给定的图像应该存储在哪个virtual bucket之上，我们就需要对图像的唯一ID执行一个简单的Hash标记。只要virtual bucket的数量保持不变，这个Hashing也将保持稳定。这种方式稳定的原因在于：我们把对数据的移动放在一个更粗粒度的级别上，而不再是针对于单个图像。
如何安置数据？**
当我们把virtual bucket映射到物理存储节点上时，我们的头脑应该保持清醒，必须保留一些规则以确保当我们丢失服务器或硬盘设备时，不能同时把数据丢失。如果我们把所有给定的图像副本都放在单一机架的服务器之上，一旦服务器出了问题，那就意味着图像将不可能再次使用。
如果我们把数据从一个给定的存储节点完全镜像到另一个存储节点之上，我们不太可能会出现不可用的数据，因为同时失去两个节点的可能性极低。然而，每当我们失去一个节点，我们会从另一个节点重新复制数据到源节点。当然我们必须缓慢的进行恢复，以便不影响单一剩余节点的性能。
如果我们采取相反的方法，让集群中的任何服务器都共享所有服务器中的数据，当我们恢复失去的副本时，从本质上说，为了恢复数据我们就需要读取整个集群。然而，我们也会有一个非常高的数据丢失的可能性（因为任何两个节点分享一个块数据块，丢失几率会很高）。所以，最优方法是两种办法的折中：对于一个给定的数据片段，会有限定数量的机器分享的数据的副本——肯定是超过一个，但是绝对用不到整个集群。
当我们确定映射数据到存储节点上时，我们把所有的这些因素都纳入考虑之中。那么产生的结果就是：我们构建了一个库，它被称为“libcrunch”，它非常了解各种数据的存储规则，比如说rack-awareness；它了解复制数据的方式，以便最大限度地减少数据丢失的风险，同时最大化数据恢复时的吞吐量；并且在集群中的任何拓扑(如添加节点或删除节点)改变时，试图最小化数据迁移的数量。最重要的一点，它让我们能够映射整个数据中心的网络拓扑结构，所以存储节点已经有更好的数据位置，我们只需要考虑rack-awareness以及通过PDU zones和路由器来确定副本的存储位置。
图：Blobstore 数据存储方式
拓扑管理**
随着磁盘和节点数量的不断增加，存储失败的机率也在不断升高。存储能力需要增强，磁盘和节点在出问题以后需要被立即取代，服务器也需要移动。为了使Blobstore更易于操作，我们投入了大量的时间和精力到libcrunch之上，还且随着集群的改变也开发了相关的工具。
当一个存储节点失败之后，驻留在这个节点上的数据需要从现存的节点拷贝到正确的复制因子之上。失败的节点被标记为不可用的集群拓扑，因此libcrunch需要计算从virtual buckets映射到存储节点的改变。随着该映射的变更，就会指示存储节点复制和迁移virtual buckets到一个新的位置。
Zookeeper**
拓扑和放置规则存储在Zookeeper集群中。Blob Manager处理这种交互，当一个操作符对系统进行变更时，它就会调用存储在Zookeeper中的这个信息。拓扑的改变包括复制因子的调整、添加或删除节点失败以及调整其他的libcrunch输入参数等等。
跨数据中心复制**
Kestrel主要用于跨数据中心复制，这是因为kestrel是一个持久性的队列，可以用它来实现跨数据中心图像数据的异步复制。
确认数据中心路由（Data center-aware Routing）**
TFE(Twitter的前端)是一个Twitter的核心组件。我们为TFE编写了一个定制的插件，这样就扩展了默认的路由规则。我们的元数据存储跨越多个数据中心，因为元数据存储（每blob）都很小(仅有几个字节)，我们复制这个信息通常比blob数据要快得多。如果一个用户试图访问一个blob，但是数据还没有复制到最近的数据中心中，那么我们就会查找这个元数据信息以及请求代理到最近的存储blob数据的数据中心。但是如果复制被延迟，我们仍然可以发送路由请求到最初存储blob的数据中心，这样它就能把数据复制到最近的数据中心，即使读取用户图像的成本有一点的延迟，但是“无伤大雅”。
未来的工作**
我们已经发布了第一个Blobstore的内部版本，尽管Blobstore开始仅仅只能处理一些图片相关的信息，但是我们正在往其中添加其他的功能和需要blob storage的用例。而且我们也不断对其进行迭代，让它更健壮、更具扩展性而且更易于进行维护。（编译/@CSDN王鹏，审校/包研）
