提高基于文件系统的存储效率的考虑

很久没写博客了，今天突然有空想写点什么了，想来想去最近也就是这个可以写了。

首先我们需要明白这篇博客的适用场景：对于以B为单位短消息频繁落盘，文件落盘时间关乎系统的运行效率。

消息落盘指的是数据从内存写入物理磁盘上，数据在内存中存取效率速度比写盘快N多倍，如果我们需要优化存储模型，我们就应该在内存数据运行和写盘的差异时间上着手。

写磁盘为什么会慢？这是因为一般机械硬盘还是使用磁头读写，我们需要存取一个或者一段数据，那么我们需要先将磁头移动到数据所在的磁道上，然后磁盘经过旋转，磁头落在数据的开始位置，最后完成读写。这个模型就表明整个数据读写存在3个瓶颈，  1 寻道时间（磁头偏移到对应磁道上） 2旋转延迟（磁头旋转到数据的开始位置，一般使用磁盘旋转半圈的时间作为平均旋转延迟作为标准） 3读写时间

关于磁盘还有几个概念需要了解1inode节点（这个是linux中文件元信息，windows中也有对应的文件头，这个用来标注文件大小，文件名等信息，我们实际写文件的时候需要先修改inode节点），2吞吐量（磁盘连续读写的速度，比如读取500Mb/S等）3 IOPS  （每秒随机读写的次数，比如IOPS 500 就表明磁盘可以每秒进行500次IO操纵- 寻道开始到数据存取一块数据完成结束）

吞吐量主要评价的是磁盘存取连续文件的能力，主要的耗时在于读写时间，而IPOS主要评价的是磁盘存取碎片化文件的能力，主要耗时在于寻道时间和旋转延迟。知道的了这些概念，我们就可以得到相应的优化方向

1 协调吞吐量与IOPS的差异，充分利用每次磁头寻道时间

    - 先申请一块足够大的空间来提供读写，一次划来的存储空间最有可能是连续空间，也不需要磁盘进行优化调整    

    - 提高每次IO落盘或读取的数据量

由于是短消息，所以我们不可能针对每个短消息进行落盘，我们需要聚集足够多的短消息然后进行落盘，这相当于对于筛减了一遍落盘的信号，（这个在异步刷新页面的时候也有体现，比如我最近在做的客户端，设计到上传的时候页面需要刷新回显，如果我们针对短文件上传完成就刷新，那么会存在页面狂闪烁的现象，于是我采用了使用信号量加守护线程的方式，实现最后页面至多一秒钟刷新一次），但是聚集消息就代表了我们线程需要等待，那么就代表了消息消费的时间会增长，那么这里要做超时处理与性能权衡，我们需要根据系统模型调整这个数据聚集的块的大小，保证足够多的线程能复用一个IO并且不影响本身的操作，如果限定时间内收集不到足够多的消息，我们就需要强制写盘，那么就得到第二个优化点

2使用消息等待队列来缓冲落盘消息，促使足够多的消息复用一次IO

- 需要考虑一次聚集多少消息

- 需要做聚集超时和消息超时的处理

剩下一个和存储无关，但是还是能提高系统性能

我们知道在生产线模型出来之前正常的工作流程都是一个人负责一个产品的整个生命周期，而这种生产模式在面临大规模生产时存在性能瓶颈，员工在切换任务的时间损失和熟练度损失，而生产线就是讲工作流程拆解，让每个部分负责一部分职责，每个部分只需要重复做一件事，并且部分任务可以并发的执行，这个在现实中对应的模型是在商品出库的时候我们可以在办理手续的时候派人去清点商品准备出库，只要手续完成，商品便可以直接拖走。在程序中对应的模型是线程的fork && join模型，我们可以抽解出一部分可以并发执行工作流，让他们复用处理时间

3采用fork&&join模型 复用处理时间