[设计]首次揭秘，面向核心业务的全闪分布式存储架构设计与实践( 三 ) |固态硬盘|云计算|大数据|

NeonSAN 的数据写入是三个副本同时写入，保证数据间的强一致性，数据的读取是从主副本读的。数据的副本可以按卷进行灵活的配置，在一个集群中既可以有单副本的卷，也可以有两副本的卷，还可以有三副本的卷。
NeonSAN 支持精简置备和全置备，一个集群可以同时存在精简置备的卷和全置备的卷。

本文插图
我们通过一个例子看看 NeonSAN 强一致性写过程中的 IO 路径。
首先，客户端发 IO 给三副本的主副本节点，当主副本节点收到 IO 请求后会同时做两件事：一是把 IO 请求发给它本地的 SSD ，同时也会把请求发给两个从副本，当两个从副本 IO 完成以及本地的 IO 也完成，就是三个 IO 同时完成后才会返回给客户端写成功，实现强一致三副本的写入。
NeonSAN 分布式全闪有哪些黑科技 NeonSAN 是一个面向全闪的分布式存储系统，针对全闪有哪些特殊的设计？

本文插图
首先，NeonSAN 采用了极短 IO 路径，这是可以提供卓越性能的根本。
NeonSAN 只要 3 步就可以完成一个 IO ，当客户端的 IO 发到存储节点后，存储软件做完处理后直接发给本地的 SSD 。
业界其他的分布式存储中，却要经历很多步骤：先经过存储软件的处理，再发给本地文件系统，还要写日志，某些系统还需要再经过缓存，最后才能落到 SSD ，这个 IO 路径是非常长的。（简单来说就是很慢）
NeonSAN 采用自研 SSD 管理模块，直接管理本地裸设备，不依赖本地的文件系统，不需要日志，也不需要 Cache ，极大精简了 IO 路径，从而让延迟减少到最低，接近于 SSD 延迟的量级。

本文插图
接下来讲讲 NeonSAN 并行流水线处理的设计。
传统机械盘只有 1 个队列，深度是 32 ， NVMe SSD 一般盘有 128 个队列，每个队列的深度是 128 ，还采用传统的软件设计，显然 NVMe 是处于饥饿的状态，无法发挥队列和深度优势。
NeonSAN 采用并行流水线，将 IO 进行拆分，拆分成接收、调度和落盘。
举个例子，在机械盘的年代超市只有 1 个收银台，只能排 1 队，但是到了 NVMe SSD 时代，超市有 128 个收银台，如果我们还排 1 队就对资源造成极大的浪费，所以需要采用多个 IO 队列并行 IO ，充分发挥 NVMe SSD 本身的性能，提升 SSD 的使用率。

本文插图
在微秒的 SSD 时代，操作系统逐渐暴露出一些问题，比如低效 CPU 核心调度和内存资源的竞争，以及调度时的切换等带来了巨大的延迟。
【[设计]首次揭秘，面向核心业务的全闪分布式存储架构设计与实践】在高并发的压力下，多核心 CPU 的竞争与不合理的调度成为性能的瓶颈。 NeonSAN 专门设计了资源调度引擎，避免由于调度问题和内存争抢问题带来的延迟开销。
首先，在网卡上我们分配专门的接收与解析 IO 流水线，针对 IO 调度流水线我们给它分配了独享的 CPU ，避免调度流水线来回切换产生不必要的上下文开销，做到专门的 CPU 服务专门的流水线。
在内存方面，在系统软件启动时一次申请所需内存，根据不同流水线需求的多少按需分配给接收与解析 IO 调度、数据落盘等流水线，避免在 IO 过程中频繁申请与释放，带来的访问页表、内存锁等额外开销及内存碎片问题。