LinkedIn开源其分布式对象存储系统总汇.docxVIP

LinkedIn 开源其分布式对象存储系统?Ambry2016-06-04?Subramanian?InfoQ“LinkedIn在Github上基于Apache 2许可证协议开源了其分布式对象存储系统Ambry。Ambry是一个是不可变对象的存储系统，非常易于扩展，它能够存储KB到GB大小的不可变对象，并且能够实现高吞吐和低延迟，该系统支持跨数据中心的双活部署，并且存储成本低廉。它特别适于存储各种媒体内容。据Linkedin的前工程主管Sriram Subramanian介绍，媒体内容在Web中已经无处不在，Linkedin中的每项新特性基本上都会与某种类型的媒体内容进行交互。这些媒体内容会存储在后端，并且主要会由内容分发网络（Content Delivery Networks，CDN）来提供服务，后台存储系统会作为CDN的原始服务器（origin server）。随着Linkedin流量的不断增长，原来所使用的媒体内容存储方案在可扩展性、可用性以及运维方面所遇到的问题越来越多。两年前，他们着手解决这些问题，而Ambry正是该项工作的结果。2013年时的媒体存储是怎样的？LinkedIn之前的系统被称为媒体服务器（因为没有一个像样的名字），这个系统由两部分组成，分别是用于媒体文件存储的Filer以及存储元数据的大型Oracle数据库。这些系统的前端是一些运行在SOLARIS上的无状态机器，它们会将请求路由到对应的Filer或数据库上。Filer是通过NFS的方式mount到无状态机器上的，并使用Java的File API进行远程访问。前端会与数据中心（DC）里面的一组缓存进行交互，从而保证如果下游系统（Filer/Oracle）出现性能问题或不可用时，前端不会受其影响。随着LinkedIn对媒体内容的需求不断增加，原有的系统在面临这些需求时，遇到了如下严重的问题：频繁出现的可用性问题：每次对文件的元数据操作出现峰值时，原有的系统都会出现延迟。当访问大量的小文件时，对元数据的操作就会增多。每次文件操作都要经过多级的转换（Java、NFS以及Filer），使其很难进行调试；难以扩展：用来存储数据和元数据的底层系统都是单体的。水平扩展元数据的存储是不可能实现的，为数据存储增加硬件也需要很多的手动过程；对小对象和大对象的支持效率低下：媒体数据集中包含了数万亿的小对象（50KB-1MB）也包括数亿的大对象（1MB-1GB）。对于小对象的存储来说，元数据操作的代价是很高昂的，而对于大数据，原有的系统缺乏端到端的流支持，难以支持新产品的使用场景；平均修复时间（MTTR，Mean Time To Repair）指标很差：老系统中的大多数组成部分在很大程度上都是黑盒，这需要获得支持许可证，并且要通过电话的方式来描述和解决问题，这会影响到MTTR；成本高昂：旧的媒体存储成本很高，再继续扩展的话，成本上已经吃不消了。如果想管理媒体的扩展性，就不能延续该方案了。在这个过程中，Linkedin探索过多种替代方案，最终还是决定自行实现更匹配其需求的解决方案。Ambry是如何运行的？设计目标在了解Ambry的设计和内部运行原理之前，明确其设计目标是很有帮助的，这决定了它的实现方式。高可用性和水平可扩展：该系统要处理实时流量，会直接影响到站点的可用性，因此它必须具有很高的可用性。另外，还希望新系统能够尽可能地实现无缝的集群扩展；降低运维的负担：分布式系统一般都会难以管理，对于频繁的集群操作，能够实现自动化是非常重要的，这能避免系统成为运维的一种负担。复杂的系统通常很难实现自动化并可靠的运行，因此新系统的设计要简单、优雅并自动化；更低的MTTR：分布式系统出现故障是难以避免的，但是很重要的一点在于快速修复故障，让各个子组件启动并运行。这就需要系统的设计简单，并且不会出现单点故障；跨DC双活：Linkedin有多个数据中心，因此所有的系统都要支持双活配置，这样的话，系统能够更新不同数据中心中的同一个对象；提升小对象和大对象的效率：请求是由小对象和大对象所组成的，小对象通常是1K到100K，超出这个范围的对象会位于大对象桶中（bucket）。要同时处理好各种大小的对象，通常来讲是很困难的。大量的小对象会给元数据带来很高的负载，造成硬盘碎片，需要很多的随机IO，而大对象则需要很好的内存管理、端到端的流处理和有限的资源使用；廉价：媒体内容很快就会占据很大的存储空间，它的另外一个特点是旧数据会变成“冷”数据，并不会频繁访问。针对这种情况有很多优化技术，包括使用密集的硬件（denser hardware）、分层存储、擦除编码以及数据去重等。在设计时，Ambry希望媒体内容能够高效存储在密集型的机器上，并且能够非常容易地使用其他优化成本的方案。概览总体上来讲，Ambry由三