双11已圆满落幕，但技术的探索，仍未止步。
“阿里巴巴数据库技术” 特此推出《赢战2018双11——阿里数据库 & 存储技术揭秘》系列干货文章，为你讲述2135亿这个超级数字背后的故事，敬请关注！
导读：面对数据库实例和存储规模的不断增长，大促成本、调度效率等难题，2017年阿里就开始小范围应用新型技术架构——“存储计算分离”，以更低成本支撑弹性大促。
2018年，我们实现了全单元规模化部署存储计算分离。不过在此之前，各个业务都需要根据自身业务特性进行大量优化。数据库领域更是如此，而且要求更加苛刻，难度更大。阿里巴巴存储技术事业部高级技术专家吕健将详细解读在2018双11大促中，阿里如何打破存储与计算之间的技术壁垒，从而实现无需搬动数据即可灵活弹性扩容的技术突破。
一、2017年我们做了什么？
记得早在2017年的时候，王坚博士就曾号召大家就关于“IDC As a Computer”是否能做到，进行过激烈的讨论。而要做到此，必须要实现存储计算分离，分离后由调度对计算和存储资源进行独立自由调度。而在实现存储计算分离的所有业务中，数据库是最难的。因为数据库对I/O的时延和稳定性有着极高的要求。但是从业界来看，存储计算分离又是一个未来的技术趋势，因为像Google spanner以及Aurora都已经实现了。
所以2017年，我们抱着坚定的信念，去实现数据库的存储计算分离。事实上，2017年我们做到了，基于盘古和AliDFS(ceph分支) ，在张北单元存储计算分离承担10%的交易量。2017年是数据库实现存储计算分离的元年，为2018年大规模实现存储计算分离打下了坚实的基础。
二、2018技术突破
如果说2017年是数据库实现存储计算分离的突破之年的话，那么2018年就是追求极致性能的一年，也是由试验走向大规模部署的一年，其技术的挑战可想而知。在2017年的基础上，2018年的挑战更为巨大，需要让存储计算分离更加的高性能、普适、通用以及简单。
2018年，为了使得在存储计算分离下数据库的I/O达到最高性能和吞吐，我们自研了用户态集群文件系统DADI DBFS。我们通过将技术沉淀到DADI DBFS用户态集群文件上，赋能集团数据库交易全单元规模化存储计算分离。那么成为存储中台级产品，DBFS又做了那些技术上的创新呢？
2.1 用户态技术
2.1.1 “ZERO” copy
我们直接通过用户态，旁路kernel，实现I/O路径的“Zero”copy。避免了核内核外的copy，使得吞吐和性能都有了非常大的提高。
过去使用kernel态时，会有两次数据copy，一次由业务的用户态进程copy数据到核内，一次由核内copy到用户态网络转发进程。这两次copy会影响整体吞吐和时延。
切到纯用户态之后，我们使用polling模型进行I/O request请求的发送。另外对于polling mode下CPU的消耗，我们使用了adaptive sleep技术，使得空闲时，不会浪费core资源。
2.1.2 RDMA
另外，DBFS结合RDMA技术与盘古存储直接进行数据交换，达到接近于本地SSD的时延和更高的吞吐，从而使得今年跨网络的极低时延I/O成为可能，为大规模存储计算分离打下了坚强的基础。今年集团参加大促的RDMA集群，可以说是在规模上为业界最大的一个集群。
2.2 Page cache
为了实现buffer I/O的能力，我们单独实现了page cache。Page cahce采用touch count based LRU算法实现。引入touch count的意义是为了更好的与数据库的I/O特性结合。因为数据库中时常会有大表扫描等行为，我们不希望这种使用频率低的数据页冲刷掉LRU的效率。我们会基于touch count将page在hot端和cool端进行移动。
Page cache的页大小可配置，与数据库的页大小进行结合时，会发挥更好的cache效率。总体上DBFS的page cache具备以下的能力：
基于touch count进行page的冷热端迁移
冷热端比例可配置，目前为热冷比例为2:8
page size可配置，结合数据库页进行最优化配置
多shard，提高并发；总体容量可配置
2.3 异步I/O
为了提高数据库的I/O吞吐能力，大部分数据库都使用了异步I/O。我们为了兼容上层数据库的I/O特性，实现了异步I/O。异步I/O特性：
无锁队列实现
可配置的I/O depth，能够使得针对数据库不同的I/O类型进行精确时延控制
polling adaptive，减少CPU消耗
2.4 原子写
为了保证数据库页写出的时候不出现partial write，DBFS实现了原子写功能。基于DBFS的Innodb，可以安全的将double write buffer关掉，从而使得在存计分离下数据库带宽节省100%。
另外，如PostgreSQL使用的是buffer I/O，也避免了PG在dirty page flush时偶发性遇到的缺页问题。
2.5 Online Resize
为了避免扩容而带来的数据迁移，DBFS结合底层盘古实现volume的在线resize。DBFS有自己的bitmap allocator，用于实现底层存储空间的管理。我们对bitmap allocator进行了优化，在文件系统层级做到了lock free的resize，使得上层业务可以在任何时候进行对业务无损的高效扩容，完全优于传统的ext4文件系统。
Online Resize的支持，避免了存储空间的浪费，因为不用reserve如20%的存储空间了，可以做到随扩随写。
以下为扩容时的bitmap变化过程：
2.6 TCP与RDMA互切
RDMA在集团数据库大规模的引入使用也是一个非常大的风险点，DBFS与盘古一起实现了RDMA与TCP互切的功能，并在全链路过程中进行了互换演练，使得RDMA的风险在可控的范围内，稳定性保障更加完善。
另外，DBFS，盘古以及网络团队，针对RDMA进行了非常多的容量水位压测，故障演练等工作，为业界最大规模RDMA上线做了非常充足的准备。
2.7 2018年大促部署
在做到了技术上的突破和攻关后，DBFS最终完成艰巨的任务通过大促全链路的考验以及双“十一”大考，再次验证了存储计算分离的可行性和整体技术趋势。
三、存储中台利器DBFS
除了以上做为文件系统必须实现的功能以外，DBFS还实现了诸多的特性，使得业务使用DBFS更加的通用化，更加易用性，更加稳定以及安全。
3.1 技术沉淀与赋能
我们将所有的技术创新和功能以产品的形式沉淀在DBFS中，使得DBFS能够赋能更多的业务实现以用户态的形式访问不同的底层存储介质，赋能更多数据库实现存储计算分离。
3.1.1 POSIX兼容
目前为了支撑数据库业务，我们兼容了大多数常用的POSIX文件接口，以方便上层数据库业务的对接。另外也实现了page cache，异步I/O以及原子写等，为数据库业务提供丰富的I/O能力。另外，我们也实现了glibc的接口，用于支持文件流的操作和处理。这两种接口的支持，大大简化了数据库接入的复杂度，增加了DBFS易用性，使得DBFS可以支撑更多的数据库业务。
posix部分大家比较熟悉就不再列出，以下仅为部分glibc接口供参考：
// glibc interface
FILE *fopen(constchar*path,constchar*mode);
FILE *fdopen(int fildes,constchar*mode);
size_t fread(void*ptr, size_t size, size_t nmemb, FILE *stream);
size_t fwrite(constvoid*ptr, size_t size, size_t nmemb, FILE *stream);
intfflush(FILE *stream);
intfclose(FILE *stream);
intfileno(FILE *stream);
intfeof(FILE *stream);
intferror(FILE *stream);
voidclearerr(FILE *stream);
intfseeko(FILE *stream, off_t offset,int whence);
intfseek(FILE *stream,long offset,int whence);
off_t ftello(FILE *stream);
longftell(FILE *stream);
voidrewind(FILE *stream);
3.1.2 Fuse实现
另外，为了兼容Linux生态我们实现了fuse，打通VFS的交互。Fuse的引入使得用户在不考虑极致性能的情况下，可以不需要任何代码改动而接入DBFS，大大提高产品的易用性。另外，也大大方便了传统的运维操作。
3.1.3 服务化能力
DBFS自研了shmQ组件，基于内享内存的IPC通信，从而拉通了对于PostgreSQL基于进程架构和MySQL基于线程架构的支持，使得DBFS更加的通用化和安全，为以后在线升级提供坚实的基础。
shmQ基于无锁实现，性能和吞吐表现优异，从目前测试来看，在16K等数据库大页下能控制在几个us以内的访问时延。服务化以及多进程架构的支持，目前性能与稳定性符合预期。
3.1.4 集群文件系统
集群功能是DBFS的又一大明显特性，赋能数据库基于shared-disk模式，实现计算资源的线性扩展，为业务节省存储成本。另外，shared-disk的模式也为数据库提供了快速的弹性能力，也大大提高了主备快速切换的SLA。集群文件系统提供一写多读以及多点写入的能力，为数据库shared-disk和shared nothing架构打下坚实的基础。与传统的OCFS相比，我们在用户态实现，性能更好，更加自主可控。OCFS严重依赖于Linux的VFS，如没有独立的page cache等。
DBFS 支持一写多读模式时，提供多种角色可选(M/S)，可以存在一个M节点多个S节点使用共享数据，M 节点和S节点共同访问盘古数据。上层数据库对M／S节点进行了限制，M节点的数据访问是可读可写的，S节点的数据访问是只读的。如果主库发生故障，就会进行切换。主从切换步骤：
业务监控指标探测发现M 节点出现无法访问或者异常的时候，进行决策，是否要进行切换。
如果发生切换，由管控平台发起切换命令，切换命令完成，代表DBFS和上层数据库都已经完成角色切换。
在DBFS 切换的过程中，最主要的动作就是IO fence，禁止掉原本的M节点IO能力，防止双写情况。
DBFS在多点写入时，对所有节点进行全局的metalock控制，blockgroup allocation优化等。另外也会涉及到基于disk的quorum算法等，内容比较复杂，暂不做详细陈述。
3.2 软硬件结合
随着新存储介质的出现，数据库势必需要借其发挥更好的性能或者更低成本优化，并且做到对底层存储介质的自主可控。
从Intel对存储介质的规划来看，从性能到容量，会形成AEP,Optane和SSD这三种产品，而在向大容量方向上，又会有QLC的出现。所以综合性能和成本来看，我们觉得Optane是一个比较不错的cache产品。我们选择它作为DBFS 机头持久化filecache的实现。
3.2.1 持久化file cache
DBFS实现了基于Optane的local持久化cache功能，使得在存计分离下更近一步提升数据库的读写性能。File cache为了达到生产可用性，做了非常多的工作，如：
稳定可靠的故障处理
支持动态enable和disable
支持负载均衡
支持性能指标采集和展示
支持数据正确性scrub
这些功能的支撑，为线上稳定性打下坚实的基础。其中，针对Optane的I/O为SPDK的纯用户态技术，DBFS结合Fusion Engine的vhost实现。File Cache的页大小可以根据上层数据库的block大小进行最佳配置，以达到最好的效果。
以下为file cache的架构图：
以下是测试所得读写性能收益数据：
其中带有“cache”的为基于filecache所得。整体表现随着命中率提高，读时延开始下降。另外，我们针对file cache，进行了诸多性能指标的监控。
3.2.2 Open Channel SSD
X-Engine和DBFS以及Fusion Engine团队展开合作，基于object SSD进一步打造存储自主可控的系统。在降低SSD磨损，提高SSD吞吐，降低读写相互干扰等领域，进行了深度探索与实践，都取得了非常不错的效果。目前已经结合X-Engine的分层存储策略，打通了读写路径，我们期待下一步更加深入的智能化存储研发。
四、总结与展望
2018年DBFS已经大规模支持了X-DB以存储计算分离形态支持“11.11”大促；与此同时也赋能ADS实现一写多读能力以及Tair等。
在支持业务的同时，DBFS本身已经拉通了PG进程与MySQL线程架构的支持，打通了VFS接口，做到了与Linux生态的兼容，成为真正意义上的存储中台级产品——集群用户态文件系统。未来结合更多的软硬件结合、分层存储、NVMeoF等技术赋能更多的数据库，实现其更大的价值。
