本文只用作个人备考笔记用途，无商业用途，若有侵权，立即删除。
2分布式数据库与集中式数据库的差异.
2.1传统集中式数据库面临的挑战
- 传统数据库的优劣
- 优势：
- 成熟稳定:经过近40年的发展，应用到各行各业，产品技术非常成熟稳定；
- 行业适配性强:适配不同行业的各种需求；
- 生态完善:拥有大量的ISV应用开发商和技术开发者，技术生态、产业生态和人才生态都很完善；
- 劣势：
- 成本高:自身软件售价高，同时依托于高端硬件，CAPEX和OPEX成本高昂；
- 无法横向扩展:容量的提升只能依靠提升设备自身的性能(增加CPU/内存/硬盘，或从PC服务器升级为小型机等），一定能碰到单点的上限；
因此，传统数据库比较适合处理数据量和访问量都比较平稳、比较有限的场景，比较难应对数据量和访问量都快速增长的场景。
- 使用数据库中间件的分库分表方案依然有短板
- 优势：
- 线性扩展:通过分库分表，可以快速实现数据库的水平扩展；
- 技术成本低：不需要改造核心数据库引擎，或者只需要做很少的改造；
- 劣势：
- 跨库分布式事务:数据库核心引擎没有分布式能力，只能通过中间件来完成分布式处理，但中间件难以做到RPO=0,因此在遇到异常和故障时无法100%保证分布式事务的ACID能力;
- 全局一致性:由于多个数据库服务器的时间戳不一致,因此很难保证多个库之间数据版本号的全局一致性;
- 负载均衡:扩容和缩容时，底层数据库引擎无法在线调整数据分布规则,因此需要暂停业务并重新导数据，对业务和运维挑战很大;
- 跨库复杂SQL:跨库的复杂SQL运算(比如多表做分片键无关的关联查询)只能在中间件完成，而中间件不具备分布式并行计算能力,最终会限制应用对SQL的使用，产生业务侵入性。
2.2分布式数据库基本特点及对比分析
- 原生的分布式关系型数据库架构
优势：- 数据高可靠+服务高可用：多副本一致性协议Paxos的工业级实现，个别节点发生故障时保证数据零丢失（RPO=O）和服务快速恢复（RTO<30秒)。
- 线性扩容：随着业务量增加进行扩容（比如线上促销期间)，随着业务量减少进行缩容（比如促销后)。
- 低成本：基于普通X86服务器保证高可用性，无需使用高端小型机和存储。
- 全局一致性：支持分布式事务，确保全局一致性，支持分布式复杂查询。灵活的部署方式:支持三中心、五中心、主备等多种部署模式。
- 对业务透明：业务系统可以像使用单点数据库一样使用分布式数据库，业务迁移改造成本低。
- 小结
- 传统集中式数据库经过近40年的发展，已经非常成熟。但在当前这个大数据的时代，传统数据库依然面临较多挑战，分布式数据库可以有效解决这些问题，是未来数据库发展的重点方向
- 传统数据库往往对硬件基础设施有较高要求，同时只能纵向扩展，无法横向扩展，容易达到性能上限；
- 分库分表虽然可以横向扩展了，但也有带来了不支持复杂SQL、较难保证分布式事务的ACID等新问题；
- 分布式数据库可以有效解决这些问题，应用可以像使用集中式数据库一样使用分布式数据库，分布式数据库具有低硬件成本、高可扩展性、高可用性等特性。
3OceanBase数据库产品简介
3.1发展历程及产品简介
- OceanBase核心特性
- 高性能：
- 水平扩展
- 按需在线扩容，缩容，不停服务
- 单集群突破100台服务器
- 高透明：
- ·全局一致性快照
- 全局索引
- ·自动事务两阶段提交
- 高兼容：
- Oracle/MySQL两种兼容模式
- 降低业务迁移改造成本
- 高扩展：
- 水平扩展
- 按需在线扩容，缩容，不停服务
- 单集群突破100台服务器
- 高可用：
- 基于Paxos协议，强一致性
- 少数副本故障，数据不丢，服务不停
- RPO=0; RTO<30s
- 多租户：
- DBaas架构
- 资源隔离
- 自动负载均衡
4OceanBase 产品家族及基础概念
4.1 产品家族及安装部署简介
- OceanBase 数据库内核通过 Paxos 协议保证了高可用性，可以兼容 MySQL 和 Oracle，同时支持 HTAP，即它既可以用于 OLTP 业务，也可以用于 OLAP业务。物理上看，OceanBase 数据库运行在很多台服务器上，组成一个大的集群。
- OceanBase 给运维者提供 OCP 工具平台，图形化的界面，帮助管理员更好的完成日常的集群管理、租户管理、监控告警、性能诊断等任务。
- OceanBase 给开发者提供 ODC 工具平台，图形化的界面，帮助开发者更好的完成数据库连接管理、数据库对象管理、存储过程开发调试、导入导出等任务。
- 为了方便快捷的进行数据迁移，OceanBase 还提供了 OMS 数据库迁移平台，既可以从数据仓库订阅数据，也可以从异构的数据库里（比如 DB2、Oracle、MySQL）进行数据迁移、回滚等。
4.2 基础概念
- OceanBase基础概念介绍
- 集群、zone、OB server
- 一个集群由多个Zone组成，给集群内的一批机器打上同一个tag，则属于同一个Zone；
- 不同的Zone可以对应不同城市、一个城市的不同机房、或者一个机房的不同机架；
- Zone个数>=3，建议是奇数；
- 每个zone均有且只有一份完整的副本;单Zone的故障不影响业务；
- 每台OB Server相对独立，有独立计算和存储引擎，也会有部分数据。对业务而言，每台 OB Server 均是一台传统的集中式数据库，业务访问到这台 OB Server 后，如果需要访问的数据在其它 OB Server 上，它们自己会自动协商调度，对业务是无感知的。
- RootService总控服务（RS）
- 服务：
- OceanBase的核心模块，管理整个集群。
- 集群内置服务，无需额外软硬件部署。
- 自带高可用能力，无单点故障风险。
- 核心功能：
- 系统初始化(BootStrap) ；系统元数据管理。
- 资源分配及调度：分区及副本管理、动态负载均衡、扩容/缩容等。
- 全局DDL；集群数据合并。
- 多租户机制，资源隔离，数据隔离
- 租户简介
- 将数据库集群按指定规格（CPU、内存、存储、TPS、QPS）划分成多个资源池，分配给不同的租户；
- 租户资源隔离策略:内存物理隔离;CPU逻辑隔离，数据隔离；
- 一般一个应用占用一个租户。
- 租户特性
租户类似传统数据库的实例，它由系统租户根据需要（比如说为了某个业务的需要）创建出来。在创建租户的时候，除了指定租户名字以外，最重要的是指定它占用的资源情况。租户具有如下特性:- 可以创建自己的用户（不同的用户名和密码);
- 可以创建数据库(database) 、表（table）等所有客体对象
- 有自己独立的information_schema等系统数据库
- 有自己独立的系统变量
- 数据库实例所具备的其他特性
- 每个租户拥有若干资源池(Resource Pool)
首先，我们需要定义一个资源规格，比如资源规格 U1=2C8G。这只是定义了一个 2C8G 的资源规格，并没有真正创建资源池。
然后创建一个资源池并授予给租户 1，这个资源池的定义是：Unit=U1，Unit 数量=1。Unit=U1 这个比较好理解，就是该租户的每个资源模块的规格都是 2C8G。这个“Unit 数量”怎么理解呢？是指这个租户只有 1 个资源么？不是的，我们可以看这个图上，蓝色方块的数量是 3 个，说明租户 1 有 3 个资源，分布在 Zone1、Zone2 和 Zone3，每个 Zone 都有 1 个资源。所以这个“Unit 数量=N”的意思是各个 Zone 内分配 N 个资源，而不是一共分配 N 个资源，若 N=1，3 个 Zone 的话就是 3 个资源模块，5 个 Zone 的话就是 5 个资源模块，这样单个 Zone 的故障不影响租户承载的业务。同理可以看下黄色模块代表的租户 2 和绿色模块代表的租户 3，“Unit 数量”分别为 2 和 3，意味着每个 Zone 将为他们分配 2 个和 3 个服务器，在每个服务器上分配一个 2C8G 的资源模块给租户。如果一个 Zone 内有很多服务器，租户的资源模块是分布在 Zone 内的各个 Server 中的，它的位置不是恒定不变的，会在 Zone 内各个 OB Server 中漂移（比如服务器故障或者有新扩容的服务器等）。
当然，这个资源大小和数量也不是静态的，可以随着业务的发展调整 Unit 的规格，比如从2C8G 调整为 4C16G，如果你把这个租户看成传统数据库的话，就是纵向扩展，或者调整 Unit的数量，比如从 1 到 3，就是横向扩展了。当然横向扩展也是有上限的，上限就是每个 Zone内服务器数量的上限
5OceanBase集群技术架构
5.1Paxos 协议与负载均衡
- 数据分区与分区副本
- 分区
- 当一个表很大的时候，可以水平拆分为若干个分区，每个分区包含表的若干行记录。根据行数据到分区的映射关系不同，分为hash分区，List分区（按列表), range分区（按范围)等。
- 每一个分区，还可以用不同的维度再分为若干分区，叫做二级分区。
- 分区是OceanBase数据架构的基本单元，是传统数据库的分区表在分布式系统上的实现。
- 副本
- 为了数据安全和提供高可用的数据服务，每个分区的数据在物理上存储多份，每一份叫做分区的一个副本。
- 副本根据负载和特定的策略，由系统自动调度分散在多个Server上。副本支持迁移、复制、增删、类型转换等管理操作。
- 支持三种副本，满足不同业务类型的需求
根据存储数据种类的不同，副本有几种不同的类型，以支持不同业务在在数据安全，性能伸缩性，可用性，成本等之间进行取舍折中。
副本的内容不单单只有硬盘上的静态数据，副本还包括内存的增量数据以及记录事务的日志。基于副本内容的不同，可以分为全能型副本、日志型副本、和只读型副本。
- 全能型副本：是最常用的副本，也就是目前支持的普通副本，拥有事务日志，Mem Table和SSTable等全部完整的数据和功能。它可以随时快速切换为leader对外提供服务。
- 日志型副本：只包含日志的副本，没有MemTable和SSTable。它参与日志投票并对外提供日志服务，可以参与其他副本的恢复，但自己不能变为主提供数据库服务。因为日志型副本所消耗的物理资源(CPU、内存、磁盘）更少，它它一般用于最后一个副本，可以有效降低最后一副本机器的成本，进而降低整个集群的总体成本，所以它不会变成主副本为业务提供服务。
- 只读型副本：包含完整的日志，MemTable和SSTable等，但是它的日志比较特殊。它不作为paxos成员参与日志的投票，而是作为一个观察者实时追赶paxos成员的日志，并在本地回放。这种副本可以在业务对读取数据的一致性要求不高的时候提供只读服务。因其不加入paxos成员组，又不会造成投票成员增加导致事务提交延时的增加。
- 多副本一致性协议
- 以分区为单位组建Paxos协议组：每个分区都有多份副本（ Replica) ，自动建立Paxos组，在分区级用多副本保证数据可靠性和服务高可用，数据管理更加灵活方便；
- 自动选举主副本：OB自动生成多份副本，多副本自动选举主副本，主副本提供服务（如图黄色副本供应用访问，蓝色副本用于备份)；
接下来我们对以上内容进行总结下：
1：OceanBase 的 Paxos 组是以分区为单位的，不是以表、数据库或者租户为单位的，是分区级的，在更细粒度上建立 Paxos 组，可以让数据管理更加灵活方便。
2：组成员会自动选举出主和从，不需要人工干预。
3：副本会均匀的分布在 Zone 内的机器上，避免单个 Zone 的故障影响业务。
- 自动负载均衡与智能路由
- 自动负载均衡：各个服务器中，使得各个服务器都能承载业务流量。(如图应用1、2、3读请求分布路由到不同的OB Server) ;
- 每台OB Server相互独立：每台OB Server均可以独立执行SQL，如果应用需要访问的数据在不同机器上，OB Server自动将请求路由至数据所在的机器，对业务完全透明（如应用2->P6->P7/P8)。
通俗来讲，每台 OB Server 都是全功能的，都是相对独立的，都践行“首问责任制”和“最多访问一次”的概念，避免对业务的侵入性。
- 通过多副本同步Redo Log确保数据持久化
- Paxos组成员通过Redo-Log的多数派强同步，确保数据的持久化；
- Leader无需等待所有Follower的反馈，多数派完成同步即可向应用反馈成功；
- 例子：
1.应用写数据到P2分区。Zone2-OB Server1的P2为主副本(Leader)，承接业务需求；
2.将Redo-Log同步请求发送到Zone1-OB Server1和Zone3-OB Server1中的P2从副本（ Follower) ；
3.任何一个Follower完成Redo-Log落盘并将响应返回给Leader后，Leader即认为Redo-Log完成强同步，无需再等待其它Follower的反馈；
4.Leader反馈应用操作完成。 - 该机制的好处：
- 数据更新只要Redo-Log落盘就好，而Redo-Log的落盘是像记日记一样，是顺序写的，很快。实际更新的数据存储在内存，不用马上落盘，减少了数据落盘带来的寻址、写数据等时间，快速响应应用的写请求。
- Redo-Log 日志是同时同步给 2 个以上的副本，只要多数派落盘成功，不用等所有从副本落盘成功，可以快速响应应用。
- OB Proxy为应用提供智能路由服务，应用透明访问
- 高路由转发
- 对SQL做基本解析，确定对应Leader所在机器；
- 反向代理，将请求路由至对应Leader； Leader位置无法确定时随机选择OB Server；
- 轻量SQL解析＋快速转发，保证高性能，单OB Proxy每秒转发百万次请求。
- “非”计算节点，无状态
- 每个OB Proxy是一个“无状态”的服务进程，不做数据持久化，对部署位置无要求；
- OB Proxy不参与数据库引擎的计算任务，不参与事务（单机or分布式)处理；
- 多个OB Proxy之间无联系，可通过F5/SLB组成负载均衡集群；
- 不需要独立服务器，可以与OB Server共用一台服务器，如果应用对实时性要求高，也可以将OB Proxy部署到应用服务器中。
