SequoiaDB 系列之四 :架构简析

在本系列的第一篇中,简述了SequoiaDB的安装,以及一个(伪)集群的部署

第二篇和第三篇对SequoiaDB的集群,做了简单地操作。

在本篇中,将对SequoiaDB的架构进行简单的分析。

因为自身能力有限,对于架构这么高大上的主题,不敢轻言。因此本文会摘抄SequoiaDB官方的描述,加上自己的理解,达到共同学习的目的。

在解析之前,先简单叙述一下分布式系统的CAP理论:

C:代表一致性,即在某时刻,分布式系统中节点数据应该是相同的;

A:代表可用性,即有求必应,在分布式系统中某节点后,统一集群内的其它节点依然能处理远程的请求;

P:代表分区容忍性,即系统中某节点无法连接(故障)后,同属集群内的其它节点能继续提供服务。

由于某些原因,例如网络环境恶劣,灾备处理缺乏等,没有任何一个分布式产品全部实现了CAP。故目前的分布式系统,都是在C和A中做出选择。

如果考虑C,就必须对节点做多个备份,在写数据时,同步写其它备份节点,都完成才返回。大并发情况下,无法及时响应,导致不可用。

如果考虑A,就无法保证数据(真的)写入多个备份节点,而访问备节点的请求获取到的数据可能是过期的数据。

SequoiaDB中,在大规模分布式环境中提供了数据最终一致性的保障。并且提供方式,切合用户业务场景,使数据库系统既具备一定的安全性,又具备一定的可用性。

  • 写操作只在某几个节点上执行后即返回,其它备节点后台定时向主节点同步,在此模式下,高可用性;
  • 写操作在所有节点上执行后再返回,在此模式下,数据更安全,满足一致性。

用户可以权衡自己的应用场景,在创建Collection(集合)的时候,合理设置ReplSize的数值。

SequoiaDB的整体架构图如下:

数据库系统提供一组协调节点,供客户程序访问。可以理解成为数据库的代理。

既然是代理,因此协调节点仅保持客户端的连接,作为请求分发节点将用户请求分发至相应的数据节点,并不保存任何用户数据,。

在协调节点之后,有数据节点组和编目节点组。

编目节点保存系统的元数据信息,像该数据库有几个用户,有几个数据组,数据组中有哪些cs,又有哪些cl,以及创建cl时候的一些选项值等。协调节点通过与编目节点通讯从而了解数据在数据节点中的实际分布。一个或多个编目节点可组成复制组集群。

用户的数据保存在数据节点中。一个或多个数据节点可以构成一个数据节点组(官方称之为分区组,复制组)。数据节点组中每个数据节点都存储该复制组的一份完整数据,又称为复制组实例(或分区组实例);复制组中的数据节点之间采用最终一致性同步数据,不同的复制组中保存的数据无重复。

一个数据节点组,必须有一个主节点,来处理用户的写请求。在考虑更高可用性的场景下,用户的写操作,会先写在主节点上,然后通过同步机制,备节点可以从主节点获取到用户的操作和数据,对节点的数据进行更新和存储。而对于用户的读操作,可以从数据节点上的任何一个节点上得到处理。

其实在集群环境中,所有的读、写等请求,都是从协调(coord)节点分发下来的(当然,直连数据节点组中的节点的情况除外)。上图所描述的,是把协调节点省略掉了(不信?可以看看源码中的pmd模块和rtn模块)。

当集群中,主节点故障了,在集群节点中的通信机制发现之后,会发起选举,从备节点中选择新的主节点,继续接受和处理客户端的请求。关于选举部分,可以通过“二次选举”关键字搜索,维基百科上描述得比较详细 :)

选举是有条件的,在SequoiaDB中,选举的发起,必须是除故障节点外所有节点的数目,大于集群内所有节点数据的一半。可能我描述得不太准确,用公式说明吧。

假设一个集群内,所有节点数是 T(total),故障的节点数是D(Dump),选举的发起条件则是: true == (T-D) > T/2。当然,在正常情况下,集群中的主节点也会自发的在各个节点中进行切换,选择最佳的节点作为集群主节点。

当发现节点故障了,dba对故障进行了处理,并恢复了故障节点。这个时候,恢复的节点会在启动之后,充当从节点,从主节点中拉取数据,做到数据的备份。

图示如下:

SequoiaDB整体架构基于上述机制,但是如何做到,就得慢慢分析其源码。更多简介,请去SequoiaDB官网信息中心获取。

唉,花了好久时间,感觉讲的还是不太清楚,而且只是业务上的架构,并没有涉及技术层面的架构。

在写完上一篇的高级功能之后,才发现居然没有把SequoiaDB的事务处理招牌写上去。

真是败笔啊。

我再找时间,去尝试一下SequoiaDB的事务功能是如何使用的。据说,MongoDB在目前的版本中,也没有提供事务的功能。看样子,其实国产软件,不一定输国外软件。

拙陋之处,敬请海涵。有讲述错误之处,请指出。感谢您能耐心看到这里。

下一篇,可能新写一篇关于SequoiaDB的事务功能的使用介绍,也可能是接着主题,开始分析SequoiaDB的源码部分。敬请关注。

PS:说到国产软件,不禁就会想起给自己和朋友配电脑时候,CPU,硬盘,内存,核心配件,居然都是国外的。龙芯火过一阵之后,也慢慢销匿。在软件产品方面,游戏引擎、数据库等软件,也大都出自国外。在NoSQL慢慢升温的情况下,杀出一个能和MongoDB这个行业老大竞争的SequoiaDB数据库,作为软件从业者,其实心里还是感到很自豪的。由衷希望国内会出现更多的牛逼软件产品,为我国人争光。

=====>THE END<=====

时间: 2024-08-04 03:22:41

SequoiaDB 系列之四 :架构简析的相关文章

三层架构—简析

三层学习完了,第一次验收的时候,自己理解的也不是很到位,后来又重新敲了一遍登陆例子,查阅了一些资料 进行第二次验收才感觉清晰了许多.之前画时序图时我就想过时序图基本上也是很好的体现了三层,当时也和别人讨 论过这个问题.直到学完三层后,更加证明了这一点. 下面我将从理论和实践两个角度总结一下三层. 理论篇 为什么使用三层架构? 说白了,分层的目的是想将复杂问题简单化,也就是面向对象技术所崇尚的"高内聚,低耦合".当业务复杂到 一定程度,数据存储在独立的存储介质时适合用三层架构. 什么是三

ONOS预热篇之架构简析(二)

ONOS是首款专门面向服务提供商和企业骨干网的开源SDN网络操作系统,是由一家名为开放网络实验室(ON.Lab)的非盈利性组织打造的一款商用控制器,并将于美国时间2014年12月5日全球首发.ONOS旨在为服务提供商和企业骨干网提供高可用性(HA).可横向扩展及高性能的网络需求.由于该项目得到了业界各知名大佬包括服务提供商AT&T.NTT,网络供应商Ciena.Ericsson.Fujitsu.Huawei.Intel.NEC,网络运营商Internet2.CNIT.CREATE-NET的资助和

关于Twitter的系统架构简析

三层架构(three-tier architecture)网站的架构设计,传统的做法是三层架构,所谓“传统”不意味着“过时”,新潮的技术不成熟,传统的路子更稳健.(1)表示层(presentation tier):apache web server,主要任务是解析http协议,将请求分发给逻辑层:(2)逻辑层(logic tier):mongrel rails server,利用rails现成的模块,降低工作量:(3)数据层(data tier):mysql: 数据层先来吧:twitter的核心

NETGEAR 系列路由器命令执行漏洞简析

NETGEAR 系列路由器命令执行漏洞简析 2016年12月7日,国外网站exploit-db上爆出一个关于NETGEAR R7000路由器的命令注入漏洞.一时间,各路人马开始忙碌起来.厂商忙于声明和修复,有些人忙于利用,而我们则在复现的过程中寻找漏洞的本质. 一.漏洞简介 1.漏洞简介 2016年12月7日,NETGEAR R7000路由器在exploit-db上被爆出存在远程命令执行漏洞,随着安全研究人员的不断深入,R8000和R6400这两款路由器也被证实有同样的问题. 2016年12月1

SequoiaDB 系列之三 :SequoiaDB的高级功能

上一篇简单描述了一下SequoiaDB的简单CRUD操作,本篇将讲述一下稍微高级点的功能. 部署在我机器上的集群环境,在经过创建名字为"foo"的cs,创建名字为"bar"的cl,以及插入一些数据之后,并没有删除掉,因此在本篇中会继续使用. 首先,我们先看看,在SequoiaDB的安装目录中的database目录里面,有那些文件: ~$ ls /opt/sequoiadb/database/data/11850 我们会发现有几个文件:foo.1.idx,foo.1.

JDK源码简析--java.lang包中的基础类库

题记 JDK,Java Development Kit. 我们必须先认识到,JDK只是,仅仅是一套Java基础类库而已,是Sun公司开发的基础类库,仅此而已,JDK本身和我们自行书写总结的类库,从技术含量来说,还是在一个层级上,它们都是需要被编译成字节码,在JRE中运行的,JDK编译后的结果就是jre/lib下得rt.jar,我们学习使用它的目的是加深对Java的理解,提高我们的Java编码水平. 本系列所有文章基于的JDK版本都是1.7.16. 本节内容 在本节中,简析java.lang包所包

Sql Server来龙去脉系列之四 数据库和文件

在讨论数据库之前我们先要明白一个问题:什么是数据库? 数据库是若干对象的集合,这些对象用来控制和维护数据.一个经典的数据库实例仅仅包含少量的数据库,但用户一般也不会在一个实例上创建太多的数据库.一个数据库实例最多能创建32767个数据库,但是按照实际情况,一般设计是不会达到这个限制值. 为了更明显地说明数据库,数据库包含了以下属性和功能: *. 它是很多对象的集合,比如表.视图.存储过程.约束.对象集合的最大值是2(31) - 1(超过2百亿).一般对象的数量在几百至一万. *. 它维持拥有的用

JDK框架简析--java.lang包中的基础类库、基础数据类型

题记 JDK.Java Development Kit. 我们必须先认识到,JDK不过,不过一套Java基础类库而已,是Sun公司开发的基础类库,仅此而已,JDK本身和我们自行书写总结的类库,从技术含量来说.还是在一个层级上,它们都是须要被编译成字节码.在JRE中执行的,JDK编译后的结果就是jre/lib下的rt.jar,我们学习使用它的目的是加深对Java的理解,提高我们的Java编码水平. 本系列全部文章基于的JDK版本号都是1.7.16. 源代码下载地址:https://jdk7.jav

Android -- MediaPlayer内部实现简析

Android -- MediaPlayer内部实现简析 在之前的博客中,已经介绍了使用MediaPlayer时要注意的内容.现在,这里就通过一个MediaPlayer代码实例,来进一步分析MediaPlayer内部是如何运作.实现的:当然这里的分析只截止到底层调用播放器之前,因为播放器这块实在是没搞懂. 我们使用的例子来源于之前MediaPlayer Playback译文中的官方实例: String url = "http://........"; // your URL here