《系统日报》持续关注分布式系统、AI System,数据库、存储、大数据等相关领域文章。每天以摘要的形式精选不超过三篇系统文章分享给大家。 如果你有好文章推荐,或者有其他任何想法,欢迎在 Articles Weekly Repo[1]提 issue。
来源:https://engineering.fb.com/2022/05/04/data-infrastructure/delta/
导读:偶然看到群里同学分享的 Meta 技术博客[2]新公开的高可用、强一致、链式复制的对象存储。由于我也做过一段时间的对象存储,也分享过 Facebook 家的小文件存储:Haystack[3](做 batch) 和 F4[4](冷热分开、EC), 顿时来了兴致,好奇这次 Meta 又带来了什么干货。
看完之后觉得的确有点意思,下面简单梳理下文章要点,感兴趣的同学可以去看看博客原文,还有华人小姐姐解说的相关视频哦。
Delta 是简单、可靠、可扩展、低依赖的对象存储,只提供四个基本操作:put、get、delete 和 list。在架构设计上,Delta 牺牲了读写延迟和存储效率,来换取架构的简单性和可靠性。
Delta 不是:
总结来说,定位是一个基座式存储服务,就是性能可以不高,但要简单、弹性、可靠。其定位坐标如下图:
Delta 产品定位的坐标
对于一个逻辑上的 Bucket(对象存储的命名空间)中的数据,首先使用一致性哈希进行分片(Partition),对于每个分片,使用链式复制(Chain Replication)进行冗余。通常每个分片有四个副本,每个副本放在不同的容错阈。
四个节点的副本链的读写
读写流程:所有的写入都在链表头,依照链表顺序复制后,等到链表尾复制完成后返回成功(同步复制);所有的读取都被路由到链表尾,以保证强一致。
可以看出,由于是同步写,Delta 的写入延迟比较高;由于是只读尾节点,读吞吐也不高。
当然,Delta 对读取稍稍做了个优化——分摊查询,即允许客户端读任何一个副本,但该副本必须要和尾节点通信确定数据可靠版本(clean version)后才能返回数据给客户端,以保证一致性。
多节点均摊读
其依据是,相比客户端查询,内部版本确认查询要轻量的多。
Delta 通过心跳和投票来剔除故障节点:即当同时有一定数量的节点标记某一个节点心跳超时后,就将该节点上所有副本从复制链中剔除。其中有两个阈值需要慎重选择:
在故障节点修复之后,可以通过一系列操作加回副本链:
故障副本的摘除与挂回
Delta 使用一个控制平面服务(CPS,control plane service)对故障节点进行自动检修。每个 CPS 实例监控一组 Delta Bucket 列表,其主要策略有:
解释下最后一条:即能修复先修复,只有坏到不能再坏(超过一半)才从池子中拨出一个副本给他,从而保证池子里有充足备用弹药。
文中还提到了全球地理复制和用归档服务进行冷备。并提到 Delta 下一步是想充当 Meta 中所有需要数据备份和恢复的服务的存储后端。