Atlas：百度Key-value云数据存储系统设计揭秘

MSST 2015的论文(论文在这里）介绍百度云使用的key-value存储系统atlas的设计，思路相当赞。简单总结一下，建议想深入学习的同学直接阅读论文。

存储场景

百度云94%的文件在[128KB-256KB]之间，所以atlas主要针对小文件存储

百度云前面有CDN，到达atlas的请求基本都是随机访问，atlas是随机访问的存储引擎，不支持range操作

总体架构

atlas主要由PIS和RBS两个部分组成，下面将分别介绍

PIS存储接口

atlas的PIS模块(patch and index slice)直接面向用户，与其他KV存储引擎类似，暴露put/get/delete接口，不同的是atlas的key是规定长度128字节的GUID。

PIS以slot(slice)为单位进行数据管理，用户的key-value会分散存储到多个slot里，put时atlas的客户端会根据key计算hash，并对slot数量取模，将key路由至某个slot，每个slot单独进行数据管理。

PIS的primary副本接收到用户的put请求，会将请求转发至多个secondary副本，每个副本都将value追加至本地patch(类似于log文件)，并记录key的value在patch里的位置信息(offset、length)，当patch到达64MB时，patch将不再写入数据，PIS会产生一个新的patch文件用于写，同时会将写满的patch以block的形式存储到RBS里，patch存储至RBS时，RBS会分配一个唯一的blockid，此时PIS将key==>(blockid、length、offset)的映射关系写入index模块(一个类似于 google leveldb的系统)。

PIS接收到get请求时，首先在patch里查找key是否存储，如果存在则直接从patch读取value，返回给用户;如果key在 patch里不存在，则在index里查找，如果index里未找到，则说明atlas并没有存储这个key;如果在index里找到，则根据(blockid、length、offset)从RBS里读取value，返回给用户。

PIS处理delete请求与leveldb类似，会新写入一条该key的记录，标示为key已删除。

RBS接口

RBS(raid-like block storage)提供block的读写删接口，block长度固定为64MB，RBS里block只能整个写入和删除，但支持部分读取。

RBS包含一个中心管理节点(master-slave结构)，以及一组存储节点(part-server)，写入block时，RBS不再使用传统的多副本来保证数据可靠性，而是通过erasure-code来保证，极大的节省存储成本。

64MB的block会被RBS的客户端切分成8个8MB的part，通过8+4的erasure code计算出4个4MB的part，总共12个part;写入时，首先从中心节点请求分配一个唯一的blockid，同时分配12个 part-server用于写入12个part(实际上给了15个part-server信息，3个是备用的，如果存储12个part时，有某些part 存储失败，直接使用备用的part-server，而不用重新向中心节点发送新的请求，减少了与中心节点的交互次数);当12个part存储成功后，将 part与part-server的对应关系更新至中心节点。

当需要访问某个block时，RBS客户端向从中心管理节点查询block所在的part-server，然后从part-server读取数据;如果读取的part-server当时处于故障状态，会读取block内其他至少8个part，来恢复该part-server里的数据。

删除空间回收