OceanBase分布式技术架构分析
oceanbase概述
OceanBase概述一、介绍OceanBase是一款分布式关系型数据库管理系统（RDBMS），由中国阿里巴巴集团自主研发并维护。
它致力于为全球用户提供高性能、高可用、高可靠的数据存储服务，以满足企业级应用对数据的存储和管理需求。
OceanBase的出现，填补了我国在数据库领域的空白，标志着我国在数据库核心技术上的重大突破。
二、发展历程OceanBase的发展历程可以追溯到2010年，当时阿里巴巴集团为了解决“双十一”购物狂欢节期间的大规模数据处理问题，开始研发一款全新的数据库系统。
经过多年的发展和完善，OceanBase已经成为了全球领先的分布式关系型数据库管理系统之一。
三、技术特点1. 分布式架构：OceanBase采用分布式架构，可以横向扩展，支持海量数据的存储和处理。
2. 高可用性：OceanBase具有高可用性，通过数据复制和故障切换技术，确保数据的可靠性和业务的连续性。
3. 高性能：OceanBase具有高性能，通过优化的数据存储和查询算法，提供快速的数据处理能力。
4. 多租户支持：OceanBase支持多租户模式，可以为多个用户提供独立的数据空间，保证数据的安全性和隐私性。
四、应用场景OceanBase广泛应用于各种场景，包括电商、金融、物流、教育、医疗等领域。
例如，它可以作为电商平台的后台数据库，支持每秒处理数百万笔交易；也可以作为金融机构的数据中心，存储和处理大量的金融交易数据；还可以作为物流公司的订单管理系统，支持实时的订单处理和追踪。
五、未来展望随着大数据和云计算技术的发展，OceanBase将继续发挥其分布式数据库的优势，提供更加强大和灵活的数据存储和处理能力。
同时，OceanBase也将积极探索新的技术领域，如人工智能、物联网等，以推动数据库技术的进一步发展。
六、总结OceanBase作为我国自主研发的分布式关系型数据库管理系统，不仅在技术上具有领先优势，而且在实际应用中也展现出了强大的能力。
oceanbase 级别定义
oceanbase 级别定义
OceanBase是阿里巴巴开发的一种分布式关系型数据库管理系统。
在OceanBase中，有几种不同的级别定义，包括事务级别、隔离级别和日志级别。
首先，让我们来看看事务级别。
在OceanBase中，事务级别定义了事务的隔离程度和并发控制的方式。
OceanBase支持四种事务级别，分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。
每种级别都有不同的特点和适用场景，可以根据实际业务需求进行选择。
其次，隔离级别是指在并发执行的事务中，一个事务对数据的修改在另一个事务中是否可见。
OceanBase支持的隔离级别包括READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。
不同的隔离级别对并发控制有不同的要求和影响，可以根据业务需求和性能要求进行选择。
最后，日志级别是指数据库系统记录和输出日志的详细程度。
在OceanBase中，日志级别包括ERROR、WARN、INFO和DEBUG。
不同的日志级别对系统性能和故障排查有不同的影响，可以根据实际
情况进行配置和调整。
总的来说，OceanBase的级别定义涵盖了事务级别、隔离级别
和日志级别，通过合理的配置和调整可以满足不同业务场景的需求，并提高系统的性能和稳定性。
OceanBase数据库源码解析
精彩摘录
本书还精选了一些实际应用场景中的案例进行分析。这些案例涵盖了金融、电商、社交等多个领 域。通过这些案例，读者可以更好地理解OceanBase数据库在实际应用中的表现和应用方式。书 中还详细介绍了如何优化OceanBase数据库的性能，以及如何处理高并发访问、数据一致性和容 灾等方面的技术难题。 对于这些摘录进行分析和解读，可以发现，《OceanBase数据库源码解析》这本书具有以下亮点： 亮点一：全面系统的解析。这本书对OceanBase数据库源码进行了全面而系统的解析，覆盖了从 数据结构、算法设计到查询、索引和事务处理等多个方面，为读者提供了一本深入了解 OceanBase数据库源码的宝典。 亮点二：实践应用与案例分析。书中所提供的案例分析，将理论知识与实践应用紧密结合。
目录分析
(1) OceanBase数据库的背景、技术架构和核心特性； (2)数据存储：包括数据的存储格式、压缩、恢复和复制等方面的内容； (3)索引：涉及B树、Hash表等索引数据结构以及索引的创建、维护和优化等方面的知识； (4)查询：涵盖查询计划的生成与执行、查询优化等； (5)事务处理：包括事务的并发控制、持久化机制等； (6)并发控制：涉及锁机制、并发事务的处理等； (7)容灾备份：讲述备份恢复策略、数据安全等方面的内容； (8)性能优化：针对OceanBase数据库的性能调优进行了详细阐述； (9)应用实践：提供了实际应用场景中的案例分析和最佳实践。 每个部分在整本书中都扮演着重要的角色，它们相互依赖、相互补充，共同构成了一个完整的体 系。
oceanbase案例
oceanbase案例1. OceanBase是什么？OceanBase是一个完全自主研发的分布式关系型数据库系统，由中国互联网巨头阿里巴巴集团旗下的阿里云计算公司研发。
它主要基于阿里巴巴自研的分布式系统技术，并在此基础上融合了MySQL和Oracle等关系型数据库的特点，提供了高性能、高可用、高扩展性的数据库解决方案。
2. OceanBase的历史发展OceanBase的研发始于2015年，最初是为了满足阿里巴巴内部的大规模交易场景需求而开发的。
2017年，阿里云将OceanBase推向市场，并逐步推广至更广泛的用户群体。
截至目前，OceanBase已经成为了阿里云数据库的核心产品之一，并在金融、电商、物流等众多领域得到了广泛应用。
3. OceanBase的特点OceanBase具有以下特点：（1）高性能：OceanBase采用多副本、多节点的分布式架构，能够支持百万级的并发请求，并具备线性扩展性，能够轻松应对高并发的业务场景。
（2）高可用：OceanBase提供了多副本、自动分区、数据冗余等多种机制，保证了数据的高可用性，能够在节点故障或网络中断等情况下保证系统的正常运行。
（3）高扩展性：OceanBase支持线性扩展，可以根据业务需求动态扩容或缩容，从而满足企业快速发展的需求。
（4）全球分布：OceanBase支持全球数据分布，能够实现多地域数据备份和异地容灾，提高了数据安全性和可靠性。
（5）免费：OceanBase提供了免费版和企业版两种版本，免费版可以满足小型企业的需求，企业版则提供了更为完善的功能和技术支持。
4. OceanBase的应用场景OceanBase主要应用于以下场景：（1）电商：海量商品数据，高并发的交易场景，对数据库的性能和可靠性要求非常高，OceanBase能够满足这些需求。
（2）金融：金融领域对数据的安全和可靠性要求非常高，OceanBase提供了多副本、数据冗余、自动容错等多种机制，能够保证数据的高可用性和安全性。
阿里巴巴——Oceanbase
物理查询计划举例-单表查询
物理查询计划举例-多表查询
写事务
• 写事务，包括UPDATE、INSERT、DELETE、 REPLACE，由MergeServer解析后生成物理执行计划， • 物理执行计划最终将发给UpdateServer执行。
• 写事务可能需要读取基线Server
ChunkServer的功能包括：存储多个tablet、提供读取服务、执行定期 合并以及数据分发。
OceanBase将大表划分为大小约为256MB的tablet，每个tablet由 一个或者多个SSTable组成（一般为一个），每个SSTable由多个块 （Block，大小为4KB ~ 64KB之间，可配置）组成，数据在SSTable中 按照主键有序存储。 查找某一行数据时，需要首先定位这一行所属的tablet，接着在相 应的SSTable中执行二分查找。 SSTable支持两种缓存模式，Block Cache以及Row Cache。 Block Cache以Block为单位缓存最近读取的数据，Row Cache以行为 单位缓存最近读取的数据。
OceanBase——MergeServer
MergeServer的功能主要包括：协议解析、SQL解析、请求转发、结果合 并、多表操作等。
OceanBase客户端与MergeServer之间的协议为Mysql协议。 MergeServer首先解析Mysql协议，从中提取出用户发送的SQL语句，接着 进行词法分析和语法分析，生成SQL语句的逻辑查询计划和物理查询计 划，最后根据物理查询计划调用OceanBase内部的各种操作符。 MergeServer缓存了tablet分布信息，根据请求涉及的tablet将请求转发 给该tablet所在的ChunkServer。如果是写操作，还会转发给 UpdateServer。 MergeServer支持并发请求多台ChunkServer，即将多个请求发给多台 ChunkServer，再一次性等待所有请求的应答。
如何基于OceanBase构建应用和数据库的异地多活
如何基于OceanBase构建应用和数据库的异地多活OceanBase是一个通用的分布式的关系型数据库，有很多独特的特点。
比如数据库的多租户、高可用、极致弹性伸缩能力。
如果把OceanBase当作单库使用，就没有把OceanBase的分布式优势发挥到极致。
本文主要分享一个基于分布式架构的应用把OceanBase数据库的分布式优势发挥到极致所需要了解的OceanBase基础，这也是理解蚂蚁金服的基于OceanBase构建的三地五中心异地多活架构的基础。
分布式数据库开发相关问题好的性能首先是设计出来的，应用如果追求极致的性能，就需要关注OceanBase里数据的相关事情。
如：•数据如何分布？•数据如何读写？•存储容量瓶颈怎么办？•访问性能瓶颈怎么办？•数据库出故障时数据可用性和可靠性具体怎样？应用需要做什么特殊处理么？•数据库扩展时应用需要迁移数据么？数据迁移的时候对应用有什么影响？这些问题对理解OceanBase的分布式特点很有帮助。
后面我们逐步看看OceanBase是如何应对。
OceanBase集群外观首先简介一下OceanBase集群的外观。
图 1 OceanBase集群外观OceanBase是以集群形式运行的，由一堆服务器组成。
上图是「三副本」部署，机器会分为三组，每组一个区域（称为Zone），各个机器通过网络互相访问。
没有光纤交换机、共享存储以及直连网线等。
服务器通常建议CPU、内存和磁盘尽可能的大，磁盘建议用普通SSD盘。
普通服务器的好处是便宜，劣势是可靠性和性能可能不如小型机那么高。
也就是说OceanBase可以部署在一组可靠性和性能不是特别高的普通服务器上，却提供了高性能、高可用和高可靠、弹性伸缩等多项能力。
以上是一个OceanBase集群的外观和能力，但是提供给业务的并不是这个集群的全部资源和能力，而是其子集，即租户（T enant）。
OceanBase多租户特性OceanBase定义了一些基本的资源规格（Resource unit config，如4CPU8Gmem500Gdisk等），然后选取某类资源规格创建一组资源池（Resource Pool），此时集群资源就有一部分被分配出去了。
OceanBase云平台产品说明书
OceanBase 云平台（产品名称） 声明 产品版本：V1.0.0（软件版本）文档版本：20150122（发布日期）OBCP 实验指导手册｜产品版本：V 0.8.8声明蚂蚁集团版权所有 © 2020 ，并保留一切权利。
未经蚂蚁集团事先书面许可，任何单位、公司或个人不得擅自摘抄、翻译、复制本文档内容的部分或全部，不得以任何方式或途径进行传播和宣传。
商标声明及其他蚂蚁集团相关的商标均为蚂蚁集团所有。
本文档涉及的第三方的注册商标，依法由权利人所有。
免责声明由于产品版本升级、调整或其他原因，本文档内容有可能变更。
蚂蚁集团保留在没有任何通知或者提示下对本文档的内容进行修改的权利，并在蚂蚁集团授权通道中不时发布更新后的用户文档。
您应当实时关注用户文档的版本变更并通过蚂蚁集团授权渠道下载、获取最新版的用户文档。
如因文档使用不当造成的直接或间接损失，本公司不承担任何责任。
目录声明 (I)1.实验概述 (1)2.实验准备 (3)2.1.实验架构 (3)2.2.设备需求 (3)3.实验：OB分布式架构高级技术 (4)3.1.OB负载均衡 (4)4.实验：OB存储引擎高级技术 (21)4.1.内存管理 (21)4.2.合并与转储 (27)5.实验：OB SQL引擎高级技术 (31)5.1.SQL 引擎 (31)5.2.SQL 执行计划 (38)5.3.执行计划缓存 (47)6.实验：OB SQL调优 (54)6.1.分区 (54)6.2.索引、局部索引与全局索引 (60)6.3.Hint (65)6.4.SQL 性能监控 (68)7.实验：OB分布式事务高级技术 (72)7.1.全局快照与分布式一致性读 (72)8.实验：OBProxy 使用与运维 (78)8.1.OBProxy基础运维 (78)8.2.OBProxy 路由配置与运维 (80)9.实验：OB备份与恢复 (84)9.1.（逻辑）备份与恢复 (84)9.2.（物理）备份与恢复 (91)10.实验：OB 运维、监控 (98)10.1.用户管理 (98)10.2.日志管理 (103)10.3.日常运维操作 (108)10.4.数据监控 (113)10.5.灾难恢复 (117)3.实验：OB分布式架构高级技术3.1.OB负载均衡3.1.1.实验目的在这一章节的实验中，学员能够体验和理解OB负载均衡的主要特性，如下： ²表组特性下的资源分配²自动负载均衡²集群扩容²租户扩容²PrimaryZone 的设置3.1.2.实验准备进行负载均衡实验，每个 OB ZONE 中至少有两台 observer.步骤 1：完成基础的OB集群搭建，每个 Zone 先只有一个 observer3.1.3.实验步骤3.1.3.1 表组特性下的资源分配步骤 1：租户 obcp_t1下创建表分区mysql登录obcp_t1 租户，选择 test数据库use testcreate table t1 (c1 int,c2 int ) ;create table t2 (c1 int,c2 int ) primary_zone='zone2' ;create table t3 (c1 int,c2 int ) partition by hash (c1) partitions 3;查看表分区副本分布情况的统计：mysql> select tenant.tenant_name, zone, svr_ip,casewhen role=1 then 'leader'when role=2 then 'follower'else NULLend as role,count(1) as partition_cntfrom__all_virtual_meta_table meta inner join __all_tenant tenant onmeta.tenant_id=tenant.tenant_idinner join __all_virtual_table tab on meta.tenant_id=tab.tenant_id andmeta.table_id=tab.table_idwheretenant.tenant_id=<obcp_t1 ID>group by tenant.tenant_name,zone, svr_ip, 4order by tenant.tenant_name, zone, svr_ip, role desc;注： 实验环境中，创建的表分区的分布开始未必如以上这样均衡的， 负载均衡需要一些时间，待系统检测并自动分布。
oceanbase sql 执行计划解读
oceanbase sql 执行计划解读OceanBase 是一个分布式关系数据库，其 SQL 执行计划是查询优化的核心。
执行计划描述了如何以最高效的方式执行 SQL 查询。
下面我将简要介绍OceanBase SQL 执行计划的解读。
1、执行计划概述执行计划是一个数据结构，它描述了数据库如何执行 SQL 查询。
执行计划由一系列操作组成，每个操作描述了数据库如何处理查询的一个部分。
执行计划是查询优化器生成的最佳执行计划，它旨在以最小化时间和资源消耗的方式返回查询结果。
2、执行计划的结构执行计划通常由多个操作组成，每个操作都有一个名称和一组属性。
操作名称描述了要执行的操作类型，例如选择、连接、排序、扫描等。
属性提供了有关操作的更多信息，例如要扫描的表、要连接的表等。
3、解读执行计划解读执行计划需要理解每个操作的意图和代价。
以下是一些常见的操作和它们的解读：（1）选择操作：选择操作用于过滤查询结果。
它基于指定的条件过滤行，并返回满足条件的行。
解读选择操作时，需要关注条件表达式和过滤的行数。
（2）连接操作：连接操作用于将两个或多个表中的行组合在一起。
它基于指定的连接条件将行匹配在一起。
解读连接操作时，需要关注连接类型（内连接、左外连接等）和连接条件。
（3）排序操作：排序操作用于对查询结果进行排序。
它根据指定的列或表达式对结果进行排序。
解读排序操作时，需要关注排序顺序（升序或降序）和使用的列或表达式。
（4）扫描操作：扫描操作用于读取表中的数据。
它可以是有索引扫描或全表扫描。
解读扫描操作时，需要关注要扫描的表、扫描方式（使用索引或全表）以及返回的行数。
4、评估执行计划评估执行计划是确定查询的效率和资源消耗的关键步骤。
评估执行计划时，需要考虑以下因素：（1）操作的顺序和类型：理解操作的顺序和类型有助于确定查询的复杂性和资源消耗。
（2）操作的代价：每个操作都有一个代价，包括CPU时间、I/O开销等。
了解操作的代价有助于确定查询的性能瓶颈。
oceanbase 并发参数
oceanbase 并发参数
（原创版）
目录
1.介绍 OceanBase
2.OceanBase 的并发参数
3.结论
正文
1.介绍 OceanBase
OceanBase 是一个分布式关系型数据库，其设计目标是为了满足高并发、高可用性和低延迟等需求。
在金融、电商等对数据一致性和可用性要求高的场景中，OceanBase 都有着广泛的应用。
2.OceanBase 的并发参数
OceanBase 的并发参数主要包括以下几个：
- 并发度：这个参数决定了一个事务在执行过程中，可以同时执行的并发事务的数量。
并发度越高，系统的并发能力越强，但是过高的并发度可能会导致事务冲突，影响系统的可用性。
- 事务间隔：这个参数决定了一个事务在执行过程中，需要等待其他事务执行完成的时间间隔。
事务间隔越短，系统的并发能力越强，但是过短的事务间隔可能会导致事务冲突，影响系统的可用性。
- 锁等待时间：这个参数决定了一个事务在等待锁的时候，可以等待的最长时间。
锁等待时间越长，系统的并发能力越强，但是过长的锁等待时间可能会导致事务冲突，影响系统的可用性。
- 提交间隔：这个参数决定了一个事务在提交后，需要等待其他事务提交完成的时间间隔。
提交间隔越短，系统的并发能力越强，但是过短的提交间隔可能会导致事务冲突，影响系统的可用性。
3.结论
总的来说，OceanBase 的并发参数是一个重要的调节手段，可以通过合理设置并发参数，达到提高系统并发能力，保证系统可用性的目的。
OceanBase设计规范与数据架构指南_v2(1)_3
OceanBase设计规范与数据架构指南文档修订历史1OceanBase1.0 简介自从E.F.Codd于1970年首次提出关系数据库模型后，关系数据库便以其易于使用的接口、完善的功能和生态而成为了IT领域必需的基础设施，广泛应用在各行各业，包括金融、电信、房地产、农林牧渔、制造业等等。
关系数据库经过了40多年的发展，涌现了Oracle、SQL Server、DB2等优秀的商业数据库产品，开源领域也不乏MySQL、PostgreSQL这样的精品。
但是，随着互联网行业和大数据的兴起，数据量和并发访问量呈现指数级的增长，囿于关系数据库的架构，原先运行良好的关系数据库遭遇了严峻的挑战：极度高昂的总体拥有成本、捉襟见肘的扩展能力、荏弱无力的大数据处理性能等等。
于是NoSQL应运而生，Hbase、Cassandra等系统如雨后春笋般冒出，这些系统多采取分布式架构，易于扩展及容灾，结合大数据处理系统如Hadoop 等，可以很容易处理量级非常大的数据，这一时让NoSQL风光无两，大有取代SQL之势，让人看不清NoSQL系统的边界。
很多公司尝试将核心系统迁移到新兴的NoSQL系统上，比如Facebook就尝试将部份核心系统迁移到Cassandra。
在迁移过程中，人们发现NoSQL所获得针对SQL的优势其实是以牺牲一些非常重要的功能来获取的，如NoSQL一般不支持事务或只支持非常有限的事务，这极大的增加了业务系统的复杂度，在传统的OLTP领域采取NoSQL系统基本上是不可以接受的。
阿里巴巴/蚂蚁金服的关系数据库使用场景极其严苛，有着全球最大的并发量需求，在可靠性方面需要做到单机、机架、机房甚至是地区级别的容灾恢复能力。
早期使用共享存储、小型机等高端硬件也只能部分满足我们在性能和可靠性上的需求，而且随着业务的发展，这种IOE架构很快就成为瓶颈。
我们能不能结合新兴分布式系统和传统关系型数据库的优点，既拥有传统关系型数据库在功能上的优势，同时具备分布式系统的可扩展性、高可靠性等特征？OceanBase即是以此为出发点，开始打造一个分布式关系型数据库。
支付宝高级技术专家黄贵《OceanBase：海量分布式关系型数据库》
mergeserver进行sql解析，生成物理执行计划，将其中的数据操作部分计划 （包括部分操作符）根据tablet划分幵发下压到ChunkServer执行。
数据合幵
读写事务 照常进行
新的修改增 量
Data
基线数据
冻结修改增量
很多数据库每天有明显的访问低谷
数据合幵期间的读事务
Data
基线数据
冻结修改增量
bucket1 bucket2 bucket3
bucket4 root
index
index
bucket5 bucket6 mutator list mutator list mutator list mutator list
幵发事务管理
• 使用MVCC保证写事务丌阻塞只读事务
• •
• •
每行为每次事务保存修改历叱，根据事务ID读取到指定数据 修改历叱的合幵，丌在被读取的多个历叱版本将被定期合幵
MergeServer ChunkServer
MergeServer ChunkServer
MergeServer ChunkServer
MergeServer ChunkServer
MergeServer ChunkServer
Root Server
MergeServer ChunkServer
Update Server
– Spring配置
<bean id="groupDataSource" class="com.alipay.oceanbase.OBGroupDataSource" init-method="init"> <property name="userName" value=“ob" /> <property name="passwd" value="test"/> <property name="dbName" value="test" /> <property name="configURL" value="http://10.232.102.182:8080/diamond-server/.../> </bean>
OceanBase分布式事务以及两阶段提交实现具体设计
OceanBase分布式事务以及两阶段提交实现具体设计眼下OceanBase中还存在updaeserver单点，下⼀步的开发任务是使得OB⽀持多点写⼊，⽀持多个UPS(及updateserver)。
当中难点是怎样设计两阶段提交的失败恢复以及多机的快照读写，和同事讨论后，形成⼀个能够work的简单设计版本号，记录在此。
为分布式事务的两阶段提交细化详细流程，拟採⽤primary record⽅式实现失败恢复，即在进⼊commit阶段之前。
先写⼊primary record 记录当前事务的状态（commit/rollback）。
Primary record起到⼀个全局⽇志的作⽤。
可供全部參与者读取。
须要注意的是，为了保证⼀致性，读写primary record 都须要加锁，须要使⽤select update语句。
採⽤primary record ⽅式的优势是，协调者在整个事务处理过程中能够是⽆状态的，不须要记录操作⽇志。
宕机重新启动后不须要做失败处理。
⽽參与者宕机重新启动或超时失败后，能够⽆需与协调者以及其它參与者通信，实现独⽴恢复，实现简单。
其缺点是每次分布式事务中都会记录⼀次primary record，会添加写⼊数据量以及事务延迟。
将两阶段提交的流程分为下⾯⼦流程描写叙述：Ø 协调者处理流程Ø 參与者处理流程Ø 未决事务处理流程为⽀持长事务、长事务中长语句以及两阶段提交，⽂档还简单描写叙述了对UPS⽇志的改动⽬标。
最后。
⽂档简单记录了组内讨论实现多UPS快照读写的⼀些讨论结果。
1. 两阶段提交具体流程Ø 协调者处理流程协调者处理流程指的是開始⼀个分布式事务直到事务结束或者失败。
处理期间。
协调者须要维护分布式事务的相关状态和信息，如參与者列表，事务运⾏计划，事务提交的时间戳，事务的primary record 主键等等，这些信息不须要持久化存储，协调者宕机后。
OceanBase1.0的分布式事务讲解
盘的原子性操作和硬件本身有关，磁盘一般是一个512 字节的块写入是原子的，SSD 一般是4KB 的块写入是原子的。
用一个数据结构的例子说明这种原子性实现机制。
struct Balance {int accountA;int accountB;};Balance * x ＝new Balance();上面是C++ 的结构体，表示了两个账户 A 和 B 的余额。
如果从 A 转账5 元给B，对应的C++ 代码如下：x->accountA -= 5;x->accountB += 5;上面的代码不是原子的，在两条语句中间，如果另一个线程读取accountA 和accountB 的值，会发现转账操作只执行了一半。
如果使用下面的代码，就可以保证无论什么时候读取，都不会读到转账执行了一半的情况：Balance * tmp = new Balance();tmp->accountA = x->accountA - 5;tmp->accountB = x->accountB + 5;x = tmp;操作的生效时间是x = tmp;语句，单一变量的赋值操作是原子的，保证了整个转账操作是原子的。
使用日志实现原子性（Atomicity）上面基于原子性操作的实现方法在数据结构中很常用，但是现在数据库系统都是使用日志技术（log）实现原子性（Atomicity），因为日志技术解决原子性的方法更灵活，还能同时解决了事务的持久性（Durability）需求，而且比直接持久化数据有更好的性能，所以几乎所有的数据库系统都采用了日志技术（log），甚至还包括文件系统、队列系统等。
使用log 时，先把整个事务的操作编码成连续的日志信息，再把日志信息写入持久化设备，当日志成功写入后，就是保证事务原子性成功的时机。
以上面的转账操作为例，编码出的日志信息如下：<accountA, balance, -5>, <accountB,, balance, +5>当上面的信息持久化成功后，数据库系统再会修改两个帐户的数据，而且帐户数据本身持久化到硬盘的时机可以延后到任意时刻，因为即使数据没有持久化前就宕机了，系统重启后还是可以从log 中将上面的转账操作恢复出来。
oceanbase底层原理
oceanbase底层原理OceanBase是阿里巴巴集团自主研发的一款分布式数据库系统，具有高可用、高可靠、高扩展性等特点。
它的底层原理涉及到分布式存储、分布式事务、分布式索引等多个方面。
下面将从这些方面详细介绍OceanBase的底层原理。
1. 分布式存储OceanBase采用了分布式存储架构，将数据分散存储在多个节点上，提高了数据的可靠性和可用性。
它使用了一种称为“Sharding”的技术，将数据按照一定的规则分割成多个片段，并将这些片段分布在不同的节点上。
这种方式可以使得数据的访问更加高效，同时也能够提高系统的容错性。
2. 分布式事务在分布式场景下，保证数据的一致性是一个重要的问题。
OceanBase 通过使用多副本和分布式事务来解决这个问题。
多副本可以保证数据的可靠性，即使某个节点出现故障，系统仍然能够正常运行。
而分布式事务则可以保证多个节点上的数据操作是一致的，避免了数据的冲突和不一致。
3. 分布式索引索引是数据库系统中非常重要的一个组成部分，它可以提高查询效率。
OceanBase的底层原理中也包含了分布式索引的设计。
它采用了一种称为“DolphinDB”的技术，将索引数据分布在多个节点上，并通过一定的算法将数据定位到正确的节点上进行查询。
这样可以使得索引的访问更加高效，并且能够支持海量数据的快速检索。
4. 分布式调度OceanBase的底层原理中还包括了分布式调度的设计。
它通过一种称为“OceanScheduler”的技术，将任务分配给不同的节点进行执行。
这样可以使得系统的负载均衡，提高系统的稳定性和性能。
5. 分布式计算除了存储和索引，OceanBase的底层原理中还包括了分布式计算的设计。
它通过一种称为“OceanCompute”的技术，将计算任务分发到不同的节点上进行并行计算。
这样可以提高计算效率，同时也能够支持大规模数据的处理。
总结起来，OceanBase的底层原理涉及到分布式存储、分布式事务、分布式索引、分布式调度和分布式计算等多个方面。
国产数据库OceanBase实现一大突破迈入4.0时代
国产数据库OceanBase实现一大突破迈入4.0时代8月10日，2022OceanBase年度发布会在京沪深三地同时召开，一系列动作标志着国产分布式数据库OceanBase正式迈入4.0时代。
OceanBase 4.0首次实现单机分布式一体化架构，公共云收入同比增长300%，在这些成绩面前，OceanBase又发布四大基于产品、服务、生态、开发者应用的策略。
OceanBase 4.0首次实现单机分布式一体化架构OceanBase发布的业内首个单机分布式一体化架构，可以实现单机部署并兼顾分布式架构的扩展性与集中式架构的性能优势，实现了更低的部署成本和运维复杂度，灵活满足不同使用场景需求，极大降低中小企业使用分布式数据库的门槛，打破当前分布式数据库只适用于大客户的局限，让中小企业也可以低成本使用分布式数据库。
4.0版本能在全球最小的电脑树莓派上运行，即使是普通的个人电脑也可以运行单机分布式一体化数据库。
4.0版本能够把故障恢复时间（RTO），从30秒提升到8秒以内。
当故障发生时，数据丢失率（RPO）为零。
8秒内恢复，是中国数据库融灾的第一次，也是全球数据库的第一次。
“珊瑚计划”发布未来，OceanBase将降低直接面对客户的比例，建立以“合作伙伴”为中心的商业生态模式。
为了升级商业生态模式，OceanBase推出“珊瑚计划”：未来3年，面向全国重点省会城市，培养60家核心经销商，三年实现合作伙伴收入份额占总销售份额60%以上。
从2020年正式商业化至今，OceanBase已服务金融、政府、运营商、零售、互联网等多个行业的400多家客户实现核心系统升级。
如，支撑山东移动实现业务降本增效：详单处理效率提升30%，存储投入成本降低 90%；稳定支撑理想汽车自研生产制造系统 MES、仓储管理系统 WMS，产线抖动频率平均下降约80%。
社区版与企业版同等性能OceanBase将发布4.0社区版，MySQL兼容能力全部开源，社区版将享受企业版同等性能。
淘宝：OceanBase分布式系统负载均衡案例分享
淘宝：OceanBase分布式系统负载均衡案例分享摘要：Heroku因“随机调度+Rails单线程处理导致延迟增加的负载均衡失败”的案例之后，我们在思考：在负载均衡测试时发现问题并妥善解决的成功经验有没有？于是，挖掘出“淘宝在双十一压测OB时发现存在严重的随机访问导致负载不均问题，并通过加权算法妥善解决”的成功案例，也就是本文。
编者按：在CSDN云计算频道日前所做的文章《响应高达6秒用户揭露Heroku私自修改路由造成高支出》中，网友们认为这是“因随机调度+Rails的单线程处理导致延迟增加的负载均衡失败的案例”。
但在负载均衡测试时就能发现问题并妥善解决的成功经验有没有？在随后的微博中，支付宝的@Leverly评论：“去年双11前的压测OB就发现了存在严重的随机访问导致负载不均问题，还好通过加权算法很好的解决了。
”引发了我们的关注，于是有了本文。
重点是淘宝在“双十一”背后，OceanBase分布式系统负载均衡的经验分享。
以下为正文：云计算所具备的低成本、高性能、高可用性、高可扩展性等特点与互联网应用日益面临的挑战不谋而合，成为近年来互联网领域的热门话题。
作为一名技术人员不难理解在云计算的底层架构中，分布式存储是不可或缺的重要组成部分。
国外知名的互联网公司如Google、Amazon、Facebook、Microsoft、Yahoo等都推出了各自的分布式存储系统，在国内OceanBase 是淘宝自主研发的一个支持海量数据的高性能分布式数据库系统，实现了数千亿条记录、数百TB数据上的跨行跨表事务[1]。
在分布式系统中存在着著名的“短板理论”[2]，一个集群如果出现了负载不均衡问题，那么负载最大的机器往往将成为影响系统整体表现的瓶颈和短板。
为了避免这种情况的发生，需要动态负载均衡机制，以达到实时的最大化资源利用率，从而提升系统整体的吞吐。
本文将结合OceanBase的实际应用和大家分享一个去年淘宝双十一前期的准备工作中遇到负载均衡相关案例，抛砖引玉，期望对大家的工作有所启发。
oceanbase 安可标准
oceanbase 安可标准OceanBase安可标准OceanBase是阿里巴巴集团自主研发的一款分布式数据库产品，是建立在阿里云云原生数据库服务基础上的企业级分布式数据库系统。
OceanBase以其高可用、高性能、高扩展性和高可靠性等特点，在云计算、大数据和物联网等领域广泛应用。
其中，安可标准则是OceanBase中的一项重要的功能。
安可标准是OceanBase在数据可靠性方面的一种安全机制。
在分布式系统中，由于各个节点之间的通信存在延迟或者网络故障等问题，导致数据在不同节点上的一致性难以保证。
为了解决这个问题，OceanBase引入了安可标准。
安可标准的核心思想是通过日志复制和重放来实现数据的一致性。
具体来说，当OceanBase的一个节点接收到客户端的写请求时，它会将写操作记录在本地的日志文件中，并通过网络将这个日志文件发送给其他节点。
其他节点在接收到日志文件后，会按照写请求的顺序将操作记录到各自的日志文件中。
当节点在本地的日志文件中陆续累积了一定量的写操作后，会对这些操作进行批量重放，以保证所有节点之间的数据同步。
安可标准的实现主要包括两个部分：安可决策和安可执行。
安可决策是通过一套算法来判断在什么情况下可以安全地应用写请求。
而安可执行则是指在安可决策的基础上，按照一定的顺序将写请求记录到各个节点的日志文件中，并进行批量重放。
在OceanBase中，安可标准具有以下几个特点：1. 原子性：安可标准能够保证写操作的原子性，即要么全部执行成功，要么全部不执行。
2. 一致性：安可标准保证数据在不同节点之间的一致性，即各节点上的数据应该保持一致。
3. 隔离性：安可标准通过日志复制和重放，将写请求的执行与读操作相隔离。
这样即使在执行过程中发生错误，也不会影响到正在进行的读操作。
4. 持久性：安可标准将写操作记录在日志文件中，并不断地进行重放。
这样即使系统发生故障，也能够通过重放日志文件来恢复数据。
oceanbase备份原理
oceanbase备份原理OceanBase备份原理是指通过创建数据备份副本来保护数据库中的数据。
OceanBase是一款分布式的关系型数据库系统，它将数据分布在多个节点上，并使用多副本存储数据来提高数据的可用性和容错性。
在OceanBase中，数据以行的形式存储在表中，每行数据都有一个唯一的主键值。
为了实现数据备份和高可用性，OceanBase使用了基于paxos协议的一致性副本机制。
具体来说，OceanBase将每个数据表分为多个区块（chunk），每个区块都有一个副本组，副本组由多个数据节点组成，每个节点都有一个副本。
对于每个副本组，会选择一个节点作为领导者（leader），其他节点作为从属节点（follower）。
当用户在OceanBase中插入、更新或删除数据时，首先会将操作请求发送给领导者节点。
领导者节点会将操作请求在副本组中的各个节点上执行，并在执行完成后将结果返回给用户。
同时，领导者节点会将操作请求同步给从属节点，以便后续的数据一致性检查和备份操作。
在一致性副本机制中，领导者节点会将操作请求发送给副本组中的多个节点，并等待大多数节点的确认。
一旦领导者节点收到大多数节点的确认，就可以认为操作已经达到了一致性，并将结果返回给用户。
如果领导者节点出现故障，系统会自动选举新的领导者节点。
由于数据在多个节点上有多个副本，即使某个节点或副本组发生故障，其他节点上的副本仍然可以继续提供服务。
当节点恢复正常后，系统会自动将缺失的数据副本恢复。
综上所述，OceanBase通过使用多副本和一致性副本机制实现了数据的备份和高可用性。
它能够保障数据的安全性和可靠性，提供高性能和高可用性的数据库服务。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
OceanBase分布式技术架构分析目录OceanBase作为金融级分布式数据库一直备受瞩目 (3)1. 分布式存储&事务 (3)2. 分布式查询 (13)3. 经验&思考 (15)OceanBase作为金融级分布式数据库一直备受瞩目OceanBaseOceanBase 1.0项目从2013年初开始做总体设计，2014年开始编码、测试，2015年底正式上线并无缝迁移部分集团MySQL业务，直到2016年中才正式上线蚂蚁核心业务，包括会员视图、花呗、账务，等等，最后“丝般柔顺”地通过了2016年双十一大考。
从技术架构的角度看，一个分布式数据库主要就是两个部分：一个部分是怎么做存储，怎么做事务；另外一个部分是怎么做查询。
首先我们看第一个部分，主要是三个关键点：可扩展、高可用以及低成本，它们代表了OceanBase的核心技术优势。
1.分布式存储&事务第一我们怎么理解数据，如何把数据划分开来从而分布到多台服务器？这个问题其实传统关系数据库已经帮我们解决好了。
无论是Oracle还是MySQL，都支持一个叫做两级分区表的概念。
大部分业务都可以按两个维度划分数据：一个维度是时间，数据是按照时间顺序生成的；另外一个维度，对于互联网业务来讲，往往就是用户。
不同的用户生成不同的数据，不同用户之间的数据相关度比较低，而同一个用户的数据往往会被同时访问。
图1 OceanBase数据分布如图1，通过时间和业务主键两个维度将表格划分为P1~P8总共8个分区。
OceanBase 跟传统数据库不一样的地方在哪里呢？传统数据库所有的分区只能在一台服务器，而OceanBase每个分区可以分布到不同的服务器。
从数据模型的角度看，OceanBase可以被认为是传统的数据库分区表在多机的实现。
对于常见的分布式系统，要么采用哈希分区，要么采用范围分区。
OceanBase的数据划分方案和这些系统有较大的差别，通过两级分区表，我们可以把不同的用户，以及在不同时间点生成的数据全部融合到统一的表格里面。
无论这些分区在在多台服务器上是如何分布的，甚至可以对在线数据采用内存计算，对历史数据采用更高压缩率的压缩算法或者执行预计算，整个系统对使用者呈现的都是一张表格，后台实现对使用者完全透明。
当然，这里面还会有很多的工作要做。
第二点是我们底层的分布式架构。
图2 OceanBase整体架构图2是OceanBase整体架构图。
OceanBase架构图往往都是三个框框。
为什么这样呢？这是基于高可用考虑的。
为了实现机房故障无损容灾，OceanBase需要部署到三个机房。
每个机房又会有很多服务器，每台服务器又会服务很多不同的分区。
如图2， P1到P8代表不同的分区，每个分区有3个副本，分布在三个机房内。
用户的请求首先发给ObProxy。
ObProxy是一个访问代理，它会根据用户请求的数据将请求转发到合适的服务器。
ObProxy的最大的亮点在于性能特别好，我们对它做了非常多的针对性优化，使得它可以在非常一般的普通服务器上达到每秒百万级的处理能力。
ObServer是OceanBase的工作机，每台工作机服务一些分区。
与大多数分布式系统不同的地方在于，OceanBase这个系统没有单独的总控服务器/总控进程。
分布式系统一般包含一个单独的总控进程，用来做全局管理、负载均衡，等等。
OceanBase没有单独的总控进程，我们的总控是一个服务，叫做RootService，集成在ObServer里面。
OceanBase会从所有的工作机中动态地选出一台ObServer执行总控服务，另外，当总控服务所在的ObServer出现故障时，系统会自动选举一台新的ObServer 提供总控服务。
这种方式的好处在于简化部署，虽然实现很复杂，但是大大降低了使用成本。
接下来我们看整个数据库最核心的部分。
数据库最基础，也是最核心的部分是事务处理，这点对于多机系统尤其重要。
如果只是操作单个分区，因为单个分区一定只能由一台服务器提供服务，本质上是一个单机的事务，OceanBase的实现机制和Oracle、MySQL这样的传统数据库原理类似，也是多版本并发控制。
不同点在于，OceanBase做了一些针对内存数据库的优化，主要有两点：1.日志同步。
因为要做高可用，一定要做日志的强同步。
OceanBase之所以既能做到高可用，又能做到高性能，是因为我们做了很多针对日志强同步的优化，包括异步化、并行，等等；2.内存数据库。
OceanBase借鉴了内存数据库的设计思路，实现了无锁数据结构、内存多版本并发控制、SQL编译执行等优化手段。
如果操作多个分区，这又分成两种情况：1.多个分区在同一台服务器。
由于多个分区在一台服务器，本质上也是单机事务，实现方案与之前提到的单分区事务类似。
2.多个分区分布在多台服务器上。
由于多个分区跨ObServer，OceanBase内部通过两阶段提交实现分布式事务。
当然，两阶段提交协议性能较差，OceanBase内部做了很多优化。
首先，我们提出了一个表格组的概念，也就是说，我们会把多个经常一起访问，或者说访问模式比较类似的表格放到一个表格组里面。
与此同时，OceanBase后台会将同一个表格组尽可能调度到一台服务器上，避免分布式事务。
接下来的优化手段涉及到两阶段提交协议的内部实现。
两阶段提交协议涉及多台服务器，协议中包含协调者、参与者这两种角色，参与者维护了每台服务器的局部状态，协调者维护了分布式事务的全局状态。
常见的做法是对协调者记日志来持久化分布式事务的全局状态，而OceanBase没有这么做。
如果协调者出现故障，OceanBase通过查询所有参与者的状态来恢复分布式事务。
通过这种方式节省了协调者日志，而且只要所有的参与者都预提交成功，整个事务就成功了，不需要等协调者写日志就可以应答客户端。
OceanBase里面高可用是基于Paxos协议实现的。
Google Chubby系统的发明者说过一句话，这个世界上所有的高可用强一致的协议都是Paxos或者Paxos的变种，我们也认为一切不是Paxos协议实现的高可用机制都是耍流氓。
图3 OceanBase高可用原理如图3，OceanBase最底层的技术就是通过Paxos协议实现的分布式选举和多库多活。
Paxos协议的好处在于节点是多活的，当服务节点出现故障时，其它正常的节点可以在几秒内替代这个故障的节点，很快恢复服务，而且完全不丢数据。
Paxos协议同时实现了高可用和强一致，这是很牛的。
当然除了最底层核心的Paxos协议，OceanBase还会通过分布式调度将同一个分区的不同副本调度多多个机房，而不是在一个机房或者一个机架里面。
当服务器出现故障，OceanBase客户端能够很快自动感知到，并把服务切到没有故障的服务器上。
通过这一系列组合拳，OceanBase真正做到了持续可用。
图4 高可用：OceanBase VS Oracle图4是OceanBase和Oracle的高可用能力对比。
1.单个节点故障，相比Oracle RAC，OceanBase单个节点故障的影响会小一些，为什么？因为OceanBase的集群规模往往会比较大，单个节点的故障只影响很小一部分数据。
另外，OceanBase的恢复速度也会更快。
OceanBase采用基线加增量的存储引擎，最热的增量数据都是全部在内存的。
当主库出现故障，备库只需要把最后一部分未完成的日志回放出来就能够提供服务，非常快。
而Oracle底层存储是基于页面的，它需要逐步恢复页面，这个过程相对更长。
2.机房整体故障。
OceanBase在蚂蚁都是三机房部署的，当一个机房出现故障，OceanBase也能够做到几十秒恢复，和单个节点故障的恢复速度基本相当。
但是，传统的关系数据库，即使是Oracle也做不到，Oracle RAC不太可能部署到多个机房的。
接下来我们看看OceanBase的性能。
长远来看，性能取决于底层的引擎如何设计，而OceanBase的引擎跟传统数据库的引擎有较大的差别。
图5：两类数据库引擎在互联网里面能够看到各种各样的存储系统，引擎非常多，我认为基本可以分为两个大类。
如图5，第一类是传统关系数据库引擎。
关系数据库本质上是面向磁盘设计的，它把数据分成很多很多的页面，通过页面缓存机制来管理页面，底层的索引是B+树。
这种引擎发展得非常成熟，但是写入性能差，原因是关系数据库的写入放大效应。
用户数据是按行写入的，但是关系数据库却是按页面管理的，有时只写了一行数据，却不得不把整个页面刷入磁盘。
另外一类互联网公司流行的引擎是LSM树。
Google里面有一个很有名的开源系统LevelDB，Facebook基于它又开发了一个类似的系统RocksDB。
这种引擎采用基线加增量的设计，数据首先以增量的形式写入到内存中，当增量达到一个阀值时统一写到磁盘。
这种做法的好处是解决了关系数据库写入放大的问题，但是它的合并代价会比较大，可能出现合并速度赶不上内存写入的情况。
图6 OceanBase存储引擎OceanBase本质上是一个基线加增量的存储引擎，跟关系数据库差别很大，但是我们借鉴了传统关系数据库的优点对引擎进行了优化。
如图6，第一个优化就是合并性能的优化，传统数据库把数据分成很多页面，我们也借鉴了传统数据库的思想，把数据分成很多2MB 为单位的宏块。
执行合并时，如果只有一部分数据修改，那么，只需要合并那些修改过的宏块，而不是把所有没有修改的宏块也一起合并。
通过这个方式，OceanBase的合并代价相比LevelDB和RocksDB都会低很多，这是第一点。
第二，我们会利用OceanBase的分布式机制做优化。
在多机系统中，数据一定是存在多个副本。
OceanBase实现了一个称为轮转合并的机制。
当主副本提供服务时，其它副本可以执行合并；等到其它副本合并完成以后，原来的主副本接着合并，并把流量切到已经合并完成的副本。
通过这种方式，OceanBase把正常服务和合并时间错开，使得合并操作对正常用户请求完全没有干扰。
由于OceanBase采用基线加增量的设计，一部分数据在基线，一部分在增量，原理上每次查询都是既要读基线，也要读增量。
为此，OceanBase做了很多的优化，尤其是针对单行的优化。
OceanBase内部把很多小查询的结果缓存在内存里面，以行为单位，而不是以块为单位。
行缓存包括两个部分，如果这个行存在，缓存这个行的原始数据；否则，缓存布隆过滤器。
OLTP业务大部分操作为小查询，通过小查询优化，OceanBase避免了传统数据库解析整个数据块的开销，达到了接近内存数据库的性能。
另外，由于基线是只读数据，而且内部采用连续存储的方式，OceanBase可以采用比较激进的压缩算法，既能做到高压缩比，又不影响查询性能，大大降低了成本。