Ocean设计思路和架构设计

标签: 分布式
31人阅读 评论(0) 收藏 举报
分类:

最近看了杨传辉的《大规模分布式存储系统:原理解析与架构实战》,里面讲了分布式文件系统的经典设计案例和oceanbase的整体设计,看完之后,对于分布式系统的理解有了一个新的层次。

单机系统

首先将一下我们接触比较多的单机系统。对于一些业务很小流量不大的系统,我们经常只会给应用部署到一个机器上。在这个系统上,无论是内存,网络还是处理器处理数据,都可以满足部署的小系统,由于小系统的流量不大,所以承载的压力不大,不会出现系统宕机和奔溃的现象。

当小系统由于用户量提升到某个数量级时,就必须要对小系统进行负载均衡和容错处理,对系统进行各个层次的水平业务拆分和垂直系统分布。例如,根据系统当前的情况和未来可能需要应对的流量,合理分为用户、业务1、业务2等业务线拆分。对于用户业务,可以将用户业务系统部署在3-10台机器不等,也可能更高,或者需要跨机房容灾处理等,从整体的多台机器部署降低单机系统的压力和流量分发。而对于用户模块业务,会涉及到数据库的数据存储,热点数据的缓存,高峰流量的应对,消息通知的队列等等。拿数据库来说,我们将根据情况,将数据按照某种路由规则,分拆到不同的数据库,不同的表中,从而降低单库单表的压力。

下面主要针对阿里OceanBase数据库为例,讲一讲OceanBase设计上值得学习和从中得到的一些思路上的扩展和启发。

OceanBase是阿里集团研发的支持数百TB数量,数十万TPS和数百万QPS的关系型数据库


从图中可以看出,OceanBase分为4个模块,主控服务器RootServer、更新服务器UpdateServer、基线数据服务器ChunkServer和合并服务器MergeServer。

RootServer负责管理所有的服务器,子表分布和副本管理等,采用的是一主一备,主备强同步。

UpdateServer主要存储数据库的增量修改数据,也是一主一备。

ChunkServer负责基数数据的存储和查询,同时会在低峰时期合并UpdateServer的数据。

MergeServer比较关键,主要负责处理客户端的sql执行请求,对sql进行语法词法分析、缓存设计,根据sql的情况,分发到对应的ChunkServer和UpdateServer,如果是读事务,从他们这里拿到数据后,进行合并;如果是写事务,可能会先去ChunkServer拿数据,再去UpdateServer中做更新。

之所以这么设计这几个模块,是考虑到很多的数据其实并非热点数据,且多数历史数据是不会改变的,不变的数据按照一些路由规则,将同一用户的数据尽可能存在一个表中,而对于每个子表的大小也有严格的控制,比如每个子表的大小是256M,子表有唯一全局主键,每个子表有一个主键范围,这个子表主键范围的元数据会存放在RootServer和MergeServer中。MergeServer收到用户的请求后,会根据当前缓存的子表信息发送对应的请求到ChunkServer,获取到数据后,MergeServer会进行合并后返回到客户端。ChunkServer给MergeServer提供读服务,OceanBase会为数据存储2或3份。

对于这种设计,每一个都需要去考虑他们在分布式集群中,每个点可能碰到的机器异常状况,对于这个系统,来看看可靠性和可用性。

RootServer和UpdateServer都是采用一主一备,在发生故障时,可以快速切换到备服务器上。ChunkServer的基线数据,一般会保存多份数据,即使某个机器出现硬盘不可修复,数据在其他机器上也有存储,在RootServer检测到ChunkServer异常时,会根据当前负载均衡的情况,切换或者增加机器,保证系统的可用性。

对于UpdateServer,提供服务时,只有一个主服务提供更新服务,那么这个单点的性能是否会成为整个OceanBase的瓶颈?UpdateServer中的数据都是存在内存中的,据书上介绍,假设每天更新1亿次,每次消耗100字节,每天插入1000万次,每次1000字节,及时这样每天也才20GB,当数据一下很大时,算40GB,对于当今的主流服务器,可以配置96GB,甚至是192GB、384GB,所以内存这一块不会成为瓶颈。

在这种分布式设计时,考虑更多的是机器宕机是经常性的,网络是不可行的,所以需要更多的监控和自动化运维,对于异常服务器的处理,热备减少启动时间,负载均衡上的策略,监控好每一台服务器,保证每台机器负载不至于过高或过低,在容错上,发现ChunkServer查询时出现异常,可以快速重新活切换到另一个可以提供查询的ChunkServer,当发现某太ChunkServer异常多次,那么RootServer对其进行下线操作,保证系统的健壮性。

本文讲到的只是OceanBase设计中很小的一块,如果对OceanBase的设计感兴趣的,也欢迎与我讨论,或者看一下杨传辉大佬(OceanBase核心开发人员)写的这本好书。


查看评论

GBA程序开发入门3

下面我将一一讲解上篇的程序前三行:typedef unsigned char u8;typedef unsigned short u16;typedef unsigned long u32;定义GBA...
  • tangl_99
  • tangl_99
  • 2003-06-13 17:07:00
  • 9440

分布式系统设计原理与方案

一直在思考分布式系统设计的问题,业务对象原封不动的情况下部署在客户端和服务器端,可以根据配置文件选择是连接服务器还是连接本地的数据库,这个问题让我绞尽脑汁,我总是设想的客户端与服务器端通信的方式是最低...
  • hellokobe
  • hellokobe
  • 2016-12-11 22:38:53
  • 408

分布式系统架构设计思路

  • 2017年11月06日 16:28
  • 3.9MB
  • 下载

系统架构设计方法论

系统架构设计方法论 软件架构设计方法体系涵盖了预想架构(PA)概念架构(CA)细化架构(RA)三个阶段和一个贯穿环节。 一、预备架构 预备架构阶段主要是通过系统的理解需求和挖掘潜在需求以...
  • u012921921
  • u012921921
  • 2016-11-07 20:29:02
  • 2599

一种精妙的系统架构设计思想

上次看到那两老外写的APS支撑系统中,在持久层做一个通用接口类,然后使用不同的数据库类型的时候,就来实现这个接口类,感觉这样着实不错。屏蔽了系统在不同的数据库之间转换的时候的差异性,把...
  • lbq1221119
  • lbq1221119
  • 2007-09-03 14:27:00
  • 489

互联网数据库架构设计思路

一 、58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证“读”高可用的方法:复制从库,冗余数据,如下图   ...
  • hjm824
  • hjm824
  • 2016-07-25 17:28:22
  • 990

Android App整体架构设计

Android App整体架构设计
  • stephenxe
  • stephenxe
  • 2016-03-29 21:44:22
  • 643

c#程序设计,框架设计,设计模式

       对于所有要想开发c#底层框架的程序员来说,包括我本人,也是很喜欢用框架的模式来开发项目。第一,框架会让一个开发者觉得项目的思路,结构很清晰,第二,便于项目后期的维护。对于一个项目而言,后...
  • ddllzz2008
  • ddllzz2008
  • 2010-07-20 11:49:00
  • 5188

Jenkins Blue Ocean

Blue Ocean本身是一个Jenkins Plugin,但是的Blue Ocean插件本身没有实现任何功能,他的功能需要其他的插件来扩展;截止到目前,Blue Ocean包含如下的Plugin: ...
  • chen517611641
  • chen517611641
  • 2018-01-31 11:29:55
  • 163

Android App整体架构设计的思考(一)

本文是对我在知乎一个回答的总结和整理,其中的内容大多是对我平时的阅读和实践的总结,希望对Android的开发者有所帮助。但毕竟是个人的经验之谈,难免有疏漏,也欢迎对本文的内容提出建议。 1.架构设计的...
  • luyi325xyz
  • luyi325xyz
  • 2015-01-24 15:04:18
  • 19970
    个人资料
    持之以恒
    等级:
    访问量: 11万+
    积分: 678
    排名: 7万+
    最新评论