foundation部分学习记录(更正更新中……)
foundation部分学习记录(更新中……)
从FDB的角度看,它对上层只提供有序+事务+KV存储的抽象。
设计原则
- 模块化分割,尽量细分且模块之间相互解耦
例如事务系统内,其提交(write path)和读取(read path)是可以独立扩展的,系统中根据事务功能的不同,区分了很多角色(timestamp管理,冲突检测,提交的协调,logging..),每个角色也可以独立配置和扩展。而全局来看也把各个功能尽量拆分开来,减少耦合。
- 快速failure快速恢复
与一般的数据库系统不同,它处理各种类型的failure方式都一致,就是发现failure后重启整个事务系统,通过recovery机制来修复failure,因此必须做到快速检测和快速恢复才行。生产环境中从出现问题->发现->主动shutdown->recovery,一般在5s以内。
- 确定性模拟测试系统
提升质量,使得bug可被reproduce。
对外接口是典型的key/value(get/set/getrange..),事务机制是典型的OCC,开始时基于系统的快照做读取+修改,所有修改在client本地缓存,结束时带着read set/write set发起提交。由于需要缓存修改,系统对于Key/Value/事务的大小都是有限制的,这和client的缓存+in-memory的事务管理系统的缓存机制有关。
如上图所示,FDB 的架构中规中矩,大的模块可以分成三部分:
- 客户端接口 Client TTransaction
- 控制平面 Control Plane
- 数据平面 Data Plane
论文重点介绍的是 Control Plane 和 Data Plane。
Control Plane
Control Plane 负责管理集群的元数据,使用 Active Disk Paxos 来保证高可用。Control Plane 分成以下几个部分:
- Coordinator
几个 coordinator 进程组成一个 paxos group,其中有一个 leader,称为 cluster controller。
Cluster controller 负责故障检测,管理各种进程的角色,汇集、传递整个集群的各种信息。同时,cluster controller 是整个集群访问的入口点,controller会创建另外几个单实例进程。Client 通过一个保存有 coordinator 的 IP:Port 的配置文件访问集群,并从 cluster controller 获取最新的 proxy 列表。
- DataDistributor
DataDistributor 负责监控 StorageServer 的故障情况和数据的平衡调度。
- Ratekeeper
Ratekeeper 通过控制单调递增时间戳的分配速度来进行过载保护。
Data Plane
Data Plane 大体上可以划分成三大部分:
- Transaction System 负责实现 serializable snapshot isolation 级别的分布式事务,整个TS层是无状态的,便于发生failure时,快速整体重启。
- Log System 负责日志的复制,保证系统的高可用。
- Storage System 保存实际数据,或者说状态机,会从 Log System 异步拉取日志进行 apply。目前单机存储引擎是使用一个修改过的 SQLite。
其中事务管理系统(TS)负责写路径,storage系统(SS)负责读路径,是解耦的,可以各自独立扩展。
Transaction System 较为复杂,大体上可以分层三个模块:
- Proxy 作为事务系统面向 client 的代理接口,事务请求都需要通过 proxy 获取 read version,获取 key ranges 对应的 storage server 的信息,提交事务。
- Sequencer 负责分配递增的 read version 和 commit version。
- Resolver 负责 SSI 级别的事务冲突检测。
从上面的架构图可以看到,读写路径是分离的,TS层+LS层和write path相关,而SS层和read path相关。这是其设计的核心思想,将功能尽可能细分为不同role,由不同服务进程负责,不同role各自独立配置和扩展。例如如果想提高读吞吐,扩展storage server,如果想提高写吞吐,扩展Resolver/proxy/LS。
日志复制
日志复制是每个分布式数据库实现高可用所必须的。
FDB 有两种数据需要复制:Control Plane 的元数据和 Data Plane 的用户数据。
Control Plane 的元数据日志复制使用了 Active Disk Paxos(Paxos 的一个变种)。基于 Paxos 复制日志实现系统的高可用是常规的业界做法,也是不依赖外部仲裁实现高可用、强一致的标准方法。
Data Plane 采用了同步复制的方式——每次复制给 f + 1 个节点,只有 f +1 个节点都成功才返回成功。这种方式只需要 f + 1 个副本就可以容忍 f 个副本丢失,而采用 Paxos/Raft 进行复制的话,需要 2 * f + 1 个副本。
看起来,同步日志复制的成本比采用 Paxos/Raft 的方式要低许多,但是这里 Log System 的选主和故障恢复、故障转移应该是要严重依赖 cluster controller 的仲裁。并且任意一个副本故障都会导致写失败,如果采用 Paxos/Raft 的方式,只有 leader 故障才会导致写失败。另外,这里的 membership change 是怎么做的?这个估计要看看代码才清楚。这其中还有什么坑呢?估计要深度使用过后才清楚。
事务
Data Plane 的分布式事务是为典型的 OLTP 场景设计的——水平扩展、读多写少、小事务(5 秒)。FDB 通过 OCC +MVCC 来实现 SSI 的事务隔离级别。
一个事务的基本流程大概如下:
Client -> proxy -> sequencer 获取 read version。
Client with read version -> storage 根据 read version 读取数据快照。
写请求在提交前会先缓存在本地。
事务提交:
- Client 发送读集合和写集合给 proxy。
- Proxy 从 sequencer 获取 commit version。
- Proxy 将读集合和写集合发送给 resolver 进行事务冲突检测。
- 如果事务冲突,则 abort 掉。否则 proxy 发送写集合给 log server 进行持久化,完成事务的提交。
事务的执行流程,这里有几个关键的问题。
- 如何决定 read version?
- 如何进行事务冲突检测,以满足 SSI?
- 如何从故障中恢复?
如何决定 read version?
按照 SSI 事务的要求,通过 read version,必须能读到所有 commit version 小于等于 read version 的事务。对于已经提交的事务,这个问题不大。主要问题在于并发事务。
举个例子:
事务 A 和事务 B 是并发事务,A 获取 read vesion,准备读取数据;B 获取 commit version,准备提交事务。
如果 read version < commit version,事务 A 无论如何无法读到事务 B 的数据,所以没问题。
如果 read version >= commit version,事务 A 需要能够读取到事务 B 的数据,但是此时事务 B 可能还没提交…
如何解决这个问题呢?比较传统的做法是,commit 之前先对数据上锁,表示有 pending(待定) 的事务。读取的时候,需要检查数据有没有上锁,如果数据已经上锁,说明有事务正在写,则等待事务执行、或者推进事务 commit/abort、或者 abort 当前事务。
FDB 的做法是:从所有 proxy 收集最新最大的 commit version 作为 read version。而由于 commit version 的分配是全局单调递增的,所以可以保证,并发事务的 commit version 肯定大于 read version。
虽然从 proxy 收集 commit version 在实现上很容易做 batch 优化来提升性能,但是每次需要访问所有的 proxy,我对其扩展性和可用性保持怀疑。
如何从故障中恢复?
known committed version (KCV)
由于redo log apply是在后台持续进行的,因此本质上它将redo apply从recovery中解耦出来,等于持续在checkpointing,在recovery期间不需要做redo/undo apply,只是确认当前的log序列需要恢复到哪个位置即可!!后续基于log -> data的过程仍然是异步。这保证了recovery的速度。
具体流程:发现failure后,老Sequencer退出,新Sequencer启动,并从Coordinator获取老的TS的配置信息,包括老的LS的位置等,同时给Coordinator加个全局锁,避免并发recovery,然后关闭老的LS,禁止接收新的log写入,开始恢复,恢复完成后启动TS系统接收用户请求。
Proxy和Resolver都是stateless的,直接重启就可以,只有LogServer有log信息,恢复如下:
FDB 事务系统的核心进程是:Sequencer、Proxy、Resolver、LogServer,其中 Sequencer 是事务系统的“主控”:
- 如果 Sequencer 挂掉了,会有一个新的 Seqencer 被重新拉起来。
- 如果其它进程挂掉了,Sequencer 会自杀,然后会有一个新的 Seqencer 被重新拉起来。
新的 Sequencer 从 Coordinators 获取旧的事务系统的信息,包括所有的 Proxy、Resolver、LogServer,阻止它们处理新的事务。然后,重新组建新的事务系统(Proxy、Resolver、LogServer)。
事务系统恢复的时候,主要是要确定 LogServer 已经提交的最新的 log 的位置,论文中叫 Recovery Version,这个位置之前(包括这个位置)的日志已经提交,这个位置之后的日志可以直接忽略掉。
FDB 这种同步复制的方式,故障恢复其实很简单: 收集至少 m-k+1 个 LogServer 的最大持久化 LSN,然后取其中的最小即可。
- m 是 LogServer 的总数
- k 是日志同步复制的副本数。
FDB 的实现比上面这个方式稍微复杂一点,不过原理上是类似的。
FDB 只提供 get()、set()、getRange()、clear()、commit() 这几个简单的接口。FDB 认为自己实现了一个数据库的底层("lower half")—— 一个支持事务的分布式 KV。其他任何数据模型,比如关系模型、文档模型,都可以在这之上通过一层无状态的服务来实现。
基于一个单纯的分布式 KV 实现所有数据模型,这是一个很理想的架构,但现实可能没想象的好(主要是性能问题)。对这个话题感兴趣的,可以看看这篇文章:FOUNDATIONDB'S LESSON: A FAST KEY-VALUE STORE IS NOT ENOUGH。
FDB 给 C++ 做了扩展,增加了一些关键字用于“原生”支持异步编程,这套东西叫做 Flow。
工作流程:
可以看到FDB内部各个组件是有着相互的关联的:
Coordinator中存储着系统核心metadata,包括LS Server的配置,LS Server中则存储了Storage Server的配置。
运行中,Controller监控Sequencer,Sequencer监控Proxy / Resolver / LogSevers的状态。
bootstrap
系统启动时,Coordinator会选举出Controller,后者启动Sequencer,Sequencer则启动另外3组进程,然后从Coordinator中获取老的LS的配置,并从老的LS中获取SS的配置,利用老的LS执行必要的recovery过程,完成后老的TS系统就可以退休了,新的LS的信息写入Coordinator中,系统完成启动,开始对外提供服务。
reconfiguration
当TS系统发生failure或者配置变化时,Sequencer检测到后会主动shutdown,Controller检测到后会重启新的Sequencer从而形成新的TS,新的Sequencer会阻止老的TS再提供服务,然后走和bootstrap类似的recovery流程即可。
为了标识不同的TS系统,引入了epoch的概念,任何时候新老TS交替,epoch就要+1。
foundation部分学习记录(更正更新中……)的更多相关文章
- CLR via C# 第五章学习记录(更新中)
1.设置全局溢出检查,项目属性->生成->高级->检测运算上溢/下溢 2.局部使用溢出检测 Byte b = ; b = ));// 不检测溢出 checked// 检测溢出代码段 ...
- Pig基础学习【持续更新中】
*本文参考了Pig官方文档以及已有的一些博客,并加上了自己的一些知识性的理解.目前正在持续更新中.* Pig作为一种处理大规模数据的高级查询语言,底层是转换成MapReduce实现的,可以作为MapR ...
- git学习——记录每次更新到仓库
记录每次更新到仓库 工作目录下面的所有文件都不外乎这两种状态:已跟踪或未跟踪.已跟踪的文件是指本来就被纳入版本控制管理的文件,在上次快照中有它们的记录,工作一段时间后,它们的状态可能是未更新,已修改或 ...
- 保姆级尚硅谷SpringCloud学习笔记(更新中)
目录 前言 正文内容 001_课程说明 002_零基础微服务架构理论入门 微服务优缺点[^1] SpringCloud与微服务的关系 SpringCloud技术栈 003_第二季Boot和Cloud版 ...
- Redis学习记录之Java中的初步使用
1.关于Redis redis下载地址:<span style="font-family: Arial, Helvetica, sans-serif;">http:// ...
- C# 知识点记录(持续更新中)
从看C#入门经典开始系统的学习C#,本文主要记录学习过程中的一些知识点,也是我博客生涯的开始,比较重要成体系的部分会单重新写文章整理归纳. 1.一字不变的字符串 @字符 使转义序列不被处理,按照原样输 ...
- [Hadoop] Hadoop学习历程 [持续更新中…]
1. Hadoop FS Shell Hadoop之所以可以实现分布式计算,主要的原因之一是因为其背后的分布式文件系统(HDFS).所以,对于Hadoop的文件操作需要有一套全新的shell指令来完成 ...
- AIX学习笔记(更新中)
AIX操作系统基本命令 系统的进入和退出login: 输入用户名(例如:user01)password: 输入用户口令若用户名及口令均正确,则用户将登陆成功.此时系统会出现命令提示符 $或#,即表示可 ...
- c#个人记录常用方法(更新中)
1.日期毫秒转换为标准的C#日期格式 //使用时,先将秒Convert.ToInt64,返回格式2015-2-10 14:03:33 public DateTime JavaTimeToC(long ...
- KISSY学习笔记(更新中)
序:身为一个JAVA开发工程师,前端代码我尽量是使用原生的JS来写的,或是使用一些JQ的开源组件(但是也只是使用,没有好好去研究过JQ这个框架).目前由于工作需要,必须要使用KISSY,打算借此机会, ...
随机推荐
- .NET Core(C#) PadLeft和PadRight特定格式字符串长度补齐的方法和js中如何填充字符串
.NET Core(C#) 1、PadLeft和PadRight使用说明 两个方法都是对字符串格式化进行补齐填充,PadLeft是左边,而PadRight是右边 '1010'.PadLeft(10,' ...
- ABP 领域服务层学习记录
在ABP框架中有一个约定,所有的领域服务都应该继承并实现IDomainService接口,在领域层Core创建某一个实体的领域服务类,继承并实现IDomainService接口.在ABP框架中,领域服 ...
- 在cmd(命令行)或bat文件切换盘符
bat文件 写一个自动更新git的bat文件,如果bat文件放在E盘,想要去到D盘的某个目录下执行命令,代码如下: SET ksf=D:\code\KSFramework @echo on d: cd ...
- 【一】AI Studio 项目详解【(一)VisualDL工具、环境使用说明、脚本任务、图形化任务、在线部署及预测】PARL
相关文章 [一]-环境配置+python入门教学 [二]-Parl基础命令 [三]-Notebook.&pdb.ipdb 调试 [四]-强化学习入门简介 [五]-Sarsa&Qlear ...
- centos多网卡时修改网卡的优先级
我有个服务器有多个网卡,分别配置了多个网段的IP地址,发现有一个网段ping不通.最后发现是路由优先级的问题. 查看路由 查看本机路由route主要看Metric的值,值越小表示优先级越高,取值范围1 ...
- 手撕红黑树 | 变色+旋转你真的明白了吗?【超用心超详细图文解释 | 一篇学会Red_Black_Tree】
说在前面 我们也很久没有更新数据结构系列了,半年前博主重新深入学习了红黑树这个数据结构,一直想更新呈现给大家,最近也一直没有时间,今天红黑树它来了! 博主为了这篇博客,做了很多准备,试了很多画图软件, ...
- 在K8S中,集群可以做哪些优化?
在Kubernetes(简称K8s)集群中,可以进行多种优化以提升性能.稳定性和资源利用率.以下是一些常见的优化措施: 控制面组件优化: kube-apiserver 高可用与扩展:通过配置多个API ...
- Delphi Vista,Win7,Win8 的 Uac,管理员身份运行
要用就用下面我自己总结的官方的做法: 1.首先搜到delphi 自带的manifest,然后在其基础上改一个单词 2.将里面的asInvoker改为requireAdministrator 3.修改为 ...
- .NET 云原生架构师训练营(模块二 基础巩固 依赖注入)--学习笔记
2.2.1 核心模块--依赖注入 什么是依赖注入 .NET Core DI 生命周期 服务设计 服务范围检查 ASP.NET Core 依赖注入:https://docs.microsoft.com/ ...
- 从零开始的微信小程序入门教程(三),有趣且好玩的数据绑定
壹 ❀ 引 我在从零开始的微信小程序入门教程(二),初识WXML与WXSS一文中简单介绍了小程序组件与小程序样式相关概念,在了解这两者之后,其实我们已经可以搭建出简单的静态页面,与书写HTML页面一样 ...