最近这一年可能听到对象存储比以前更多一些了,首先我想回答一下这个问题:为什么最近一年对象存储这个事就引起关注了?

我觉得是这样的,首先这里讲的对象存储我更喜欢称之为S3存储,因为对象存储有不同的含义,所以我更喜欢说成S3存储或者类S3的存储,这种存储有两个特点:

首先第一个没有目录树,没有复杂的结构,而是把文件,或者说我们说的对象,放在bukets里,把对象扔到桶里面,同样是数据,放在文件存储里是文件,放在对象存储里面就是对象。

比如一个照片放在文件系统里面就称之为文件,放在对象存储里面就是对象。

另外一个特点是它不是以前经常用的文件系统的操作,比方说要 mount、fopen、flseek、fwrite、fread 等等要做这样的事情,直接是一个buckets,放了一个对象进去,然后读一个对象出来,很简洁。

我们在做企业级的时候,这时往往说接口跟以前不一样,给应用开发的难度增加了。而实际上仔细的看看对象存储的接口,如果确实做过编程的话就会发现用对象存储来存文件会比你用文件系统要简单的多。这中间其实就有了对象存储会火起来一个很重要的原因。

为什么最近对象存储比较火?

刚刚提到刚才说的接口的问题。首先是对象存储产生的原因是数据量增长,增长的速度越来越快。90%都是非结构化数据,最具有代表性的就是诸位现在拿起手机拍的时候的图片。

图片数据量的增长速度非常惊人,其次是视频,视频的数量增长速度并没有达到图片这么多,但是从总体数据量来说,它的速度是非常惊人的。

在之前的一个技术分析上听过一位嘉宾分享,他说现在有128帧4K高清的视频总体来说比同样一个高清视频数据量有接近几十倍的增长。

因为普通我们看的视频是高清,1080P的高清视频,4K就是1080乘以4,应为视频画面是矩形的。所以每帧数据量增长了16倍,而我们平时看到的视频是20~30帧每秒,所以从这个角度来说128帧的视频,数据量又有了翻好几倍的增长。

所以这个增长是非常惊人的,而且大量的是非结构化数据。这里面还有一个现象就是我们说的照片属于海量小文件,而视频属于大体积文件。

还有我们平时收集的一些东西会有不同的处理方法,有的人把爬虫爬下来的文件合并成大文件存储形成超大文件,也有爬虫爬下来数据是没有合并直接存储,合不合并取决于你的数据处理后端的设计。

我们就遇到过客户,他的爬虫爬下来的数据时不合并的,他这种情况下就是海量小文件存储,所以就出现两种现象,大文件和小文件并存。这个跟以前不太一样了,是新的挑战。

随着虚拟化云化以及互联网等业态整个发生变化,数据的访问形式也不一样。比方说我们以前用共享目录会怎么做的呢?

有几个节点,monnt上共享目录以后在里面可以操作文件,当文件操作完了你可能要把文件关上才能确认数据能够落盘,实际上还没有最终确认落盘,要umount才能最终确认。

这样一个过程,大家想想如果我们现在都是虚机的话,这些(云主机)可能是随时创建随时销毁,请问这些云主机访问共享数据的话,你怎么样让存储频繁的处理mount、umount和高度的并发呢?

这个事情是难以想象的,到底有什么样的文件系统可以支持。如果是我们对象存储的话,我们直接通过发 HTTP 请求共享数据,做的非常简单,为什么?

因为我们平时在浏览器里面就是这样操作,人们的网站就是全球的用户访问一些共享数据的。所以这种接口也是非常有利于数据共享,而且它的操作更加简单了,我不用再打开一个文件怎么操作,只要发一个请求就可以了。

而在服务端来说,对访问权限的控制也更简单了,我给不同的用户颁发不同的令牌,随时可以颁发随时可以撤销,访问控制变的更加简单了。这些都是现在对象存储逐渐引起关注的原因。

事实上在美国硅谷,对象存储已经变成了很大的一个生意,很受关注的一个领域,但是在国内可能这个事情也就最近一年之内才刚刚起来,为什么?

我发现这个原因并不是在IT技术发展,而是在于其他产业的发展。比方说美国现在用对象存储存基因数据,而且有很强烈的需求,因为测序技术水平不一样,美国的测序技术比国内的要先进几年,我不敢说太长时间,两到三年肯定有了,以前华大基因的团队,当年还在中科院,人类基因组计划的1%,当时就已经非常伟大了,而且花了很长的时间。

但是现在很快就可以把一个人的基因组从头到尾测一遍,从而产生巨大的数据量,而这种就会需要有适应这个需求的新型存储系统,目前来看对象存储比较好的适应这个需求。

所以这就是对象存储为什么最近会在企业级的市场里面,或者说企业级的用户引起关注非常重要的原因,我是这么理解的。

OpenStack Swift 分布式对象存储

OpenStack 是非常庞大的体系,我在过去的两年内做了很多的分享。我会强调 OpenStack 不是简单的管理虚机,而是非常庞大的体系,这个体系还在不断的扩大不断的发展。

我觉得发展到今天这一步,OpenStack 某一个项目拿出来就可以做很多事情,而我选择的关注点是 OpenStack Swift,可以支持异地的双活多活,可以做分层和分池。另外可以直接的支持 Hadoop,它的架构大概是这么一个样子。

Proxy 节点主要提供前面讲的接口,存储节点主要是存数据的,对象存储会把对象放到桶里面,桶的概念在 Swift 里面叫 Container ,桶的数据都放在存储节点上。

还有另外一个比较重要的一点,我们说对象存储与生俱来有一个服务的对象是云的用户,所以他需要云存储的特性,做到用户隔离的东西,这里面还有一个东西把各个用户的空间逻辑划分开,说到这里不得不提一下,对象存储在安全性这方面其实比传统的存储有它一定的优势的。

比方用户隔离这个事情,如果用过像 OpenStack 或做过虚拟化 ,你可能会知道创建一个云硬盘,其实速度相对来说比删除一个云硬盘要快,有时候要快很多。为什么呢?

因为在很多云的环境里面,我们为了防止一种情况,就是创建一个云硬盘,给这个用户去用,然后用户删除了硬盘,但是没有做其他的操作,只是把云硬盘逻辑上销毁了,任何用户在这个云平台里面看不到这个云硬盘,这个时候用户资源也释放了。

当另外一个用户创建云硬盘的时候,这个位置如果重合,第二个用户就有可能把数据恢复出来。

所以这是比较危险的事情,所以我们在很多云的环境里面,在删除云硬盘的时候会做一些擦除的工作,所以这是比较消耗时间的,这是为什么在很多云环境里面你创建一个云硬盘比你删除一个云硬盘要快。

通常我们认为写数据比删除数据是要慢的,但是云硬盘比较特殊,要做擦除,起码要把前面关键的部分擦除掉。但是对象存储没有这个问题,为什么?

对象存储吐出来的就是你要请求的对象的数据,不可能涉及到我还可以把别人的数据恢复来的问题,所以正好说到这里提一下。

那用户的请求进来会首先被 Proxy Server 处理,会根据一个叫做 Ring 数据结构找到数据的位置,其实这个 Ring 原理上就是一致性哈希,旦做了一些改进,提高了整个系统的可靠性和可用性。去把数据的读出来,这个就是它的工作原理。

我们实际部署的时候,有可能没有单独 Proxy 节点,而是在服务器上把 Proxy Server 服务和三个主要的存储服务都跑起来,这样形成全对等部署,这是可以的。

这一页就是说目前我们已经了解了确定是将 Swift 用在生产环境中用的用户,如果说没有确认是用到生产环境中我就没有放上去,这仅仅是我个人查阅资料和做过研究甚至接触过的一些用户,所以实际上 Swift 的用户群是很大的。

国外的就不说了,国内的其实典型的几个像中国电信是天翼云存储,天翼云的事情比较复杂,因为有好几个不同的方案,但我确认用的是 Swift 支持云存储的。

另外爱奇艺图片存储和部分视频存储是放在 Swift ,还有中国航天是我们的客户了,他主要存遥感图片,遥感图片无论从使用方式上还是获取途径,图片的质量、数据量使用方式上近十年发生了巨大的变化,传统的存储不能满足要求,我们就给他上了云存储,以后民用的遥感图片,会有很大一部分放在 Swift 里面。

分布式对象存储的运维需要关注些什么?

我们说运维首先是看,然后做一些事情。我们从看的角度来说,假如客户问了一个问题,他说现在要换存储系统,以前测的都是fio、dd这样的测试的数据,说现在换对象存储应该关注什么东西。

测试是一个方面,平时的运维应该关注什么,我们可能关注的比较多的像传统存储也有的 IOPS ,然后吞吐率,还有延迟,某一次操作到底使用多少毫秒,这些是传统存储里面就已经关注的。

我们说这些对于对象存储来说仍然需要关注,但是我们仔细思考一下我们运维的目的是不是这个,实际上最终目的并不是这个,而是为了保证存储系统:

1. 存储的可靠性,要保证说我们的数据存进去多长时间不丢,或者我们有这个信心数据不丢,这是数据持久性。

2. 可扩展性,今天是十个节点,明年要扩展20个节点,后年100个节点。

3. 可用性,在什么样的情况下,存储系统的存储服务是可用的,另外还有一点,数据是可用的。

曾经遇到过有朋友找到我,他用 HDFS 存储,(HDFS)本身是没有问题的,原先是10个节点,又扩了10个节点,然后数据就读不出来了,其实很正常,数据都在迁移。

后来扩了10个节点比之前的更大,大量的数据都在迁移,所以数据读不出来了,数据可用性就有问题了,所以我们在强调存储系统数据的运维目的是为了保障这些,也就是说这样的事情。

我们对对象存储我们需要有新的运维手段,新存储要有新运维。

实际上我们就做了一些研究,我们认为有一些东西是比较值得关注的,这些东西呢?(可以坦率的跟大家说,这是我们产品的界面,我并不是要介绍我们的产品。)

我想说的是底层的东西是 Swift 赋予我们的,我们只是把有些东西给它做一些日志的分析拎出来,在里面调用 Swift 的接口拎出来,综合的做了展现。比如说我们关注每秒钟有多少次 HTTP 的请求,这个是一个方面。

另外呢,也就是说我们关注的不仅仅是底层的各个节点的 IOPS 的压力和网络的压力,而是从你真正的对象存储的接口去看,他的整个系统压力是怎么样的。

而我们会发现,其实虽然你每秒钟请求次数这么多,但实际上每个请求的响应延迟是不一样的,你就会发现有的请求很快回来了,有的请求很长时间才响应。甚至在我们这个截图里面出现了5秒钟以上,这个是怎么回事?

上面图里显示每次的请求的数据量,这个时候如果你在这边看到你5秒钟以上的请求全部都是 500 兆以上的大对象,实际上从某种意义上来说两方面,一方面是有一定的信心,存储系统没有太大的问题,工作还是正常的,为什么延迟比较长呢?是因为数据量比较多。

考虑另外一个事情,既然我们的系统里面我们的用户会有这么多大对象的读和写,那我们是不是要针对大对象做一下优化呢?因为 Swift 的默认把对象不做切片直接存上去的,而 Swift 是从前几个版本就已经开始提供了大对象支持。

使用动态大对象接口,你不需要去写死说每个切片有多大,每个切片第几字节到多少字节,切完传就可以了,然后你告诉 Swift 这里面有一个对象,这个对象是大对象,已经切片传进去了,这个对象的名字是什么。

Swift 在你 GET 的时候会自己把这个东西找出来给你拼装一个大对象给下载出来或者读出来,现在用起来是很方便的,大对象的支持目前是必须好的。在这边也是一样,这是写的这是读的。

另外一方面你会看到5秒钟以上的请求,到底是读还是写,在出现5秒钟以上的请求的时候它的(并发)压力是什么样的,如果这个时候你看到还都是小对象,你会发现某些时段压力会比较高,这时候再去追溯一下,怎么追溯呢?

从这边看IP,列出了前十个访问量最大的IP,如果你知道这些以后,你再去追溯说这个IP到底做什么,为什么它会造成这么高的压力导致我们整个系统响应延迟变长,整个系统的性能下降。

所以我觉得应该关注这样的事情,我们以前可能会关注比方说文件系统到底是哪一个进程在频繁的做操作,现在我们是对象存储,我们应该关注的是什么呢?

我总结一下刚才说的这些事情,应该关注的你这些请求到底做了哪些事情,然后就是你的请求到底是谁发出的,这就好比是我们在传统存储里面去关注哪个进程是如何操作我们的存储的,每个进程到底做了哪些操作,所以这是对象存储我认为需要去关注的事情。

中间还有哪些事情?当然了我要说一下,并不是说那些各个节点上的压力不重要,网络的带宽占用了多少就不重要,那个也是很重要的,否则的话没办法定位节点的问题,实际上在这个界面的,这个跟传统存储差不多,我就没有展开讲。

还有一些什么东西呢,我们说对象存储还有一个特点,很多对象存储系统是最终一致性,最终一致性系统以前一直有一个问题,就是我知道数据是最终一致的,但是我不知道哪些数据已经一致了,这个比较讨厌。

就是我知道数据特别是在跨地域部分的时候,比方说一个在上海,一个在深圳,甚至还有一个数据中心在北京,三个数据中心,三个跨地域的数据中心组成一个大的 Swift 集群。

你从深圳的数据中心写进去的数据,通过后台的数据复制网络复制了两个副本到上海的数据中心这儿,但是很难去确定到底哪些数据已经复制过去了,这个是存在很多用户心中的一个疑问。

以前我们只能笼统的回答说你要对一致性要求高的话,你就做一些配置,就不要让它后台异步复制了,你这边已经有了一个副本再返回可以做这样的操作,要么最终一致。用户说我可以容忍最终一致。

刚才我说跨地域性能比较差,是反应的可用性,有的工程师比较较真,说 CAP 定理是一致性和可用性不可兼得,但其实一致性和可用性是一个权衡,并一定是性能的权衡。

可用性和性能比较差,我不想要这个,我可以容忍最终一致,我就想知道我到底哪些数据还没有复制过去,我起码我知道这个事情以后,知道哪些数据需要通过其他途径恢复。

以前这个其实一直是一个疑问,我们现在尝试做一个事情,就是让用户知道哪些数据已经完成跨地域复制了,这个事情简单一想做完复制以后做标记就完了,但实际上不是这样的,特别是我们要设计的目标是什么,一个 Container 里面存千万级的文件,Swift 一个 Container 存亿级的比较困难,存千万级的不成问题的。

存千万级的时候很难确认哪一个数据已经复制,哪一个没有复制。我现在换一个角度,起码我告诉用户一个事情,哪个时间点之前的写入操作已经在两边都同步了,告诉用户这个事情,然后他就可以做一个决定,当我们如果万一有哪一个 Region 不可用了,用户会知道哪个时间点,比方说今天上午10点之前的数据,这个在另一个 Region 全部都有了,剩下来的数据我们再去看,要不要再通过其他途径去追溯。所以这是对象存储运维里面的跨地域部署的时候,一个比较特殊的问题。

实际上我们现在做的方法,也是通过Swift的日志分析,除了前面介绍的四个主要服务以外及还有其他的服务,replicator、auditor等,根据这些服务的日志我们可以得到一些数据综合的分析。这个是一个我想分享的,对象存储的运维。

SSD 在 OpenStack Swift 中的应用

SSD这个事情,因为其实本来我是想展现一个图表,但是那个图表其实不太好画,因为我们为了得到这个表格里面有限的几个数,我们做了大量的测试。这个数据里面,回答了我们怎么样正确的使用SSD。

我用的是这一列数据是使用8块 SATA HDD,这一列是用了SSD存放 Acount 和 Container 数据,这里用的 SSD 是 SATA 接口的 Intel 3510 ,是低端的一款。

那么最右边呢,全部是SSD,实际上的数量也不多,八个SSD。所有的数据都是平均的每秒钟的请求次数,这个时候我们会看到,读性能实际上100KB相对来说算小对象,小对象读的性能已经达到了1400多,但是当你全部使用SSD的时候仅仅提升到了1500多。

从两个角度来说:

第一,如果你是小对象读比较密集的话,SSD对你的帮助并不是很大,这个一会儿要说的,这个其实是有问题的。

第二,如果是小对象写的话,实际上你会发现我们把Account和Container放到SSD上性能就会有大幅改善,这里面要考虑经济性和性能之间的权衡问题。

但是我们是100兆大对象的话,读和写全部使用SATA是比较糟糕的,如果使用 SATA 加 SSD 的话效果也不是很好。

实际上就是想说,我们有一种做法把 Account 和 Container 数据用 SSD 存,这样的话可能在容量和经济性和性能方面都能够达到一个比较好的折中。

如果说是大规模集群来说的话,我们可以把一些节点搞出来,专门放 Account 和 Container 数据。甚至可以考虑把这些节点,上面我们讲的比较典型的方案把 Proxy Server 和存储服务分开安装,实际上在某种情况下做优化放到一起,Proxy 节点上放一些对象的 Account 和 Container 数据的存储服务。

因为这样的话,比方说我们有一个客户用的方案,就是他搞了一堆机器,还有就是两U的带 SSD 的,这个时候 CPU 和内存实际上也会比较好,那个时候会把两U的跑 Proxy、Account 和 Container ,把 4U60 盘的存 Object 的数据,这样是比较好的方案。实际上换句话说在Swift里面使用SSD是有必要的,但是没有必要把它都放在 SSD 上存,为什么?

这有两方面,你是百TB的容量或者以上,按照 SwiftStack 的说法,是说0.5的PB以下 Swift 发挥不出来优势。但是后来这个观点有所松动,他也要做生意。实际上我个人的经验来说,我认为在百TB级容量的时候,或者规划在百TB级容量的时候已经能发挥出它的优势了,相对于传统存储已经有优势了。

其实对于这种容量来说的话,你想想看你会用多少个盘,其实如果是百TB的话,如果你考虑到三副本实际上在一百个盘上下,就看你用多大的盘,实际上这些盘一起提供的 IOPS ,已经在一定程度上能够满足你的要求了,而我们说你没必要全部用 SSD ,成本会很高,所以这个并不是很有必要。

但是把 Account 和 Container 拿出来放 SSD 是有必要的。然后我们再回头说一下这个问题,为什么会有后面这个结论。

我们说 Swift 的逻辑上的存储空间的划分基本上是这样的,整个的Swift集群划分成一个个 Account ,对应用户,每个用户分 Container,对象放在 Container 里面,Container 理解为租户下面的目录。

那为什么用 SSD 来存 Account 和 Container 会优化他的性能呢?

这跟文件系统里面把元数据放SSD上是类似的,但原理上是不一样的,这也解释一下为什么( Account 和 Container 放 SSD 上)对读性能的提升不是很明显。

我们再回过头看一下上面的架构图,一个请求进来 Swift 做两个操作,第一个把这个 Object 写下去,另外要更新一个东西,就是更新 Container ,告诉 Container 下面多了一个 Object ,要做这样两件事情。

对于 Swift 来说,它的操作并不是同时做的事,或者并不是说我先更新 Container 。Swift、Container 和 Account 存储逻辑差不多,把 SQLite 作为数据库,一个 Container 对应一个数据库,一个 SQLite 数据库就是一个小文件,所以它也是作为小文件存下来的,跟 Object 一样。

那 Swift 是这样的,你有一个请求进来,然后首先通过这个 Object Server 把对象写进去,再通过 Object Server 发请求更新 Container ,这样尽量的提升当有大量小文件写的时候的性能,因为它把 Container 的更新操作作为一个后台的操作。

实际上我们在用 Swift 的时候会发现这样的情况,就是你如果说密集的写一批小文件进去的时候,你查 Container ,你读的时候是能读出来的,但是Container还没有在后台更新,这是他的一个特点。

反过来,读的时候,跟 Container 一点关系都没有,这就是他和文件系统非常大的一个不一样的地方,因为我们在文件系统中一定是查元数据服务器的,但这个地方不用,或者文件系统里面不一定有单独的元数据服务器。

对于 Swift 来说,则不是这样的。它是直接的算到你应该从哪里取 Object 就可以了,读的过程其实跟 Container 并没有什么关系。

那如果说没有关系的话,跟 Container 后面用的盘,用的存储介质也没有什么关系了,这也就是为什么我们换了 SSD 以后,把 Account 和 Container 放在 SSD 以后,对读性能没有提升,对写性能有提升。

更新 Container 实际上是一堆小的 IO,如果把 Container 和 Object 放在同一个盘上,是后台更新了,单某种程度上还是增加了 IO ,磁盘性能会被很多小的 IO 带住,所以才会导致性能下降。

总体来说,对象存储场景下 Swift 的性能还是比较优秀的,这个不仅仅是我们,我们的客户和其他的用户都测过。Swift 社区现在要进一步提升它的性能,用 Go 语言重写,虽然现在还没有达到生产中可用,但是确实是一个非常有前景的事情,也是非常值得期待的事情。

再提一下用 SSD 做 Cache 固然是一个方法,在性能价格之间做进一步的权衡,但是它还有一个问题是怎么样做自动分层?

这个实际上这是比较难办的,因为用户的体验是跟应用相关的,而应用怎么样用数据,存储系统是很难感知的,所以我现在不推荐自动分层,可以搞一些规则之类的,提供接口让用户自己去做。

比方说搞两个 Container ,老的数据我就不做自动分层了,让你用 Container Sync ,把 SSD 的 Container Sync 到磁盘上,用户就会知道,Sync 以后的数据,不期望有很好的性能表现,这样会比较靠谱的。

另外就是如果想要发挥 SSD 的性能,像之前提到的大文件,如果发挥极限性能,达到万兆的极限,那怎么做呢?需要做负载均衡,把负载分到各个节点上。

一个负载均衡集群应当是多少个 Proxy 节点呢?应当是大于3,至少有三个 Proxy 。

再谈 EC (Erasure Coding,纠删码)

最后再提一下纠删码,我想说的以前我们曾经担心的纠删码带来的开销,事实上并没有大家想象的那么严重,尤其是在大文件读写的时候。小文件存储场景不推荐使用纠删码,因为把 IO 切的更碎了,所以那样的话会影响性能。

但是总体来说的话,尤其是编解码计算这一块,单节点就可以达到数GB/S,所以纠删码对性能的影响并没有原先想象的那么大,瓶颈最终会落到网络上。

我觉得对于 Swift 来说,纠删码从2013年开始搞,后来没搞定,拖到2015年,经过这一年的折腾,希望大家能够尝试尝试,特别是对存大文件来说节省空间,以前是三副本,33% 的资源利用率,现在(参数为)6,8的纠删码能达到 75% 的资源利用率了,翻倍的改善。

Q & A

提问:我的问题就是不光Swift,您是基于Swift做产品创业,其实在对象存储和其他的系统,您觉得Swift优点比较多,我不知道有没有跟这几个系统做比较?因为像别的公司,有的存储系统像金山云也号称性能很出众,各说各家都说的很好。

李明宇:
首先我认为Swift就是特别专注做对象存储,金山云做的也不错,每家有每家的方案,我们选择的方案是 Swift ,我个人的体会用的很舒服,没有那么多事。

比如今天怎么又出了莫名其妙的问题,明天客户又打电话来,从来没有出现过这样的问题。这个一方面我小吹一下牛,我对这个东西比较了解,该填的坑在过去的五年都已经填了.

另外我确实觉得用起来比较好,我也搞过别的系统,还有我们以前用的别的系统,相比之下 Swift 是比较省心的。

另一方面,我觉得 Swift 有它自己的一些比较特殊的点能够满足我们所面对的产品需求,比方说我们现在有一些金融,特别是银行,银行有硬性规定,两地三中心,有的用户说我要搞多Region,要跨地域双活怎么搞呢?

以前的做法就是说我搞两个集群,同步数据,我问你真的规模大了,你怎么确保(数据同步),就说有一种情况,整个 Region 全部毁掉了可能性不大,因为某种情况下断了然后又恢复了,你怎么样能够把这个数据给它最好的同步过来。

而且说断的时间点之后的数据能够确保你最终整个系统里面同步的数据是你新的版本,而不要被旧的版本覆盖了等等的问题,你想那边写入了一百万个,你怎么确认那一百万的文件一定同步过来。

其实这些都是问题,这些问题真的做起来没那么容易的,你还有怎么样同时在两边写,Swift在底层把这些问题解决了,这是他的一个特点。

还有其他什么特点,我们敢去用EC,实际上也是 Swift 在这方面表现的比较好,我们也是经过大量的测试。

还有另外比较重要的一点,Swift 里面是可以做插件的,我们会遇到一些情况,比方说我们希望能够对落盘的对象数据进行加密,为什么?

因为你的盘坏了以后可能送去修要送到别的地方去,盘扔出去以后不受控了,里面的数据会不会被别人恢复,这都是问题,还有盘被偷了,七七八八的事,其实都需要做对象加密,怎么做呢?

实际上我们就可以做一些中间件,所有的进来以后都要通过加密才能落上去,这个事情要做插件对于 Swift 来说是很容易的事情。如果用别的方案我不知道怎么样实现,还有我们现在的 Swift 做了一件很聪明的事情,他可以让你设置,你用不同的认证方法进去。

所以我现在就可以做一件事情就是不同的数据通过不同的认证方法访问,比方说有的通过USB访问,有的通过指纹访问,有的通过用户名密码都是可以做的,不同的数据有不同的认证方法。

实际上我们更看重这些点,从我做厂商的角度来说,我要尽量满足客户的需求,客户的需求是多样化的,这种方式让我很容易的满足客户多样化的需求,所以这是我选择Swift的一个非常重要的一点。

提问:您好,我这边有两个小问题,就是说你刚才说后面数据同步的时候,还有 Auditor 进程,有时候会非常的耗 CPU ,你在你方面有什么优化的经验吗?

李明宇:实际上并不是特别的耗,更新 Container 的时候,对 Container 底下的盘的 IO 是一个挑战。实际上如果数据都同步完了,不会占IO的事情,因为没有数据可同步了,但是你反过来说如果真正有数据没有同步,会希望尽快的同步。

至于 Auditor 进程,做数据完整性检查,因为每隔一段时间把数据都读出来检查一遍,所以那个是会占用不少的,按默认设置 Auditor 每隔几十秒会看数据是否完整。

这确实比较讨厌,因为我们发现基本上查不出来什么问题,坏的话都是盘的故障,Auditor 只管我的数据出问题了,本来存的是12345,后来变成12346了,这个很少见。

所以能做的是把周期延长,因为出现问题的概率很低,没必要那么频繁的检查,当然周期延长这样的话会冒更多的风险。