BlueStore源码分析之架构设计

最新推荐文章于 2023-10-07 16:17:20 发布

「已注销」

最新推荐文章于 2023-10-07 16:17:20 发布

阅读量238

点赞数

文章标签： java 分布式 python 缓存数据库

本文链接：https://blog.youkuaiyun.com/didi_cloud/article/details/112006327

版权

本文详细介绍了Ceph BlueStore的架构设计，包括其设计理念、整体架构、核心模块如BlockDevice、RocksDB、BlueFS、Allocator和FreeListManager。BlueStore为提高性能，采用绕过文件系统的直接IO操作，利用日志文件系统确保数据一致性，并通过不同的磁盘分配策略处理不同类型的写操作。文章还提及了缓存管理以及读写流程，为深入理解Ceph存储引擎的运作提供了基础。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言

Ceph早期的单机对象存储引擎是FileStore，为了维护数据的一致性，写入之前数据会先写Journal，然后再写到文件系统，会有一倍的写放大，而同时现在的文件系统一般都是日志型文件系统(ext系列、xfs)，文件系统本身为了数据的一致性，也会写Journal，此时便相当于维护了两份Journal；另外FileStore是针对HDD的，并没有对SSD作优化，随着SSD的普及，针对SSD优化的单机对象存储也被提上了日程，BlueStore便由此应运而出。

BlueStore最早在Jewel版本中引入，用于在SSD上替代传统的FileStore。作为新一代的高性能对象存储后端，BlueStore在设计中便充分考虑了对SSD以及NVME的适配。针对FileStore的缺陷，BlueStore选择绕过文件系统，直接接管裸设备，直接进行对象数据IO操作，同时元数据存放在RocksDB，大大缩短了整个对象存储的IO路径。BlueStore可以理解为一个支持ACID事物型的本地日志文件系统。

设计理念

存储系统中，数据的可靠性是至关重要的。所有的读操作都是同步的，也就是除非命中缓存，否则必须从磁盘上读到指定的数据才能返回。但是写操作则不一样，一般为了性能考虑，所有写操作都会先写内存缓存Page-Cache便返回客户端成功，然后由文件系统批量刷盘。但是内存是易失性存储介质，掉电后数据便会丢失，所以为了数据可靠性，我们不能这么做。

一种可行的替代方案便是将数据先写入性能更好的非易失性存储介质(SSD、NVME等)充当的中间设备，然后再将数据写入内存缓存，便可以直接返回客户端成功，等到数据写入到普通磁盘的时候再释放中间设备对应的空间。写入中间设备的过程我们称为写日志Journal。如果写