大规模文件存储OSS技术与实践
|
对象存储服务（Object Storage Service，简称OSS），是百分点对外提供的海量、安全、低成本、高可靠的对象存储服务。用户可以通过简单的REST接口，进行数据的上传和下载。同时，OSS提供Java语言的SDK，简化用户的编程。基于OSS，用户可以搭建出各种个人和企业数据备份、业务数据应用等基于大规模数据存储的服务。同时OSS还可以与其他组件搭配使用，广泛应用于海量数据存储与备份，数据加工与处理，内容加速分发，业务数据挖掘等多种业务场景。 1.架构设计 基于对OSS的要求，我们设计的架构如下图所示：
我们采用了HBase+Ceph来进行底层存储，对于小于1MB的数据进入HBase，对于大于1MB的数据进入Ceph，同时数据通过Tomcat提供对外服务。基于上面的架构，我们的OSS可以实现以下的性能目标。 1.1 高吞吐性OSS的底层存储充分利用各组件的性能优势，来使整个集群可以达到较高的吞吐量。 HBase（Hadoop Database），是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群。对于小于1MB的文件写入HBase是一个很棒的设计。 那么大于1MB的文件，我们存入哪里呢？有这么几种方案可供我们选择，比如Hadoop，FastDFS，Ceph等组件。我们最终选择了Ceph做大文件存储。 Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。Ceph的开发目标可以简单定义为以下三项： 1.可轻松扩展到数PB容量 2. 支持多种工作负载的高性能 3. 高可靠性 1.2 高可用性高可用性对文件存储系统是极为重要的，因为数据是极为宝贵的，如果数据在OSS中很容易丢失或者不可靠，那么它的存在意义就不大了。 对于OSS的高可用，我们早就做了深思熟虑的思考。HBase的数据最终存储HDFS中，而HDFS是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统（DistributedFile System）。我们可以通过定义它的多副本机制来达到它的高可用性。 和HBase类似，Ceph也可以通过多副本机制来实现它的高可用性。 同时，我们可以定义存储的文件的过期时间来避免存储的文件无限增长，在我们的应用中，默认设置为90天。 1.3 可扩展性当系统的吞吐量越来越大，或者存储容量以及快达到OSS所能承受的流量瓶颈时，我们可以通过横向扩展相关组件来应对流量的变化。 对于直接对外提供Rest接口的Tomcat服务，如果单Tomcat服务器达到性能瓶颈时，我们可以增加Tomcat服务器来进行横向扩展，同时为了对外提供统一的网关，我们增加了LVS+Keepalived这一层来实现，如下图所示：
正常情况下，LVS使用DR模式代理若干台Tomcat服务器，keepalived是实现LVS的高可用的。当其中一台LVS出现故障下线后，keepalived通过虚拟IP技术快速切换到另外一台可用的LVS上。 另外对于HBase和Ceph的扩展性是简单易于实现的，只需要增加待扩展的机器，进行相关配置，即可快速加入集群，相应的数据也会进行rebalance。 1.4 限流算法在上面的功能概览中简单的说明了在某些场景中我们需要进行流量限制，那么这里将详细介绍限流的原理。 在OSS中，我们使用Guava的RateLimiter作为限流的组件。Guava的RateLimiter的限流方式有两种：漏桶算法和令牌桶算法。我们采用的是令牌桶算法。 对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。如图所示，令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。
我们的OSS就是采用令牌桶的方式来对流量进行限制的，当客户端以某一稳定的速率来向OSS写入的时候，系统是稳定的并且大多数的时候是这样的。但是我们有时需要应对流量峰值，这个时候超过我们规定的流量就会被限制。现在问题来了，被限制的流量如果直接丢弃，那么可能重要的文件被丢弃，这样显然不符合我们对OSS定位为高可用存储系统的要求。于是在限流的逻辑中我们加入了以下处理流程：当流量达到系统的瓶颈时，我们将被限流的流量写入kafka，等到系统负载降低的时候，再从kafka中读取这部分流量重放至OSS,这样既保证了OSS的稳定性，又解决因限流带来的数据丢失问题。 2. 功能概览 2.1 文件上传
客户端以RESTFul接口方式向OSS服务器发送上传文件的请求，OSS将文件存储到HBase或Ceph中，然后向客户端返回存储的状态。 我们将文件名作为存储的唯一标识，这样设计的好处有两点，第一，我们不需要返回用户文件在OSS服务器的存储路径；第二，也可以避免同名文件反复上传。 2.2 文件下载
客户端以RESTFul接口方式带上需要查询的文件名请求OSS服务器，OSS根据文件名查询对应的文件，返回请求客户端。 2.3 流量限制流量限制是以一种被动的方式来对流量进行控制的方式。我们可以通过压力测试来粗略估计OSS所能承受的最大压力，然后在配置文件中配置限流的数值。这里要注意的是，需要根据业务的特点对限制的流量进行处理，其一，可以完全丢弃掉被限制的流量；其二，也可以对限制的流量进行相应的处理。 3. 场景分析 现以公司某项目做讲解来进一步说明OSS在项目中的实际应用以及最佳实践。 3.1 项目的现状3.1.1 流量情况以中期某城市交付为基准：每秒约120Gb流量，每天1.5亿个文件，每秒大概1800个文件。 其它各分中心的数据均为上述城市的倍数，比如A中心的比例系数为33.33，那么它每秒的流量约4000Gb，每天约34亿个文件，每秒大概6万个文件，以此类推。 3.1.2 单机性能目前单机Tomcat能支撑最大12000TPS，对于各中心每秒的数据量，单机显然不能支撑这么大的数据量，我们需要采用Tomcat集群来支撑这么大的数据流量。 3.1.3 流量峰值（编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
