在前一篇文章中，提到了GFS在2003年面临的问题：相比硬盘吞吐数据的速度，网络（百兆网卡）成为了吞吐的瓶颈。
瓶颈分析
先做一个计算，分析磁盘写入速度与网卡吞吐速度：
| 硬件 | 配置 | 吞吐量 |
|---|---|---|
| 机械硬盘 | 5400rpm | 60MB/s ~ 90MB/s |
| 全双工网卡 | 100Mbps | 12.5MB/s |
显然，网络是瓶颈。
假如让你设计，该怎么改进？
替换硬件行不行
首先想到的是换网卡，比如把百兆网卡换成千兆网卡。按照网络上的说法，实际速度能达到理论值的50%~80%。
- 成本高：专业网卡的成本高，配套的资源成本高，比如更高级的网线等。
- 不能彻底解决问题：理论上GFS是可以无限扩容的，当超出前兆网卡的极限后要怎么办？
既然硬件走不通，那就从软件设计上想办法。
改进思路
从结果上看，最终的效果如上图所示：
- chunk1 Primary 写入 chunk server1
- chunk1 Secondary 写入 chunk server2
- chunk1 Secondary 写入 chunk server3
把问题抽象一下。显然，可以看到上面的结果包含了两个类型的操作：
| 类型 | 操作 | 举例 |
|---|---|---|
| 控制 | 查询操作 | 客户端从master server确定需要写入的服务器 |
| 控制 | 确认具备写入条件 | 查询待写入数据的3台服务器是否已收到数据 |
| 控制 | 确认操作结果(一致性) | 确保按照指定的写入顺序，各服务器的数据写入成功 |
| 数据 | 文件操作 | Linux文件写磁盘 |
这里的改进思路是：
- 控制操作与数据操作分离。
- 网络传输由于带宽瓶颈，最好做到将带宽用满。通过软件实现数据的逐级分配。
第1点的好处是，充分利用分布式系统的并行优势。由于最终结果并不要求写入成功的顺序，因此可以根据实际的网络情况进行传输。比如节点最近优先。
第2点的好处是，将客户端原本需要多次传输的耗时，减少为1次传输。即充分利用了网卡的吞吐上限，又可以利用分布式计算的优势。
上面的图作为示例，展示了第2点的一种可能的情况。
总结
设计更多的要从工程性，结合当时的需求与瓶颈来思考。
- 节省简单
- 控制流与数据流分离
- 充分利用带宽
从某种程度上来看，GFS的设计与网络通信的分层类似。数据流作为底层，解决传输与效率。控制流作为上层，解决分布式的业务需求。
