为什么Raid对于某些场景没有任何提速作用？

本文会是即将在年底前出版的下一本书中的一节，在这里先贴出了。该书中将会有更多深刻内容等待大家探索，敬请期待！

          一听说Raid，牛啊，既能提速又能冗余，堪称存储领域之航母，几乎所有存储系统底层都得加一层Raid。可是你知道么，Raid并不是在任何情况下都可以加速IO的。其中一种场景就是前文中介绍过的条带深度没有设置成与IO Size相同而导致的不能够并发IO，要么多笔IO都挤到同一块盘上串行处理，要么就是一笔IO被切分为多笔子IO而每一笔子IO都占用一块盘，导致多快盘服务于一个IO，严重浪费资源。有人可能会问，比如我把一笔128K的IO切分为4个32K的IO，让每个盘读写32K，4个盘一起不就可以提升吞吐量了么？要知道，不断对于顺序IO还是随机IO，这样做都不是好办法。比如有4笔128K的顺序IO排队，就算不切分，依然可以将条带深度设置为128K，而让4块盘同时执行者4笔128K的IO；而将条带深度设置为32K，让4块盘服务于一笔IO，该IO本身被多盘并发处理了，但是其后面排队的3笔IO依然在等待。最终这两种方式的吞吐量没有任何区别。

        对于随机IO，后面这种方式就开始有副作用了，因为其严重制约了IO的并发性，使得并发度降为1，也就是没有并发。看过前文中流水线理论的读者应该清楚，没有并发？简直搞笑了，吞吐量想上去基本不可能的。有人后续会问，虽然没有了并发，但是我每笔IO的执行时延下降了啊！哼哼，大错特错！冬瓜哥要给你当头一棒了。对于随机IO，每笔IO的时延等于什么？寻道时间+等待时间+读写时间啊！那么，机械磁盘寻道一笔32K的IO，和寻道一笔128K的IO，寻道时间有区别么？没有。等待时间有区别么？没有。读写处理时间有区别么？有！这个真的有！从磁盘读32K的数据耗时一定是128K耗时的四分之一啊，所以性能翻了4倍啊！你再说？！再来一棒子看你醒了没！寻道时间什么量级？10ms量级啊！等待时间什么量级？3ms量级啊！读写时间什么量级？这个，非常快，可以忽略不计的！额，好像明白了，读32K纵然要比读128K快4倍，但是相比寻道时间而言，这一点点提升根本是杯水车薪啊！比如10ms+3ms+0.1ms为一笔IO的时延，相比10ms+3ms+0.025ms，单笔IO在磁盘内处理的总时延几乎没变化。懂了！彻底的！还有人不懂么？还不懂的话来找冬瓜哥当面挨上几棒子就懂了。

        好，再次强调，条带深度一定要设置为上层下发的IO Size相等的值，要让多笔IO并发，而不是单笔IO被切分为多份而这多份之间并发。然而，本次的正题冬瓜哥还没进入呢，这就来了。

        还有一种场景，Raid根本起不到任何作用，反而徒增无畏的计算和元数据维护。那就是同步IO场景。什么叫同步IO，建议阅读本书其他文章。简单来讲同步IO就是应用发出一笔IO调用，仅当该IO的结果返回之后，其才会发送下一笔IO。这下惨了，咱们上文中说过，Raid之所以能够提速是因为其可以让多笔IO同时被多个盘分别执行，现在可好，上层每次只给一个IO，我咋个并发啊？有人说了，额，冬瓜哥，把这笔IO切分成多份，每个盘执行一份，不就可以并发了么？我……拿棒子来！谁以后再说把一笔IO切分多份，挨棒子数加倍！上文说了，不管顺序IO还是随机IO，一笔IO切分多份毫无用处，顺序IO这么干无影响，随机IO这么干适得其反。

        所以，遇到同步IO，就走霉运了！这个IO Size如果小于等于条带深度，那么其无论如何也必须最终落在某个盘上，那么其性能与单盘性能无差别。如果这个IO Size大于条带深度，那么Raid模块会将该IO拆分为多笔IO，向多个盘并行发送这些IO，很显然，最终该IO的性能还是单盘所体现出来的性能。哎，不对啊冬瓜哥，怎么会呢，把128K切分为4个32K，性能翻四倍啊！？我……走你的！

         咋办？如果我的应用很邪门，就是同步IO模式，没法改异步，而且就算改了异步模式，也并不是任何时间都发送异步IO的，有些场景必须同步IO，比如必须知道该IO的数据内容，判断之后，才能决定下一笔IO要读或者写哪个块。可以明确的讲，如果不换SSD的话，基本没办。不过可以让资源利用率提升一些，但是对应用的体验来讲，基本没招儿。怎么说？比如我同时运行多个应用，每个应用都发送同步IO，那么此时实际上并发度变成了4，Raid就会起到作用，但是这四个应用每一个的体验，与单盘没有任何差异。

         再结合上篇文章中对时延、并发度的分析，是不是理解又更加深刻了？此时你也许会体会到什么，没错，那就是为什么测试时性能吊炸天，上线却惨不忍睹？

相关文章：

《并发IO系统性能的根本》



Reward

people gave a reward