存储系统这个话题太大，所以有很多聊的空间。不过这里篇幅有小，所以只能简单聊聊自己的一些体会，希望能给初入门径的技术同学一些帮助。如果看了觉得无味，不过瘾，可以加我泡泡，我们喝咖啡慢慢谈。

我把这篇小文章分成2个部分，第一部分是一些存储学习相关方面的误区，我遇到过的很多人都有类似的错误认识，所以我觉得有必要特别说明；第二部分是我在系统设计上的一些观点与经验，供参考。

第一个部分：细节，实现！

有一次跟领导出差，领导说现在的存储系统架构上已经做不出啥花样了，实现的细节更为重要。我深以为然。

云计算，大数据等名词的流行，给云存储方向带来了许多喜欢高屋建瓴，夸夸其谈，热衷宏大叙事的存储系统架构师。他们在外面分享浮躁，也把很多新同学带入了误区：过度关注系统架构，而忽视落到实地的能力。我比较喜欢跟人聊天，接触的同学多 ，所以对这个感触也更深一些。

作为一个有理想和尊严的存储工程师，第一件事情要做的就是沉静下来，然后：

1.     弄明白ppt上看到的每个词，paxos, zookeeper, HDFS, SAN, RAID;

2.     学好C语言，阅读Linux Kernel存储相关代码，读完整ext4;

3.     根据VFS接口，实现个基础的文件系统；

4.     详细了解ZFS, Lustre, Ceph等成熟的并行/分布式文件系统；

5.     要明白工程师是通过阅读代码而不是PPT来熟悉一个系统的；

6.     要明白对于一个存储系统而言，细节考量，系统实现的能力比宏大的架构更有价值（看过几个PPT，听过几次分享的外行做出来的存储系统架构也照样看起来有模有样，当然没法深究）；

7.     代码我有，天下我走。

 

第二个部分：经验分享

弱弱的说句，存储方面我不是啥高人；好在我完成了第一部分的7点要求，也在公司参与设计，开发了多个存储系统，因此也有一些经验可以分享。

分布式存储系统，影响的指标有很多，我罗列了下，大概主要有：数据丢失风险，系统可用性，物理设备故障恢复速度，系统冗余度（成本角度），读写性能，系统流量，数据均衡....

影响指标很多，不同的应用场景对各个指标的要求都各不相同。系统设计，有一部分是对这些参数的trade-off，比如我可用性要能到多少，读写性能要能到多少，等等。trade-off听起来很纠结，很考量一个人的能力，很多人因此把他称为艺术。其实我想说的是，trade-off是整个系统设计里最简单，最没有技术含量，最可以拍脑袋的地方。而大家又容易把这个trade-off看成是系统架构的全部，所以我在前面说，很多时候，我们对系统架构的理解有误区。

定下性能指标后（也就是拍完脑袋后），我们可以做一些落地的架构工作了。

• 数据丢失风险以及数据一致性问题
• 我们主要通过数据的冗余来降低数据的丢失风险。比如HDFS里常采用的3副本冗余，NDFS才有的双副本冗余，RAID各个层次的冗余。基本思想很简单，狡兔三窟，这个硬盘坏了，数据另一个硬盘还有。数据冗余，看起来简单，但在分布式系统下一旦引入，就会引发各种问题。最为严重的是存储成本剧增，次要严重的是数据一致性问题。在坑爹的IP网络以及槽糕的硬件环境下，我们的任意一个读写请求都有很大的概率失败。失败后就需要考虑多个副本上数据的一致性问题；
• 有的系统通过写入数据后只读的方式来应对一致性问题（对应用场景有严格限制）；
• 有的系统通过记录journal+后台程序维护的方式来应对一致性问题；
• 有的系统通过写入副本只读+GC+Rewrite来处理一致性问题；
• Erasure Coding
• 这只是数据的一种冗余方式，但是它实在太重要了，所以单独拿出来说，EC模式下，我们可以任意条件数据副本数量与校验副本数量。比如我们可以拿12块硬盘来组成一个EC的阵列。拿其中的8个盘放数据，另外4个盘放校验码，这样，我们只有同时损坏5个盘才有可能丢失数据！
• EC是兼顾成本与数据安全性两个维度上一个很合适的落地方法。
• EC基本算法很容易理解，但是实现会有麻烦。因为核心算法是解N元1次方程，性能上没法接受在计算校验/恢复数据的时候要使用乘除等算式。我们在一个实验性的系统上实现了不依赖乘除的基于Erasure Coding的冗余策略（需要利用到数论的一些结论来快速解矩阵方程，在介绍EC的经典论文里都有详细的描述）。另外，我们部门跟intel有签署Erasure Coding基础库相关的合作协议，有intel提供的性能极其强大的现成的库可以使用。有需要的同学可以跟我联系。
• 传统Reed-Solomon算法引发的数据恢复时流量风暴目前也有靠谱的解决方案，大家Google EC LRC即可。
• 对于在乎成本的大规模数据存储，我十分推荐使用EC。
• 物理设备故障恢复速度
• 这又是一个很庞大的话题。我们传统的RAID的数据恢复相当慢——一方面是要留出一部分磁盘IO供外部使用，另一方面磁盘对拷也是分布式系统下最不经济的数据恢复方案。
• 在大系统下，磁盘的故障是常态，可能每天都要换个5块，6块的。一个大容量的物理硬盘损坏，上面的数据在越短的时间内恢复，越安全，比如，4个小时内恢复完毕。分布式系统下，有个基本的原则就是当一个物理磁盘故障时，参与数据恢复的磁盘越多，那么恢复速度就越快——并发恢复。
• 如果让参与恢复的磁盘多，基本的策略就是数据足够的分散（会引发另一个大问题，这里先不谈）。当一个磁盘上的数据来源无五湖四海时，它故障时，五湖四海的磁盘就同时恢复。速度快那是自然的事情。
• 数据均衡
• 很多大规模分布式系统，都会有数据均衡的能力。
• 当整个集群，容量快满的时候，突然采购进来500T的空间，这个时候，需要对整个系统做Rebalance。把老数据仍到新磁盘来，用于保证整个系统的每个磁盘，都有点空余量，而不是系统中大部分磁盘完全写满，新磁盘完全没数据。
• 为什么要怎么麻烦？
• 分布式系统的性能与优势很多时候来自于分布式三个字，而如果没有Rebalance，我们的每一次扩容，其实是在人为的割裂整个分布式系统。这种情况下，我们拥有的其实是N个小系统连接起来而形成的一个大系统，而不是一个完整的分布式系统。
• 可能不好理解，我简单举个例子：我们有20P的一个系统，容量快满了。这个系统我们很满意，数据足够分散，每次数据恢复，读取，依赖于庞大的分布式集群，都能迅速完成。当我们需要扩容时，我们采购了1P的新空间，这样我们就有了1个21P的大系统。但是，因为原有的20P已经满了，所以所有的新写入的数据，都到了这个1P的节点中去，这些新数据完全跟原有的就系统没有关系。在这种情况下，其实我们有用的是1个20P的大集群和1个1P的小集群，而不是21P的一个有机整体。

不知不觉的说了太多，我就此打住，如果有同学对这个话题有兴致，就如开头说的那样，喝杯咖啡当面细聊。 

 

本文来自网易实践者社区，经作者陈炬授权发布。