mailstore技术解决方案.docx

mailstore技术解决方案.docx

《mailstore技术解决方案.docx》由会员分享，可在线阅读，更多相关《mailstore技术解决方案.docx（15页珍藏版）》请在冰豆网上搜索。

mailstore技术解决方案

MailStore产品

技术解决方案

目录

技术解决方案1

1项目概述3

2系统架构3

2.1架构说明3

2.1.1基本存储系统4

2.1.2分布式缓存4

2.1.3程序库4

2.2工作流程5

3实现方案6

3.1方案一6

3.1.1基本描述6

3.1.2具体技术7

3.1.3使用流程8

3.1.4优化方案8

3.2方案二9

3.2.1基本描述9

3.2.2具体技术9

3.2.3使用流程11

3.2.4优化方案11

3.3方案三11

3.3.1基本描述11

3.3.2具体技术11

3.3.3使用流程12

3.3.4优化方案12

3.4补充说明12

3.4.1分布式缓存12

3.4.2负载均衡12

4方案评估13

4.1综合结果13

4.2可行性14

1项目概述

本存储系统的关键是为上层应用提供KV访问接口，在保证访问速度、可靠性和扩展性要求的前提下，对于实际的存储方式并无具体的要求。

基于此前提，本技术方案提出将上层接口和底层存储分离，通过中间抽象层完成二者之间的映射，具体的抽象架构以及参考实现方法如下文所述。

2系统架构

2.1架构说明

本技术解决方案的整体架构如下图所示：

在上图中，外部接口以下为整个存储系统，用户程序通过程序库提供的KV访问接口（以产品需求说明书中接口为准）与存储系统交互。

整个存储系统由三部分组成：

基本存储系统、分布式缓存、程序库。

在抽象架构中未包括系统监控等组件，在实现方案中有具体说明。

现针分别介绍上述三个部分的功能和设计思路。

2.1.1基本存储系统

基本存储系统负责数据的持久化，直接与存储硬件交互。

在本架构中基本存储系统可以采用任何成熟的存储方式，比如分布式文件系统（MFS、GFS、Lustre、HDFS）、分布式数据库（MySQL、CouchDB、MongoDB）、或者分布式键值对存储系统（Cassandra、HBase、HyperTable）等。

基本存储系统无需关心上层应用的访问方式，只要按照自己的存储接口提供服务即可。

由于基本存储系统负责数据的管理，所以在具体的实现方案中基本存储系统必须具备基本的分布式管理能力。

容错、扩展性等能力需要对不同的基本存储系统进行评估，必要时需要进行适当的再开发才能实现本项目需求。

2.1.2分布式缓存

邮件存储系统具有典型的一次写多次读的访问模式，所以配置分布式缓存可以极大的提高系统的响应速度。

而且本项目要求的KV访问接口与分布式缓存访问接口很容易匹配（二者几乎可以一一映射），系统开发效率高，使用简单。

提高分布式缓存的服务能力有两种优化方法：

1．搭建分布式缓存集群，将数据根据KEY进行划分，缓存在不同的集群节点上。

这样可以提高缓存容量，也可以提高访问缓存的并发度。

2．根据用户使用特点控制缓存失效时间。

跟踪用户的使用习惯，对于活跃用户，可将其缓存失效时间加长，提高访问命中率；对于非活跃用户，减小其缓存失效时间。

在提高缓存利用率的同时，也提高了系统的响应时间。

分布式缓存目前已经有很多成熟的解决方案，如memcached、redis等，在大规模生产系统中广泛部署。

本项目完全可以直接使用这些成熟的系统。

2.1.3程序库

程序库是衔接用户程序和存储系统的关键部分。

对应用程序，它提供产品需求说明书定义的KV接口；对低层存储，它需要对不同的基本存储系统进行适配，完成KV接口到低层接口之间的映射。

这个映射的工作由驱动层实现（图中的Drivers）。

设置中间驱动层的原因在于：

●基本存储系统是一个独立的领域，目前有众多的研究机构、厂家在进行不同的工作。

基本存储系统的演进速度非常快，新的存储系统在存储容量、容错性、扩展性上都会有极大的提升。

为了充分利用最新最先进的存储系统，有必要增加一个抽象层，将具体的存储系统和上层应用去耦合。

●基本存储系统的类型很丰富，可以是提供POSIX接口的文件系统，可以是提供专用API的文件系统，可以是通过SQL访问的数据库，也可以同样是KV接口的键值对存储系统。

这些访问接口与本项目的接口各不相同，必须设置中间层将本项目的接口映射到基本存储系统的接口上。

●通过提供不同的驱动层，不同的基本存储系统可以共存，对上层应用透明。

这样针对不同的应用数据（邮件正文、邮件附件）可以采用不同的基本存储系统，进一步提高整个系统的服务能力。

2.2工作流程

在本架构下，应用程序通过程序库与存储系统交互。

Bucket操作（createBucket、ifBucketExist、deleteBucket）直接由Driver映射至基本存储系统，不经过缓存；对KV对的操作都经过缓存，具体为：

publicvoidsaveBLOB（Stringbucket_id,Stringblob_id,

InputStreaminput_blob_stream）

throwsBLOBStoreAccessException;

写入基本存储系统；

key=bucket_id:

blob_id

memcache.set（key,in.read（））

publicvoidloadBLOB（Stringbucket_id,Stringblob_id,

OutputStreamoutput_blob_stream）

throwsBLOBStoreAccessException;

key=bucket_id:

blob_id

value=memecache.get（key）

ifvalueisnull:

value=从基本存储系统读取

output_blob_stream.write（value）

publicbooleandeleteBLOB（Stringbucket_id,Stringblob_id）

throwsBLOBStoreAccessException;

key=bucket_id:

blob_id

ifmemecache.get（key）:

memecache.del（key）

从基本存储系统中删除

3实现方案

前面介绍了本方案的抽象架构，可以发现将底层存储系统和上层抽象接口分离，具体的实现方案就非常灵活，可以根据存储部署的特性选择不同的基本存储系统。

只要实现中间驱动，则保证上层应用不变。

一个具体的实现方案包括两部分：

一是确定基本存储系统，二是驱动的映射规则。

现列举几种相关技术比较成熟的实现方案。

3.1方案一

3.1.1基本描述

基本存储系统采用分布式文件系统，驱动层的映射规则为：

Bucket映射为一个支持键值对存储的数据库文件（如BerkelyDB、TokyoCabinet），每个键值对映射为数据库文件中的键值对。

这个映射关系非常直观，驱动层的实现简单。

而且不同Bucket的数据从物理上完全分离（不同用户数据使用不同Bucket），安全性高，进行索引的针对性强。

3.1.2具体技术

分布式文件系统采用开源成熟的MooseFS，本身提供POSIX接口，具有高容错、可扩展、数据副本等重要功能，同时还提供文件系统的运行监控功能。

MooseFS采用类似GFS的设计架构，提供统一的名字空间，有主节点维护，数据分块后存储在数据节点上，读写过程都首先通过主节点获取数据位置，然后直接与数据节点通信。

具体流程如下图所示：

BerkeleyDB、TokyoCabinet都是极其成熟、稳定的单机键值对存储系统，处理文件尺寸可以达到TB级别，完全胜任个人邮件存储需求。

针对上述两种技术，本实现方案的具体架构如下所示：

整个存储系统由主节点（master），备份节点（metalogger），数据节点（chunkserver），缓存节点（memcached）,以及监视节点（monitor）组成。

●主节点、数据节点、缓存节点功能如前所述；

●备份节点实时备份主节点的元数据，一旦主节点失效，备份节点立即生效，保证系统的正常运行。

各组件的功能如前文所述，不再赘述。

●通过监控节点可以查看整个文件系统的运行状态，提供当前数据存储的统计报表。

同时可以部署操作系统监控服务（如Ganglia），监控所有节点系统的运行状态。

3.1.3使用流程

应用服务器使用存储系统之前，首先需要在本地挂载MFS，用户程序通过程序库调用存储功能。

其基本流程如下图所示（针对MFS对2.2的流程细化）。

3.1.4优化方案

将Bucket映射为一个文件的方法很直观，但所有的Bucket在MFS上都位于顶层目录，其不足在于：

●根目录的并发访问太大，必然成为系统性能的瓶颈；

●文件系统文件夹内文件数量都有上限，基本映射方法的扩展性不好，用户数量很容易达到这个上限。

为了解决上述问题，提出以下优化方法：

根据BucketID进行目录划分。

比如BucketID为ABCDEXXXX，则对应的Bucket文件存放在/A/B/C/目录下。

假设BucketID为均匀分布，且ID只能有[a-zA-Z0-9]组成，那么通过上面的划分方法，所有的Bucket将被分散在62^3=238,328个文件夹中，按1亿个Bucket计算，每个文件夹平均存储400个Bucket，根目录元数据操作的压力就极大的降低了。

3.2方案二

3.2.1基本描述

基本存储系统采用分布式键值对存储系统，驱动层的映射规则为：

Bucket和KV分别映射至存储系统中的数据存储模型，在KV模型中引用BucketID实现二者之间的关联。

3.2.2具体技术

分布式键值对存储系统采用Cassandra，具体的映射方法为：

Cassandra建立两个ColumnFamily（CFBucket，CFKV），分别映射本项目需求的Bucket和KV对。

CFBucket和CFKV的格式如下：

--otherkeyspaceconfigstuff-->

--CFdefinitions-->

Buckets的ColumnFamily只有一个Column，ROW的key就是BucketID，用JSON表示如下：

Buckets:

{

bucket_id:

{

value:

"",

timestamp:

timestamp

}

}

KVS的ColumnFamily有两个Column，ROW的key是bucket_id和当前KV中key的组合，具体用JSON表示如下：

KVS:

{

bucket_id_key:

{

bucket_id:

bucket_id,

value:

value,

timestamp:

timestamp

}

}

数据模型比较简单，KVS中通过bucket_id指向Buckets的bucket_id。

由于同样是KV接口，所以需求说明中的Bucket管理可以直接映射到Buckets中的管理，BLOB的管理直接映射到KVS的管理。

驱动层可以采用Cassandra标准访问接口（Thrift），可以看作是Cassandra的客户端。

本实现的具体架构如下：

3.2.3使用流程

Cassandra以网络服务的形式提供，所以应用程序使用前只要提供Cassandra的服务参数，程序库自动完成与Cassandra的交互。

需要注意的是，由于Cassandra采用最终一致性协议，所以程序库必须负责冲突发生时版本的选择。

鉴于电子邮件的特殊性，以时间戳作为版本的判断是可行的。

3.2.4优化方案

Cassandra采用一致性哈希算法将数据分布在所有数据节点上，而且各节点功能对等，扩展性、容错性都非常好。

由于数据分布在不同的节点上，不存在单节点数据访问瓶颈。

需要权衡的是分布式缓存memcached的作用。

Cassandra不同于Redis，它仍然以持久存储为主，所以并未使用内存对数据进行大量缓存，所以memcached的配置是有作用的。

Cassandra所有的数据都在一个名字空间中，随着数据量的增加，访问速度必然下降，如果不对数据进行区分，统一服务必然会导致响应时间增加。

电子邮件的时间局部性非常明显，较老的数据完全可以备份起来。

根据本系统架构，可以对驱动层进行扩展，搭建两套基本存储系统，驱动层根据访问数据的时间来决定从哪个基本存储系统获取数据。

3.3方案三

3.3.1基本描述

基本存储系统采用分布式文件系统，驱动层的映射规则为：

Bucket映射为一个目录，每个键值对映射为目录下的一个文件，以键位文件名，值为文件内容。

这种映射关系比方案一更直观，驱动层的实现更简单，也具有数据物理分离的好处。

相比于方案一其不足在于，一个键值对操作映射为多个文件操作（打开、读写、关闭）性能开销较大。

所以必须充分发挥分布式缓存的优势，来避免频繁的文件读写。

3.3.2具体技术

由于映射关系简单，只要基本文件系统确定，驱动层的实现也就完成了，故不再赘述。

3.3.3使用流程

本实现方案使用方法同方案一，需要首先执行挂载动作，驱动层的映射工作非常简单，故不赘述。

3.3.4优化方案

同方案一。

3.4补充说明

3.4.1分布式缓存

分布式缓存独立于不同的实现方案，可以直接使用成熟的memcached、redis等KV系统。

这些系统本身就是KV接口，而且基本都兼容memcached协议，兼容性很好，驱动层基本不需要做适配即可使用。

3.4.2负载均衡

海量数据在数据节点上的均匀分布也会影响到系统的性能，而且分布的方法随着系统的动态变化而变化，目前比较流行的有三种：

●一是GFS采用的主节点监控数据节点容量，必要时候进行数据迁移，MFS即采用此方法；

●二是Ceph采用的伪随机哈希算法，根据当前存储系统的结构确定性地计算数据的位置；

●三是分布式键值对系统普遍采用的一致性哈希算法。

这些数据分布算法已经在基本存储系统中有成熟的实现，本技术解决方案直接使用基本存储系统的均衡能力，不再专门指定数据的存储位置。

原因在于：

●不同的基本存储系统采用不同的分布策略，驱动层没有通用的解决办法，而如果针对具体系统具体实现的话，难度会很大，因为这些分布算法都很复杂，与存储系统密切关联，会极大地降低系统性能；

●另一个问题在于很难与存储系统本身的分布方法协调。

必须改造基本存储系统才能完成协调，这样就完全抵消了本技术方案抽象架构的好处。

4方案评估

4.1综合结果

前文给出了三种可能的实现方案，三种方案综合比较见下表：

方案一

方案二

方案三

扩展性

√

√

√

容错性

√

√

√

性能

√

√

×

实现难度

√

√

√

升级难度

√

√

√

管理性

√

×

×

稳定性

√

×

√

注：

√：

好；-：

一般；×：

不好

综合来看，方案一优于其它方案。

实际上，根据邮件数据的特点：

邮件正文较小，适合方案一或方案二；附件较大，且数量较少，访问少，方案三更适合。

所以从这个角度来看，最佳的实践方案是一个混合方案。

基于前文的抽象架构，给出的最终实现方案如下图所示：

分别为邮件正文和附件搭建基本存储系统1和基本存储系统2。

驱动层根据启发式信息，比如一般邮件正文为10K~50K，如果要写入的数据超过50K（或者更大，可调的系统参数），则选择基本存储2，否则选择基本存储1。

4.2可行性

上述实现方案的基本组件都是基于普通服务器搭建的，其存储能力和相应时间都达到了项目需求书中的指标。

因此，本技术方案是可行的。