shell如何控制文件读写不同时_关于数据安全与备份：如何保障数据的可靠性

熟悉架构设计的大概思路后，如何找到合适的技术方案来解决实际问题，才是最考功夫的时候。这一篇就说如何保障数据的可靠性。

不过互联网嘛，说什么都绕不开缓存，绕不开性能优化。因此本篇各种方法都会说到一半突然拐到性能优化上去，这可不是偏题。

01

RAID

我们先从硬件层面开始，逐步细化。说到硬件层面，各位同学首先想到的，可能就是磁盘阵列(RAID)了。

是的，现如今基本上每块主板都支持 RAID 功能，稍微专业一点，还会有独立的芯片来负责计算，以解决 CPU 的计算能力。这算得上是最简单同时也最可靠的解决方案了。

只要其它硬件不损坏，绝对不需要多思考数据损坏问题。但是，如果其它硬件出现了问题怎么办？

因此我的个人建议，是如果真的要应用 RAID，一定要买独立的 RAID 卡。这样 RAID 卡和其挂载的物理磁盘是一个完全分离的模块，在其它硬件出现问题时，完全可以快速转移到其它硬件环境中继续提供服务！嗯，如丝般顺滑～

可能有的同学会说，足够专业、足够细心，就足够解决任何突发情况了，哪用这样劳民伤财啊！

从成本角度来思考，这种说法没错。但如果从架构角度来考虑，其实是得不偿失的。

如何在出现问题后最短的时间内就解决问题，保障系统的可用性，这才是第一考量指标。万一新主板的 RAID 方案偷偷参杂了私货呢？万一现场工程师不熟悉新主板的配置呢？万一负责人第一时间无法联系到呢？老话说“祸不单行”，就我过往的经验来说，基本上每次出问题时，一定会有意外。

RAID 0 是将数据原样记录在两块不同的物理磁盘上，因此虽然其写效率没有增加，但读效率提高到 200%。不过实际应用比较多的方案其实是 RAID 0+1，多块物理磁盘拼接成一大块逻辑磁盘(RAID 1)，然后再翻倍做数据冗余(RAID 0)。以最小要求 4 块硬盘来做成本评估，单硬盘的写效率只有 25%，读效率是 50%。以 8 块硬盘来评估，单硬盘的写效率仅 12.5%，读效率是 25%。

另一种方案 RAID5 就实惠得多，将数据分卷记录在全部物理磁盘上，其一是恢复卷，剩下的都是数据卷。WinRAR 的分卷可恢复压缩这是这个模式，不过究竟是谁借鉴了谁，我就没有研究了。其读写效率都是 N - 1 倍。因此使用 4 块硬盘时，单硬盘的读写效率都是 300%。8 块硬盘时，单硬盘的读写效率都是 700%。

但还需要注意，如果仅仅是文件小片段读写，RAID 5 还是只操作一块物理磁盘读写数据，因此其效率只有 100%。反而是 RAID 0+1 如果算法好，仍然会从配对的两块磁盘中读，因此效率是 200%。

稍微总结一下，RAID 0+1 适用于小文件或者文件小片段操作，RAID 5 更适用于大文件操作。各自适用场景不同，但都有用。

02

OverlayFS

到了系统层面，Linux 很早就在内核中正式加入了层叠文件系统。它可以将多个源目录层叠成新的目标目录，向最上级源目录写入，但读取操作会由上至下检索文件并返回第一个找到的结果。举个例子，就是 /a 和 /b 层叠为 /c，读取的是 /b/1 文件，但更新的是 /a/1，再次读取的也是 /a/1。

这个模型有什么用？先用类似的 LRU 缓存模型中的冷热概念辅助理解一下，再想像当要保障数据的可靠性时，再冷的数据都无法丢弃。我们其实需要三种分类：热数据、冷数据和持久化数据。即便同样都上 RAID5，不同分类的数据仍然可以使用不同媒质的物理磁盘记录，以合理的降低成本。比如热数据在 SSD 里，冷数据在 SSHD 里，持久化数据就用 HDD 得了。

再引申一点，配合 NatFS，我们似乎完全可以将持久化数据中心化存储，可以解决大量成本。再把冷数据用 HDD RAID 记录，合理的节省一点点也是好的嘛。

上面说了一堆，和数据可靠性或者读写性能有啥直接联系吗？嗯，不差钱的同学可以直接跳到下一章了——不就是 SSD 嘛，我们公司从来都是 1000 块、1000 块的买～

假定我们通篇下来存在感很弱的梨子新闻要在 16 台输入输出服务器中混合提供图片、音频和视频的输出。而且因为 App 设计得很神奇，用户都非常喜欢，所以已经攒了 8T 的数据。为了保障春节期间狂飙的存储量，得提前余量到 16T。怎么办？

最壕的做法，是批量采购 1T 容量的 SSD 在每台服务器上做 RAID 0+1，所以要采购 16 2 16 * 1.1 = 563 块。然后方案做出来交上去，下午就被请辞了…

最实惠的方案，是先用 500G 容量的 SSD 两块做 RAID 0，作为层叠的最上层，负责热数据的直接输出。然后是 9 块 2T 容量的 HDD 做 RAID 5，负责持久化数据的存储，通过 NatFS 挂载至服务器做层叠的最下层。即便考虑到容灾，做两套持久化存储，也只需要 18 块 HDD。这样的方案交上去，下次涨薪不能到天花板，你该自己请辞了～

硬件方案确定了，那么软件逻辑该怎么设计才能让 SSD 物尽其用呢？其实窗户纸一捅就穿——

1.读取文件 a 时，业务系统增加一个 a.r 的标记文件；

2.写入文件 b 时，业务系统再增加一个 b.w 的标记文件；

3.计划任务检查 *.r 标记文件，复制上层缺失的文件，并清理标记；

4.计划任务检查 *.w 标记文件，复制文件至下层，并清理标记。

两个计划任务的频率各自独立。如果后者足够快，那么基本上 SSD RAID 0 都用不上，还能再节约 16 块 SSD。项目奖金又能多一点，何乐而不为。

熟悉 Linux cron.d 的同学可能会问，最快也得一分钟啊！跑守护进程扫目录又会增加 I/O 压力，两难！这就需要下文的 INotify 出马了。

03

INotify

RSync

INotify 也是 Linux 很早就有的一个特性，用于播报文件系统的变更。我们这里所说的 INotify，其实是监听这类内核底层消息并输出排版信息的工具 inotifywait。

RSync 就不用多解释了。全能的复制工具，本地、远端随便按需同步，大家肯定都用过。

这套组合的目的，就是在某个数据文件发生变更时，立即将其同步复制到另一个地方，保护数据的安全。常见的 Shell 模板代码如下：

sh# 监听 $data 目录及子目录中发生的创建、改写和删除事件inotifywait -mrq --format '%f' -e create,close_write,delete $data |  while read file do # 计算目标文件路径 target=`echo $file | sed -e "s|$data|$vault|"` # 同步复制 rsync -az $file --delete $vault done

前文中提及的需求，是不是把模板改吧改吧就搞定了。皮实耐用。

说完安全接着说性能优化。有一个场景，几乎会出现在每一个系统中，其数据量不算大，但对同步的时效有一定的要求——输出结果的静态缓存。

如果大家对这个概念已经开始淡忘了，对于设计好 URL 的 GET 请求结果，我们可能会因为其低变更频度，直接静态化处理。这样在重复请求时，直接由 Nginx 处理，负载能力是等效于静态资源的。

如果不使用 INotify + RSync，则每台服务器会独立重复计算处理。但如果碰到某些计算耗时长，由计划任务定时处理，如何在多台服务器之间共享计算结果，还是会很麻烦。

而有了 INofity + RSync 之后，计算结果的复用率得到了进一步的提高。一套代码写完，每台服务器都部署上即可。需要考虑的问题，仅仅是如何避免多服务器之间无限循环同步的问题。不过 rsync -a 理论上就已经解决了这一问题，如果哪位同学在搭建测试模型时碰到了这一问题，记得先检查一下 RSync 的版本。

04

备份的可用性

上述三种方案，都是在数据同步方面做文章。但除了复制这一思路，还有些数据需要持久保存但很少使用，我们就需要选择合适的备份方案了。

需要同学们注意的是，很少使用并非意味着不使用，又或者不在乎使用耗时。这些都是完全不同意义的。所以我们在细说备份方法前，专门用一小节，来说说备份的可用性。

简单来说，就是在出现问题时，将一份备份恢复成生产数据所需要的处理时间。处理时间越短，那么该备份的可用性就越高。这就要求备份的数据格式和结构要尽量与生产数据的格式和结构保持一致。

因此，在做子系统或者模块的架构设计之初，如果涉及到数据备份和恢复，那么数据格式和结构的设计，就需要充分考虑备份和恢复的操作的便捷性。

与此同时，备份的生成、查询、恢复脚本也应该尽量在架构设计完成之前，模型搭建阶段就并行完成，充分验证其可行性。即使负责架构设计的同学再娴熟，最迟也需要纳入早期开发和自测任务之中，而不能等到系统提测之后再匆匆补工。否则一旦出现问题，返工量简直是灾难。

顺带一提，如无特殊情况，备份数据应该和生产数据保持在同一局域网内。原因嘛，大家看过上面的论述，都懂的。

05

增量备份

统一了对备份的可用性认知之后，我们就可以具体聊一聊备份的数据设计了。毫无疑问，除开数据库，由业务系统自定义格式和结构的数据的备份，一定是增量的。

增量数据能够最大程度的提高备份效率，也能顺便尽可能地节约存储空间。

这里就又要重提 OverlayFS 的优势了——上层即增量——充分利用系统内核特性，四两拨千斤啊！使用 OverlayFS 应该怎么备份？shell# 创建临时文件夹以供备份mkdir $tmp# 扫描上层(增量)目录find $src -type f > $tmp/.index# 复制原始文件for file in `cat $tmp/.index`do path=`sed -e "s|$src/||"` dir=`dirname $path` [ '.' == $dir ] || { # 按需在临时文件夹中创建子目录 mkdir -p $tmp$dir # 按需在下层文件夹中创建子目录 [ -d "$dest$dir" ] || mkdir -p $dest$dir } # 复制至临时文件夹 cp -a $file $tmp$path # 复制至下层文件夹 cp -a $tmp$path $dest$dir # 检查该文件是否发生过变更 newer=`find $file -newer $tmp$path` # 复制过程中文件未发生变化，使用下层文件夹中副本 [ $newer == $file ] || rm -f $filedone# 打包增量备份tar -C $tmp -cf - . | xz -9 > `date +'%y%m%dT%H%I%S'`.xz

如果非拧巴着不用 OverlayFS 来简化工作，又该怎么做增量备份呢？其实基本逻辑是相近的，只是就需要有一个上次备份扫描后文件路径列表来做排异了，使用 diff 指令可以很方便的搞定这个过程。具体的脚本代码就不写了，感兴趣的同学可以自己动手尝试一下。

至此，关于数据安全与备份的内容就基本聊完了。

关注微信公众号：安徽思恒信息科技有限公司,了解更多技术内容……