OceanBase架构介绍 · alibaba_oceanbase Wiki · G

StarExploreBlogFeatures Fork

第一，数据和负载增加后添加机器的操作比较复杂，往往需要人工介入；第二，有些范围查询需要访问几乎所有的分区，例如，按照用户编号分区，查询收藏了一个商品的所有用户需要访问所有的分区；第三，目前广泛使用的关系数据库存储引擎都是针对机械硬盘的特点设计的，不能够完全发挥新硬件(SSD)的能力。另外一种做法是参考分布式表格系统的做法，例如Google Bigtable系统，将大表划分为几万、几十万甚至几百万个子表，子表之间按照主键有序，如果某台服务器发生故障，它上面服务的数据能够在很短的时间内自动迁移到集群中所有的其它服务器。这种方式解决了可扩展性的问题，少量突发的服务器故障或者增加服务器对使用者基本是透明的，能够轻松应对促销或者热点事件等突发流量增长。另外，由于子表是按照主键有序分布的，很好地解决了范围查询的问题。万事有其利必有一弊，分布式表格系统虽然解决了可扩展性问题，但往往无法支持事务，例如Bigtable只支持单行事务，针对同一个user_id下的多条记录的操作都无法保证原子性。而OceanBase希望能够支持跨行跨表事务，这样使用起来会比较方便。最直接的做法是在Bigtable开源实现(如HBase或者Hypertable)的基础上引入两阶段提交(Two-phase Commit)协议支持分布式事务，这种思路在Google的Percolator系统中得到了体现。然而，Percolator系统中事务的平均响应时间达到2~5秒，只能应用在类似网页建库这样的半线上业务中。另外，Bigtable的开源实现也不够成熟，单台服务器能够支持的数据量有限，单个请求的最大响应时间很难得到保证，机器故障等异常处

理机制也有很多比较严重的问题。总体上看，这种做法的工作量和难度超出了项目组的承受能力，因此，我们需要根据业务特点做一些定制。通过分析，我们发现，虽然在线业务的数据量十分庞大，例如几十亿条、上百亿条甚至更多记录，但最近一段时间(例如一天)的修改量往往并不多，通常不超过几千万条到几亿条，因此，OceanBase决定采用单台更新服务器来记录最近一段时间的修改增量，而以前的数据保持不变，称为基准数据。基准数据以类似分布式文件系统的方式存储于多台基准数据服务器中，每次查询都需要把基准数据和增量数据融合后返回给客户端。这样，写事务都集中在单台更新服务器上，避免了复杂的分布式事务，高效地实现了跨行跨表事务；另外，更新服务器上的修改增量能够定期分发到多台基准数据服务器中，避免成为瓶颈，实现了良好的扩展性。当然，单台更新服务器的处理能力总是有一定的限制。因此，更新服务器的硬件配置相对较好，如内存较大、网卡及CPU较好；另外，最近一段时间的更新操作往往总是能够存放在内存中，在软件层面也针对这种场景做了大量的优化。

1.3系统架构1.3.1整体架构图

如图1-1,OceanBase有如下几个部分组成：客户端：用户使用OceanBase的方式和Mysql数据库完全相同，支持JDBC、C客户端访问，等等。基于Mysql数据库开发的应用程序、工具能够直接迁移到OceanBase。 RootServer:管理集群中的所有服务器，tablet数据分布以及副本管理。RootServer一般为一主一备，主备之间数据强同步。 UpdateServer:存储OceanBase系统的增量更新数据。UpdateServer一般为一主一备，主备之间可以配置不同的同步模式。部署时， UpdateServer进程和RootServer进程往往共用物理服务器。 ChunkServer:存储OceanBase系统的基准数据。基准数据一般存储两份或者三份，可配置。

MergeServer:接收并解析用户的SQL请求，经过词法分析、语法分析、查询优化等一系列操作后转发给相应的ChunkServer或者 UpdateServer。如果请求的数据分布在多台ChunkServer上，MergeServer还需要对多台ChunkServer返回的结果进行合并。客户端和 MergeServer之间采用原生的Mysql通信协议，Mysql客户端可以直接访问MergeServer。

如图1-2,OceanBase支持部署多个机房，每个机房部署一个包含RootServer、 MergeServer、ChunkServer以及UpdateServer的完整 OceanBase集群，每个集群由各自的RootServer负责数据划分、负载均衡，集群服务器管理等操作，集群之间数据同步通过主集群的主 UpdateServer往备集群同步增量更新操作日志实现。客户端配置了多个集群的RootServer地址列表，使用者可以设置每个集

群的流量分配比例，客户端根据这个比例将读写操作发往不同的集群。

1.3.2客户端OceanBase客户端与MergeServer通信，目前主要支持如下几种客户端： 1. Mysql客户端：MergeServer兼容Mysql协议，Mysql客户端及相关工具(如Java数据库访问方式JDBC)只需要将服务器的地址设置为任意一台MergeServer的地址就可以直接使用。 2. Java客户端：OceanBase内部部署了多台MergeServer,Java客户端提供对Mysql标准JDBC Driver的封装，并提供流量分配、负载均衡、MergeServer异常处理等功能。简单来讲，Java客户端首先按照一定的策略定位到某台MergeServer,接着调用Mysql JDBC Driver往这台MergeServer发送读写请求。Java客户端实现符合JDBC标准，能够支持Spring、iBatis等Java编程框架。 3. C客户端：OceanBase C客户端的功能和Java客户端类似。它首先按照一定的策略定位到某台MergeServer,接着调用Mysql标准C客户端往这台MergeServer发送读写请求。C客户端的接口和Mysql标准C客户端接口完全相同，因此，能够通过LD_PRELOAD的方式将应用程序依赖的Mysql标准C客户端替换为OceanBase C客户端，而无需修改应用程序的代码。 OceanBase集群有多台MergeServer,这些MergeServer的服务器地址存储在OceanBase服务器端的系统表(与Oracle的系统表类似，存储 OceanBase系统的元数据)内。OceanBase Java/C客户端首先请求服务器端获取MergeServer地址列表，接着按照一定的策略将读写请求发送给某台MergeServer,并负责对出现故障的MergeServer进行容错处理。 Java/C客户端访问OceanBase的流程大致如下： 1)请求RootServer获取集群中MergeServer的地址列表。 2)按照一定的策略选择某台MergeServer发送读写请求。客户端与MergeServer之间的通信协议兼容原生的Mysql协议，因此，只需要调用 Mysql JDBC Driver或者Mysql C客户端这样的标准库即可。客户端支持的策略主要有两种：随机以及一致性哈希。一致性哈希的主要目的是将相同的SQL请求发送到同一台MergeServer,方便MergeServer对查询结果进行缓存。

3) 如果请求MergeServer失败，则从MergeServer列表中重新选择一台MergeServer重试；如果请求某台MergeServer失败超过一定的次数，将这台MergeServer加入黑名单并从MergeServer列表中删除。另外，客户端会定期请求RootServer更新MergeServer地址列表。

如果OceanBase部署多个集群，客户端还需要处理多个集群的流量分配问题。使用者可以设置多个集群之间的流量分配比例，客户端获取到流量分配比例后，按照这个比例将请求发送到不同的集群。

OceanBase程序升级版本时，往往先将备集群的读取流量调整为0，这时所有的读写请求都只发往主集群，接着升级备集群的程序版本。备集群升级完成后将流量逐步切换到备集群观察一段时间，如果没有出现异常，则将所有的流量切到备集群，并将备集群切换为主集群提供写服务。原来的主集群变为新的备集群，升级新的备集群的程序版本后重新分配主备集群的流量比例。

1.3.3 RootServer

RootServer的功能主要包括：集群管理、数据分布以及副本管理。

RootServer管理集群中的所有MergeS …… 此处隐藏：27540字，全部文档内容请下载后查看。喜欢就下载吧 ……