OceanBase
OceanBase
传统集中式数据库面临的挑战
架构
- 可扩展性方面:传统集中式数据库的扩展性有限,当数据量增加或者并发访问量增大时,集中式数据库可能无法提供足够的性能和吞吐量
- 单点故障:由于集中式数据库只有一个中心节点,一旦该节点发生故障,整个系统将无法正常工作。这种单点故障可能导致系统可用性和数据的丢失
- 单点上限:在一个数据库系统中,单个节点能够处理的最大负载或并发连接数。通常由硬件资源以及数据库软件本身的性能限制所决定的,
- 数据库安全:传统型集中式数据库存储所有数据的中心节点成为攻击者的目标,一旦该节点被入侵或者遭受到其他安全威胁,整个数据库的数据会面临泄露和篡改的风险
- 数据一致性:由于集中式数据库的数据存储都在一个节点上,当多个用户同时对数据库进行操作时,可能会出现数据一致性的问题。例如,当一个用户在修改某个数据时,另一个用户可能正在读取该数据,导致读取的数据不一致
- 高延迟:远程用户在访问数据库时,可能会出现高延迟,这对于要低延迟响应的应用场景是不可接受的。
数据库分布规则
- 是指分布式数据库系统中,决定怎么将数据分散到不同节点上,实现分布式存储和访问。
分片
- 将数据划分成多个片段,每个片段存储在不同的节点上。分片规则可以基于数据的某个属性进行划分,例如按照用户ID进行哈希分片或按照地理位置进行范围分片
复制
- 将数据复制到多个节点上以提高数据的可用性和容错性。复制规则可以确定数据的副本数量,复制的同步方式以及副本的位置选择策略
路由
- 根据查询或操作的条件将请求路由到正确的节点上。路由规则可以基于数据的分片键或其他属性进行路由决策的,以确保操作在正确的节点上执行。
数据迁移
- 在节点的增加,减少或数据重平衡时,如何将数据从一个节点迁移到另一个节点上,以保持数据的均衡和一致性。
中间件
- 使用通用数据库,可以实现数据库线性的扩容
- 数据库是单点数据库,数据库之间没有联系,不知道其他数据库的存在,依靠中间件完成需要跨库的事务
- 数据库中间件连接各个数据库,实现分库分表
需要注意的是单中间件整合各个数据库时候,倘若该数据库服务器时间戳不一致的时候可能会导致数据不一致的问题,可能在数据同步阶段的时候不同服务器操作时间戳或早或晚可能会被视为未来操作或者视为过时操作会丢失数据。
解决上面的问题,能够使用专门统一数据库服务器的时间的服务器或者建立时间戳校验机制,或者定期校准时间戳。
非短板
- 能过通过线性扩展来达到分库分表,可以快速实现数据库的水平扩展;
- 技术成本较低,不需要改造核心数据库引擎,或者只需要做很少的改造;
短板
- 跨库分布式事物,数据库核心引擎没有分布式能力,只能通过中间件来完成分布式处理,但中间件很难做到RPO = 0,因此在遇到异常和故障时无法100%保证分布式事务的ACID能力
- 全局一致性,由于多个数据库服务器的时间戳不一致,因此很难保证多个库之间数据版本号的全局性一致
- 负载均衡,在扩容和缩容时候,底层数据库引擎无法在线调整数据分布规则,因此需要暂停业务并重新导数据,对业务和运维挑战很大;
- 跨库复杂SQL,跨库的复杂SQL运算,只能要求中间件能够完成,而中间件不具备分布式并行计算能力,最终会限制应用对SQL的使用,产生业务侵入性。
原生的分布式关系型数据库架构
- 一种新型的数据库架构,能更好的处理大规模数据,并具有高并发,高可用,高扩展等特点。
数据高可靠,服务高可用
- 多副本一致性Paxos,个别节点发生故障时,保证数据零丢失和服务快速恢复。
Paxos协议
- 一种解决分布式系统中的一致性问题的协议,保证系统中多个副本在面对网络延迟,分区,信息丢失等问题时。
Prepare阶段
- Paxos提议者会向一组接受者发送一个提议,改提议包含一个提议编号和提议内容。
- 接受者会在接收到提议后,如果该提议的编号是其所接收过的所有提议中最大的,那么它就会接受这个提议,并将自己之前接受的最大编号的提议回复给提议者。
Accept阶段
- 议者会根据Prepare阶段的回复,选择一个提议内容,然后再次向接受者发送提议,该提议包含了在Prepare阶段中提出的提议编号和选定的提议内容。
- 接受者在接收到提议后,如果该提议的编号仍然是其所接收过的所有提议中最大的,那么它就会接受这个提议。
线性扩容
- 指随着硬件资源的增加,数据库的处理能力或存储能力能够线性增长。
- 线性扩容的好处是可以让系统在面对业务增长时,能够通过简单地扩展硬件资源来满足业务需求,而无需对系统的架构进行大的修改。
- 实现线性扩容,需要数据库系统具有良好的分布式架构,包括数据分片、负载均衡、分布式事务处理等能力。同时,也需要数据库系统能够有效地管理和调度各个节点的资源,以确保资源的充分利用。
全局一致性
- 支持分布式事务,确保全局一致性,无需使用高端小型机和存储
对业务透明
- 可以像使用单点数据库一样使用分布式数据库,业务迁移改造成本低。
核心部分
数据分片
分片策略
- 范围分片(按照某个字段)
- 哈希分片(通过哈希函数将数据均匀分布到各个节点)
- 列表分片(根据列表中定义的值将数据分布到各个节点)
分片键
- 分片键是确定数据分布到哪个分片的关键。通常,分片键应该选择能够使数据均匀分布到各个分片的字段
数据均匀分布
- 为了提高系统的性能和可用性,需要尽可能地使数据均匀分布到各个分片。如果数据在分片之间的分布不均匀,可能会导致某些节点过载,而其他节点闲置,这被称为”数据倾斜”
数据迁移
- 当添加或删除节点时,需要重新分配数据,这被称为数据迁移。数据迁移是一个复杂的过程,需要在保证数据完整性和服务可用性的同时进行。
分布式事务
- 支持分布式事务,保证数据的一致性,通常通过两阶段提交(2PC)或 三阶段提交(3PC)等协议来实现。
数据复制
- 为了提高数据的可用性和容错性,原生分布式关系型数据库会将数据复制到多个节点。如果某个节点发生故障,可以从其他节点获取数据。
负载均衡
- 原生分布式关系型数据库需要支持负载均衡,以保证系统的性能。这通常通过分布式哈希、一致性哈希等算法来实现。
故障恢复
- 在分布式系统中,节点故障是常见的问题。原生分布式关系型数据库需要支持故障恢复,以保证系统的持续运行。
弹性扩展
- 需要支持弹性扩展,即可以根据需要动态增加或减少节点。
OceanBase
简介
多种部署方式
集群
OceanBase是蚂蚁金服完全自主研发的通用的分布式关系型数据库。OceanBase以集群的形式存在,至少三个节点分布在三个区域(Zone),每个节点上运行一个单进程程序,进程名observer。每个observer进程都包含连个模块:SQL引擎和存储引擎,所以每个节点地位基本是平等的。稍微特殊的是每个Zone里会有一个节点的observer内还会运行总控服务,三个总控服务内容一样,角色上会有一个Leader和Follower,只有Leader提供服务。
OceanBase集群还支持多租户管理
RootService总控服务(RS)
分区
OceanBase的数据存在每个节点上,observer通过分区管理数据。分区是数据的子集,一个非分区就是一个分区,一个分区表包含多个分区,一个分区不能跨节点,分区表的不同分区可以跨节点。所以分区表可以做水平跨节点扩展。分区是数据的子集,是高可用的最小粒度。分析OceanBase是否丢数据,只要分析分区的数据写是否会丢。
读写模式
- OceanBase在初次读入一行数据时会将该行所在块读入到内存的Block Cache中,后面修改的时候并不是直接修改这个block,而是在另外一块内存中分配少量空间记录这笔修改,并且只记录变化部分,这称为增量数据(Memtable)。前面在Block Cache里的数据称为基线数据。同一记录如果反复修改多次,多个增量会议链表形式挂在该记录下
OceanBase的这种方式能够比传统数据库产生的脏块要小得多,所以OceanBase会把这些Memtable一直保存在缓存中或者推迟写入磁盘。当最后落盘的时候,Memtable会冻结成历史版本,然后和对应的基线数据在内存中进行合并,生成SSTable格式写入磁盘数据文件。合并的操作对资源有较大的影响,所以会在尽可能推迟合并操作到低峰期。若专门用户Memtable的内存利用率达到了一定的阈值,它会将Memtable直接以SSTable格式临时写入磁盘中。这就是转储的操作,相对对资源消耗比较小。
多个资源池(Resource Pool)
事务
OceanBase的Memtable一天只落盘一次,但是记录Memtable的时候OceanBase会遵循WAL机制,生成相关的事务日志保存在日志缓冲区里。和Oracle不同的是OceanBase的这些事务日志在事务提交之前会一直在日志缓冲区里,若节点宕机,没提交的事务日志对业务来说也没有数据丢失,当提交后,OceanBase会做事务日志的持久化动作。所以可能对于一些大事务会占用不少的内存空间。而且OceanBase是没有Undo,假设业务事务回滚了,它只会有一些清理逻辑。
宕机恢复
OceanBase的节点宕机后,节点上部分分区的访问会受影响,但OceanBase集群会很快恢复这些分区访问,这是OceanBase的可用性特性。和传统数据库一样,宕机后恢复,它会读取事务日志,重做事务,但在不同在于observer不需要再次读入基线数据,只需要在事务日志在增量内存中构建相关分区的Memtable。相关分区被业务读取时,对应的基线数据所在块才会被再次读入Block Cache中。
副本复制
- Oracle一样,光支持WAL是不足以保障数据安全,OceanBase还要设法保障事务日志的可靠性。除了使用DirectIO持久化到本节点磁盘外,也需要持久化到其他节点上。
- 跟传统关系数据库主备两副本架构不一样,OceanBase选择了多副本架构,是如果副本数是偶数,会有传统双机房容灾的脑裂问题。脑裂问题的本质就是全体成员在局部通信中断故障时无法就哪个节点接管服务作出一致性决议。成员数是奇数,才有可能形成多数派。
副本就是分区的别称,一个分区有三份数据,每份是一个副本。副本的内容除了数据还有事务日志。在这里我们只关心事务日志部分。三个副本在角色上是1个Leader(类似于主副本)2个Follower(类似于备副本)。只有Leader副本才会对外提供读写服务,这样就规避了单个分区多个节点同时写入的问题。但是注意每个分区只能单点写入跟OceanBase集群多个节点写入并不矛盾。因为Leader副本是可以分散到所有节点(OBServer)上。跟传统关系数据库一样,OceanBase维持三副本数据的同步是靠传输事务日志(Redo)机制实现的。
所以,为了保障事务日志的可靠性,OceanBase要把Leader副本上的事务日志持久化到本机和其他两个Follower副本上。宏观上表现就是可能存在各个节点彼此互相传输事务日志。这个跟MySQL的Master-Master架构里双向复制并不完全一样。 我们重点看看OceanBase如何认定事务日志可靠了。
使用Paxos协议,各个副本成员就事务日志持久化到磁盘进行表决。只要一半以上成员投票OK,Leader副本上的事务就可以继续提交了,Follower副本才开始应用Redo。这个协议是强制性约束,不够一半成员就会表决失败,Leader副本上事务就会回滚。这里没有类似Oracle或者MySQL的同步降级的做法。此外,剩余少数派成员最终也是要表决成功的,否则就是一个异常状态。
OceanBase会尽力自动去保障三副本成员状态的正常,否则就会告警等运维处理。这点也是强制性的约束,也是跟传统关系数据库不一样的地方。
核心特性
分布性
- 集群形式部署,支持水平扩展
- 在线扩容/缩容,自动负载均衡
- 跨机房/城市部署,容灾/多活
高可用
- 基于Paxos协议,强一致性同步
- 少数副本故障,数据不丢,服务自动回复
多租户
- 按需分配实例,即时创建和销毁
- 在线扩容/缩容
- 租户之间资源隔离
高兼容
- Oracle/MySQL两种兼容模式
- 数据平滑迁移
- 原生的SQL和事物引擎
集群技术架构
Paxos协议与负载均衡
分区
- 当一个表很大,能够水平拆分为若干分区,每个分区包含表的若干记录。根据行数据到分区的映射关系不同,分为hash分区,List分区,range分区
- 每个分区还能过通过不同维度再分,称为二级分区
- 分区是OceanBase数据架构的基本单元,传统数据库的分区表在分布式系统上实现
副本
- 为数据安全和高可用的数据服务,分区的数据在物理层面上会存储多份,每一份叫做分区的一个副本
- 副本根据负载和特定的策略,由系统自动调度分散在多个Server上。副本支持迁移,复制,增删,类型转换等管理操作
副本构成
副本构成由记录事务的日志,存储再内存的Memtable,磁盘上的静态数据SSTable
副本类型
- 一个分区在一个zone中最多由一个全功能或日志型副本
- 只读型副本在同一个zone可以有多个
全能型副本
拥有事务日志,MemTable和SSTable等全部完整的数据和功能,它可以随时快速切换为leader对外提供服务。日志型副本
只包含日志的副本,没有Memtable和SSTable。它参与日志投票并对外提供日志服务,可以参与其他副本的恢复,但子集不能变为主提供数据库服务。因为日志型副本所消耗的物理资源更少,它可以有效降低最后副本机器的成本,降低集群的总体成本只读型副本
包含完整的日志,MemTable和SSTable等,但是它的日志比较特殊。它不作为paxos成员参与日志的投票,而是作为一个观察者实时追赶paxos成员的日志,并在本地回放。可以在业务读取数据的一致性要求不高的时候,提供只读服务。因其不加入paxos成员组,又不会造成投票成员增加导致事务提交延时的增加
如上图,按照ID分为三个hash分区,每个分区再按照交易时间分为四个二级的range分区,然后会生成多份副本,副本数量会因集群数量而变化,一般来说会每个zone内只会包含一个副本
多副本一致性协议
以分区为单位组建Paxos协议组
每个分区都有多份副本(Replica),自动建立Paxos组,在分区级用多副本保证数据可靠性和服务高可用,数据管理更加灵活方便
自动选举主副本
OB自动生成多份副本,多副本自动选举主副本,主副本提供服务
自动负载均衡与智能路由
自动负载均衡
主副本均匀打散到各个服务器中,使得各个服务器都能承载业务流量
OB Server相互独立
每台OB Server均可以独立执行SQL,如果应用需要访问的数据不同机器上,OB Server自动将请求路由至数据所在机器,对业务完全透明。
多副本同步Redo Log 确保数据持久化
- Paxos组成员通过Redo-Log的多数派强同步确保数据的持久化
- Leader无需等待所有Follower的反馈,多数派完成同步即可向应用反馈成功
- 应用写数据到P2分区。Zone2-OB Server1的P2为主副本(Leader),承接业务需求。
- 将Redo-Log同步请求发送到Zone1-OB Server1和Zone3-OB Server1中的P2从副本(Follower);
- 任何一个Follower完成Redo-Log落盘并将响应返回给Leader后,Leader即认为Redo-Log完成强同步,无需再等待其他Follower的反馈;
- Leader反馈应用操作完成。
智能路由服务,应用透明访问
高效路由转发
- 对SQL做基本解析,确定对应Leader所在机器;
- 反向代理,将请求路由至对应Leader;Leader位置无法确定时随机选择OB Server;
- 轻量SQL解析 + 快速转发,保证高性能,单OB Proxy每秒转发百万次请求。
“非”计算节点,无状态
- 每个OB Proxy是一个“无状态”的服务进程,不做数据持久化,对部署位置无要求;
- OB Proxy不参与数据库引擎的计算任务,不参与事务处理;
- 多个OB Proxy之间无联系,可通过F5/SLB组成负载均衡集群;
- 不需要独立服务器,可以与OB Server共用一台服务器,如果应用对实时性要求高,也可以将OB Proxy部署到应用服务器中。
OB Proxy的故障是不会影响事务的功能,事务,持久化,落盘基本是由OB Server来完成。
设置Primary Zone,业务汇聚到特定Zone
通过为不同的租户配置不同的Primary Zone,可以将业务流量集中到若干Zone中,减少跨Zone以及服务器的操作。Zone List,逗号两侧优先级相同,分号左侧优先级高于右侧
Primary Zone有租户,数据库和表不同的级别。
- 如无特殊指定,自动继承上级对象的Primary_zone:database继承租户的primary_zone设置,table继承database的primary_zone设置。
- database和table可以指定各自的primary_zone,不必和上一级对象的设置保持一致;提供更加灵活的负载均衡策略。
Table Group,将多个表的相同分区ID的主副本聚集在一个OB Server中,减少分布式事务引入的开销
- 如果多个表的分区方式完全相同(分区类型,分区键个数,分区数量等),可以在逻辑上将这些表归属到同一个Table Group中,以影响动态负载均衡的策略
- 同一个Table Group中的所有表,分区ID(partition_id) 相同的所有分区,他们的leader在同一个observer上:在不影响全局负载均衡的前提下,可有效减少分布式事务引入的跨机访问开销。
- 如果负载均衡被打破(服务器故障后,扩容缩容等),Table Group中的所有表会作为一个整体来调整分区分布和Leader分布
- 动态创建和删除,并且对上层应用完全透明。
- 如果租户的unit_num=1 且 primary_zone只有一个zone,不需要tablegroup。
RDS实例,mysql扩容主备切换,ELR提前解行锁.。。。。。持续更新学习中………
OBCA模拟题库
【判断题】分库分表的架构虽然解决了集中式数据库的扩展性问题,但也带来了新的问题(不支持复杂SQL, 较难保证分布式事务的ACID等) 。T |