许式伟---------新一代云存储技术实践

七牛云存储联合创始人、首席执行官许式伟带来了题为“新一代云存储技术实践”的精彩演讲，他讲解了自己和存储技术的渊源，并基于多年对存储技术相关的实践和思考，从技术角度对如何设计和实现适合复杂环境的云存储技术解决方案做了总结。

七牛云存储联合创始人、首席执行官 许式伟

以下为文字实录：

我是来自七牛信息技术的许式伟，我们公司主要做云存储，整个产品名叫七牛云，这个名字可能会觉得有点怪。我最早是在金山，是金山WPS2005的首席架构师。我对存储渊源很深，06年底，成立了一个叫做金山实验室这样一个机构，我们主要的研究方向就是云存储这个领域，我中间曾经到百度。最后一家公司是盛大，应该说我到盛大的时候，盛大还没有云相关的一些产品，我在盛大起的祥云计划，也就是现在盛大云的前身，差不多从零开始做的。整个背景是这样的。

大概我们在去年的6月份创业，成立一个公司叫七牛云。今天讲的东西可能会偏技术一点，这个和前面的会不太一样。大概我们讲的东西是这样一些，主要是我们今天分享不会讲某一个技术方案，而是介绍云存储技术领域，所有各个领域的挑战，以及每个挑战，以及我们能想象的各种可能的对策。

云存储技术来说，我分别用这样几个领域来讲，一个是数据模型，一个是可靠性，可用性，一个是伸缩性，另外一个是关注性能和成本这样几个话题。我们主要是讲云存储继续的供给需求，以及可能的难点和技术上的挑战，我们会探讨一下其中应该是什么样的对策，实际上云存储的技术方案差别很大，我们不会很具体的讨论每一个技术的云存储的方案是怎样的，我们会在讲座当中会提一些已经公开的，比如包括谷歌的等等这些会涉及到。

从云存储技术本身来讲，应该说主要从需求的角度来讲，应该分功能属性和质量属性，这两个层次，什么叫做功能属性？我这个存储到底是什么样的存储？有什么样的功能，大体来说，会分成这样三类，一个是键值存储，这应该说是最简单的存储，应用也比较多的。为什么这类多？是因为越复杂的存储越难做，在我们目前，在云的背景下，第二类是数据库，有关心型的数据，主要是这种结构化的。第三类是文件系统，文件系统相对来说，应该说在互联网 应用领域，相对会比较少一点，主要的结构是说我有一个结构，每个节点是一个文件，目录，这样子的一种形态，功能上讲是大概三类。

实际上云存储难点，并不是说我实现这个功能，做一个功能，简单来说，我们这里提到的T86，最简单可以简单到置点，不同语言，名字不一样，这就是键值队，这样的背景下，要实现一个最简单的，可能就是瞬间完成的，如果我不考虑其他的任何要求，只是实现一个T86，用来放数据，一个小时都嫌多了，随便折腾一下就可以弄一个键值对了。云存储为什么难？我对这个存储系统有什么样的品质要求？这才是不同的存储技术的差异所在，这也是为什么一个云存储往往做一年两年，最后能够进入一个商用的场景，为什么会出现？主要是品质上的要求，品质上的要求，主要分上这样几点，这实际上主要是影响结构，也不一定是参数，比如说数据尺寸，这实际上是一个需求，我这个存储有什么？数据大小有多少。

典型的像数据库这种形态的，结构化数据的话，通常是一行一行，每行不到16K非常小的数据，另外一个典型是非结构化的数据，往往现在，大家提到的云存储，更多的是非结构化的数据，比如我放的是照片，音频、视频，为了稳当这种，这种普遍在于200多K，或者多少兆，这种数据就会比较大，这在需求上有不同的地方。访问的特征，这个存储到底是读多写少，还是写少读多？这两个仍然是不同的？因为读多写少是优化图，我们把大部分的请求尽可能的优化，一个系统写多读少，是优化性，这两个通常是矛盾的。

实际上在互联网领域，读多写少的应用会多一点，写多读少，通常偏日志型的是写多读少。这是两个方面。另外最关键的，技术指标，也就是说这个存储，到底我对它有什么样的一些要求？这个要求怎么衡量？一个可靠性，不丢数据，这叫可靠性，大家都知道，不丢数据，完全做到百分之百不丢数据，这是不可能的，这个集群一定是说可靠性能够达到99.9%，最后有多少个，这是一个可靠性的问题。另外一个就是可用性，也就是说，我应该随时都可以访问，不是一台服务器挂掉了以后，部分数据就不能访问了。

伸缩性，也就是说我这个集群，访问压力大了，用户多了，或者说我数据规模很大，在这样的背景下，性能不能有降低，这叫伸缩性。另外一个话题就是速度，用户无论是在美国，还是说在北京、上海、广州，最好速度都是很快的，这个速度怎么衡量？也是一个很关键的指标。最后一个话题，低成本，我在同样的硬件成本下，投入了一万，到底能够支撑一斤等等，或者说我单位的空间，我投入的钱到底是多少？这是成本，另外一个角度来说，不单单是硬件的成本，另外一个成本，也就是说，我管理一万台机器，我需要多少能去管理他，每个人平均管理多少台机器，运维，降低人力成本。存储主要的指标就包含这些方面，技术上来讲，我们的讲话会围绕这些话题一一展开。

云存储里面最关键的话题就是可靠性，可靠性这个话题，实际上用户感知，是一种事后感知，为什么这样讲？因为我可以宣称可靠性有多少，实际上验证很难，因为可靠性是在事后出问题了，才感知到，这个系统确实可靠性很重要，否则的话，自我感觉良好，直到有一天，发现系统不可用了，可靠性为什么难？首先我讲一下，为什么重要？像我们公司是做云存储，并且希望能够生根云存储这个领域，云存储领域，大家都知道，公有云的情况下，我只有一台机器，可以保证一年数据不丢，或者说硬盘的寿命是三年的话，三年可以不丢，但是如果我有一百块硬盘，或者说三百块硬盘，或者说我有一千块硬盘，规模到了一定程度，可靠性就是一个不可回避的问题。因为每天都有硬盘会损害。怎么达到可靠性？很简单，就是这样。两个副本丢失的时候，仍然可以读取到用户的数据，可靠性取决于我们愿意产生多少？这是一个方面，另外一个方面，整个集群的设计实际上也是有讲究的，这个后面会提到。

数据的问题基本上是可靠性最基本的方案。另外一个方案，异地容灾，是指多个IDC之间相互备份，一个IDC，我有三份副本，是否一定可靠？不一定，涉及到这个ID本身，地震，当然，这叫容灾，防天灾的，另外数据的，多副本业界提的比较多，数据冗余，中文叫纠三，EC，或者RAID，本质上接近，都是基于希望是低冗余的，这种情况下的这种方案就会出现。

可靠性这个话题实际上是非常难的话题，有很多挑战，挑战之一是数据的一致性，必然出现多份副本数据的内容不一样，我到底应该听谁的，因为数据可以修改，必然有版本，当我三份副本，有一份副本到底应该听谁的？这实际上是一个比较复杂的问题，自己一致性和高性能是一个矛盾，为什么这样讲？因为如果我们可以放弃高性能，在存储里面，很多东西都是一个权衡，放弃高性能，一致性也不会是一个问题，为什么？大不了我三份副本都写成功，才代表成功了，这种背景下，数据必然是一致的，问题是在于我写入的速度，降到了原来的1/3，这个大家可以理解，所以我必然在一致性和高性能之间，做一个权衡。所以在一致性模型上，如果存储研究过的话，都知道有什么，最终一致性，等等这一系列的一致性的问题。一致性的模型，所有的模型，都是对高性能和数据一致性的保障上的一个权衡。

通常情况下，我们有时候通常读到旧版本的时候，读到旧版本的数据，某些情况下，web上的首页，极少两的用户，集中到旧的首页，是没有太大的关系的，在业务许可的情况下是这样的，不能容忍的是我读出来的数据，前半截是旧的，后半截是新的。数据一致性的对策是什么？实现数据一致性通常是什么样的方案？主流的方式是这样两种。

第一，组成结构，主从结构。

第二，一种是版本号。

主从结构不是完全非常简单的结构，是主从结构的一个优化，我后面还会谈到这点，版本号，亚马逊S3，他也公开了一个，这个系统他实际上是基于版本号的，或者说，当然，基于版本好，或者时间戳，涉及到一些细节的问题，时间不一样，没有办法保证所有的时间是完全对接的，这里面还是有可能会有问题的。怎么办？里面使用的是限量时钟，实际上是一个版本号的方案。数据一致性的角度来说，主要是这样的。这两种，实际上各有优缺点，版本方案通常是理想化系统的人，或者是比较追求这种对称，因为这个方案是完全没有组的，没有组的好处很明显，没有单点，整个系统所有的节点都是对的，对等网络，有些人会崇尚自由，民主的这种想法的人会非常的喜欢，主从结构实际上是一种，我觉得从另外一个角度来说，是一个让步，主从是永远避不开的，任何一个系统里面，存储系统里面，主从是无可避免的，为什么这样。版本号这个方案，实际上有很大的限制，我觉得基本上只有比较简单的，就我刚才提到的三类的存储，T86，TB等三类，T86用版本方案会多一些，TB用版本号的方案会非常少了。

主从因为有一个决策者，里面有很多事情就好办很多，比如促进一致性，数据一致性的话，最简单的方案还是要有一个裁判，就知道应该听谁的？所以主从方案是一种常见的方案。第二个话题，实际上是数据修复，数据一致性是一个难题，数据修复是难上加难的话题。为什么这样讲？因为数据修复是指机器磁盘坏的时候，需要把这块磁盘上的数据搬到其他的机器上去，问题在于，周围第一点，如何计算所丢失的数据是什么？因为那台机器已经坏了，如果磁盘没有坏，把数据拷过来放在别的地方，问题已经坏了，不知道上面有什么，第二个话题，知道了他有什么之后，应该怎么搬数据？第三个话题，数据修复，必须是在一种不影响整个集群工作的环境下进行的。因为你需要向客户提供服务。

第一点如何计算所丢失的数据？从存储本身的结构来讲，比如我拿最简单的存储做比例，他是T86，但是问题在于，我们搬出去的时候，实际上不是根据这个结构来的，而是根据什么呢？根据尼斯可，磁盘号，对此所对应的数据，也就是说，我需要根据T86的数据，重新算成一个新的尼斯可，有什么数据的数据，这个计算要必须非常快，因为什么？因为可靠性的一个影响因素，刚才我们其实没有细讲，现在就可以讲了，可靠性的影响的关键数据，最关键的指标就是数据修复的时间，为什么这样讲？可靠性取决于几点。一个是磁盘本身的生命周期，比如说，当然我们可以买好一点的磁盘，磁盘坏了，可能五年坏，或者两年坏，这是最基本的指标，第二个指标，一块磁盘花多久的时间，数据恢复的时间，一块盘坏，把这块盘的数据，完整重现在整个集群里面需要时间。第三个指标是需要容忍几块盘，同时坏几块盘而不会丢数据。

比如说我们传统的多副本方案，三份副本，指丢失两份副本的时候，不会跑，比如说我最早可能传统的雷达，有一份副本不会坏。这是有影响的，如果我如果能够接受两块磁盘损坏，不会丢失数据，只能接受一块磁盘会损害不会丢数据，两块品质不一样。但是冗余是有成本的，所以N等于多少是不可能随便定的。

磁盘的生命周期，我希望冗余度是多少，数据恢复的时间是多少，三个指标其实只有数据恢复时间是比较大的变化的空间的。这实际上是整个系统的关键指标。正因为如此，我们在数据恢复所有的步骤，如何找到所丢失的数据，如何搬数据？这两个步骤里面，保证所有的步骤都是非常快的。大家可以做一个直观的计算，这实际上也是一个非常简单的计算，我们研究一下一般数据所需要的时间，做一个最简单的比方，有两T的盘坏了，假设我整个磁盘的贷款不是瓶颈，瓶颈是在网络上，局域网的贷款是千兆网络，千兆网络的时候，从一块磁盘，把两个数据，拷贝到另外一块磁盘当中，所需要花的时间，大家可以简单计算一下，这个时间实际上比大家想象的要长很多。

我今天讲的内容，不会讲具体的存储方案，而是讲如果说今天决定要做存储，考虑哪些关键的话题，关键的话题需要怎么解决，主要是这样的。从数据恢复角度讲，主要的是如何让集群的修复时间更短。挑战之三就是如何控制成本，因为三份副本，硬件成本变成3，通常我们的对策用CPU换空间，比如用EC，或者用RAID，这个是有成本的。第二个话题是可用性，怎样保证所有的用户随时都可以访问，不会出现因为机器挖掉，要保证销售集群，这是最基本的话题，不是全部，因为机房也可能是一个问题，机房问题包括两个问题，一个是地域问题，有的机房在部分区域是不可访问的，机房故障，机房不小心由于运维故障，整个机架切断了电源，可用性的对策，实际上应该从多个层次解决，一个层次是杜绝单点，刚才讲了，杜绝单点，主要的方式是什么？一个是Load Balance，另外一个是主从，两者怎么选择？主从是存储里面用的最多的，要保证数据一致性的话，一定要有主从，因为节点关了以后，有一个节点马上顶上。

DNS，服务器集群杜绝单点没有用，因为还有机房也要杜绝，机房，整个机架出现问题的时候，DNS作为选择方案，让用户不要选择那个机房。客户端，自行选择可用的机房。有条件的情况下，客户端是最好的。

伸缩性。两个点，分摊，访问压力、数据规模，单点，一个是写压力，一个是读压力，整个集群读压力过高的时候，很简单的方案来解决，通常比如说要节点分担压力。比如说我们常规的最早的数据库，Master上面加，可由Slave分担压力，亦可在Client加缓冲。Master可以管控一堆，分成两级，总经理，组长，组长下面再管机器，集群化的方案，这种方案也不一定，刚才提到这个方案肯定不会是一个，不是所有的。主要的思路都是差不多把Master要集群化。

分担压力也是这样的，在存储里面，是不可用的，为什么？存储是维持状态的，两台机器是孤立的，不是集群，如果是一个集群，是一种主从的结构了，对策很简单，所有的方案都是压力转移，要么有Master分散，集群化。

数据规模变的情况下，在数据规模变大，是一个算法复杂性的问题，对策，避免出现与数据量呈线性相关的运算。

速度。地域问题，就近访问IDC，通过优化路由，找到最快的路，访问中心的节点。在架构上是优化Cache结构，提高命中率。

成本。降低数据冗余。多副本大于等于RAID/EC。公有资源P2P网络，将成本降到趋近于0。在保证可靠性的前提下省成本，永远的矛盾是可靠小于等于低成本，低成本大于等于可靠。

自动化运维，一个副本挂掉的时候，整个公司的运维人员不用关心，有自我修复能力，数据丢失的时候，会定期把数据重新恢复，理论上说，这个集群，剩余空间是足够的，预留的完全可以不用理，一直跑，控制是体现在整个代码的设计里面。除了代码之外，运维流程尽可能保证自动化。