Couchbase 是一个具备高性能、可扩展性和可 用性强的数据库引擎。它可让开发人员经过 NoSQL 的键值存储(二进制或者JSON)或者使用 N1QL 的形式对数据进行操做(N1QL 是很是相似于 SQL 的一种语法操做 JSON 数据的方式)。以如今总体架构来看,Couchbase 是往分布式数据库的方向发展下去。算法
分布式数据库通常是从单机关系数据库扩展而来,用于存储结构化数据。分布式数据库采用二维表格组织数据,提供SQL关系查询语言,支持多表关联,嵌套子查询等复杂操做,并提供数据库事务以及并发控制。数据库
Couchbase 的数据服务在单机、 集群安装,集群、多集群通讯都是很是简单去作的。在必定的场景下,使用Couchbase是很是好的选择。缓存
本文主要使用分布式储存的一些理论来分析 Couchbase 的数据服务的分布式数据储存模型。安全
数据储存
存储引擎直接决定了存储系统可以提供的性能和功能。在 Couchbase 的数据储存分对象缓存和数据储存引擎。以下图所示应用对数据的操做首先是对内存操做,而后才会异步更新至数据储存引擎中。对于 Couchbase,数据层 以 memcached API 对数据进行交互,系统在 memcached 程序中嵌入持久化引擎代码对数据进行缓存、复制、持久化等操做,持久化操做就是同步数据至 CouchDB 中(新版代码中增长了forestDB引擎)。对于图中的复制是在第四节中详细介绍。服务器
对象缓存
对象缓存提供先内存储存的架构,使得的读与写的操做下降了延迟。对象储存是属于在内存中以hash储存方式储存,支持增、删、改,以及随机读取操做,其哈希分片大小,根据所储存的数据项的量会动态变更。以下图,对象缓存根据key值得相关运算计算出分片的哈希值,而后会根据根据所储存项的多少,在一个哈希分片以链表串连数据,每一个内存中储存的数据结构见图所示。网络
注:对于对象缓存大小的设置,在管理员操做平台中,能够为每一个bucket设置对应的RAM内存的大小。
数据储存引擎
Couchstore(Couchbase的数据储存引擎)是按vbucket为单位的文件储存在文件系统中。Couchstore应用B+树算法经过key值去快速指向它的内容。 为了高效的写, Couchstore应用了追加写的模型(见下文介绍)对每个文件进行高效和安全的写操做。数据结构
注:在Couchbase中,bucket是用户所操做文档数据的集合,vbucket是系统平均划分bucket的数据进行分片数据的集合。架构
B+树结构
追加写模型
追加写模式即全部的写操做只追加数据到文件尾部,而不修改老的数据,系统中的数据删除或者更新后,原来的数据成为垃圾数据,这能够加快磁盘的写速度。若是 这些数据一直保存下去,文件会无限膨胀下去,为了解决这个问题,须要按期执行合并操做以实现垃圾回收。所谓合并操做,即将全部老数据文件中的数据扫描一遍 并生成新的数据文件,这里的合并其实就是对同一个key的多个操做以只保留最新一个的原则进行删除,每次合并后,新生成的数据文件就再也不有冗余数据了。负载均衡
数据分布
分布式系统区别于传统单机系统在于可以将数据分布到多个节点,并在多个节点之间实现负载均衡。
Couchbase 数据分布
在Couchbase数据分布是按计算分配到多个节点上,每一个节点都储存两部分数据有效数据和副本数据,客户端对数据的操做主要是按照节点中对应的有效数据进行操做,执行压力会部分到不一样的节点,相似以下图所示:
- 均匀的分配有效vbucket和副本vbucket到不一样服务器节点中;
- 把有效数据与副本数据划分到不一样物理节点中;
- 在复制多份数据时,尽可能有其它节点进行数据传播;
- 扩展时,以最小化数据迁移量进行复制。
负载均衡
在 Couchbase 中,咱们所操做的每个bucket会逻辑划分为1024个vbucket,其数据的储存基于每一个vbucket储存而且每一个 vbucket都会映射到相对应的服务器节点,这种储存结构的方式叫作集群映射。以下图所示,当应用与Couchbase服务器交互时,会经过SDK的与 服务器数据进行交互,当应用操做某一个的bucket的key值时,在SDK中会经过哈希的方式计算,使用公式crc32(key)%1024肯定key 值是属于1024个vbucket中的某个,而后根据vbucket所映射的节点服务器对数据进行操做。
复制
为了保证分布式存储系统的高可靠和高可用,数据在系统中通常存储多个副本。当某个副本所在的存储节点出现故障时,分布式存储系统可以自动将服务切换到其它的副本,从而实现自动容错。
复制的概述
- 强同步复制:复制协议要求主备同步成功才能够返回客户端写成功,这种协议称为强同步协议。强同步协议提供了强一致性,可是,若是备副本出现问题将阻塞写操做,系统可用性较差。
- 异步复制:在异步复制下,主副本不须要等待备副本的回应,只须要本地修改为功就能够告知客户端写操做成功。异步复制的好处在于系统可用性较好,可是一致性较差,若是主副本发生不可恢复故障,可能丢失最后一部分更新操做。
Couchbase 中的复制
集群内复制(单集群内复制)
集群内复制主要针对同一个集群中多个节点的数据进行多份复制备份,而且复制的份数会分布到不一样的节点中。在数据分布中咱们知道每一个节点都会储存有效的 vbucket和复制的vbucket。以下图展现,当应用对对数据进行写操做,此操做会先到集群节点中所对应有效的vbucket的数据进行写操做,并 且有效的vbucket节点会根据DCP协议传输写操做的变动传输到复制的vbucket所对应的节点,对复制的vbucket进行变动。可复制的 vbucket的份数,能够在操做bucket的时候进行配置,备份数量为1-3份。
- 内存级的储存。此种模式是当应用写数据时,当数据已经储存到内存中后,就会返回正确回复给应用,同步其它节点和持久化储存都是由异步处理。此种模式速度最快,相对的容错性也是最差。
- 内存+持久化级的储存。此种模式是当应用写数据时,只有数据储存在内存和硬盘中后,才会返回正确回复给应用,同步其它节点是异步处理方式。此种模式,若是单节点出现问题,数据可能出现不一致性。
- 内存+备份节点级的储存。此种模式是当应用写数据时,只有数据储存同步到其它节点的内存中时,才会返回正确回复给应用,持久话处理都是异步处理,应用是能够选择出同步数据的节点数量。此种模式保证了数据必定备份和容灾,可是也有必定可能数据没有持久话会丢失。
- 内存+持久化+备份节点的储存。此种模式是当应用写数据时,数据存储必须知足所须要的节点中内存复制和持久化都完成后,才能够返回正确给应用。这种模式保证即便有效vbucket节点机器出现没法恢复的故障。
注:在程序流程中,第2,3,4种储存方式持久化数量节点和备份节点的数量是由客户端进行设置和进行检测的。第1种储存方式客户端是直接进行操做而且没有检测过程的。
- 读取时,获取一致性的的数据。此种方式是当数据更新后全部的应用读到数据都是同样的。主要原理是读和写都是操做有效vbucket。
- 读取时,能够获取不一致性的数据。此种方式适合对于对数据一致性不是很重要,对可用性比较注重的场景。主要原理是读的时候,有效vbucket不可用时,数据会从备份vbucket中获取数据。
跨数据中心复制(多集群间复制)
跨数据中心复制主要是针对多个集群间的数据复制,此种复制主要以异步的方式经过XDCR协议同步数据到其它集群中备份,从而实现单集群或机房出现问题级的容灾。跨数据中心复制是以bucket为单位进行复制的,在管理员操做界面能够经过配置XDCR来进行此种复制方式,下图为跨数据中心复制示例图:
容错
- 单集群中能够设置auto-failover的方式来实现自动容错。管理员可在后台设置auto-failover的时间,当集群检测到单点机器超过设置的时间后,则选取uuid/seqno为最新的机器的副本数据激活,更新vbucket所映射的服务器来恢复业务。
- Couchbase现阶段没有实现多集群容错的方式,在设计应用的时候,须要检测单机群问题,进行集群的切换来恢复业务。
分布式协议
DCP (Database Change Protocol)
- 有序复制,基于每一个vbucket存在一个顺序序列号,同步时根据序列号进行更新;
- 重启恢复,当同步链接中断后,从新链接后,会对冲突数据进行恢复;
- 一致性,使用快照数据同步数据统一性;
- 内存间复制。
XDCR (Cross Data Center Replication)
- 基于bucket复制,两个集群的同一个bucket能够实现单向或者双向复制;
- 经过DCP协议保持持续性复制,一个XDCR链接中包括多个DCP数据流。这些流能够根据不一样的分区对目的集群进行同步复制;
- 支持多种集群拓扑复制。集群间能够经过单向,双向复制。多个集群能够实现1对1,1对多,多对1等的集群复制拓扑图;
- 安全复制。数据中心见传输数据可使用SSL进行加密;
- 最终一致性和解决数据冲突的能力。当出现冲突数据,会使用元数据的序列值,CAS值,文档标签和过时时间限制对数据进行冲突解决。
跨机房部署
- 集群总体切换,这种方式是两个机房部署了相同的Couchbase集群,由XDCP以异步方式同步集群副本,当出现问题时,可切换集群。这种方式的问题是 当主机房总体出现故障时,有两种选择:要么将服务切换到备机房,忍受数据丢失的风险;要么中止服务,直到主机房恢复为止。所以,主备机房切换每每是手工 的,容许用户根据业务的特色选择“丢失数据”或者“中止服务”。
- 单个集群跨机房,这种方式是将单个集群部署到多个机房,容许不一样数据分片的主副本位于不一样的机房。这种方式主要是考虑到写数据的时候,一致性比较强的数据是同步到每一个节点中才算写成功的案例,当机房出现问题时,大部分数据是能够继续可用。
Couchbase的分布式及理论
- 一致性:读操做老是能读取到以前完成的写操做结果,知足这个条件的系统称为强一致系统,这里的“以前”通常对同一个客户端而言;
- 可用性:读写操做在单台机器发生故障的状况下仍然可以正常执行,而不须要等待发生故障的机器重启或者其上的服务迁移到其它机器;
- 分区可容忍性:机器故障、网络故障、机房停电等异常状况下仍然可以知足一致性和可用性。
分布式存储系统要求可以自动容错,也就是说,分区可容忍性老是须要知足的,所以,一致性和写操做的可用性不能同时知足。
部署拓扑结构 | 故障范围保护 | CAP 平衡 | 评论 |
单Couchbase服务器机群 | 节点故障(例如, 节点以前硬件故障,通讯失败) | 能够配置成CP,而且能够经过配置auto failover操做获得有效性 | 当故障时,Couchbase服务器容许有效的读和配置 auto-failover一个不多的时间超时来恢复写的可用性。 |
多Couchbase服务器机群单向XDCR复制 | 节点或机群故障 (例如: 数据中心天然灾害) | AP是经过XDCR机群间单向复制来防止节点故障或者 | 单向复制能够用于同步数据在秒级计算能力数据中心中,
目的集群数据就能够经过最终一致性的数据用来读取和当原集群故障时,升级为读写集群(主从模式业务,读写分离)
|
多Couchbase服务器机群双向XDCR复制 | 节点或机群故障(例如: 数据中心天然灾害) | AP是经过XDCR机群间双向向复制来防止节点故障或者 | 双向服务能够用于有效/划分计算能力的跨数据中心,目的集群数据就能够读取和写最终一致性的数据在稳定状态,你会发现两个集群在操做同一个数据时发生了冲突,许多用户使用写在不一样的划分段来让各自集群来处理避免冲突。(多主模式) |
基本可用(Basically Available)
基本可用是指分布式系统在出现故障的时候,容许损失部分可用性,即保证核心可用。
电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。
软状态( Soft State)
软状态是指容许系统存在中间状态,而该中间状态不会影响系统总体可用性。分布式存储中通常一份数据至少会有三个副本,容许不一样节点间副本同步的延时就是软状态的体现。
最终一致性( Eventual Consistency)
最终一致性是指系统中的全部数据副本通过必定时间后,最终可以达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊状况。
总结
以上大体介绍 Couchbase 服务器的数据的分布式储存架构及一些分布式理论的知识。
Couchbase在系统分布式方面提供了基础的支持,然而在分布 式储存的一致性、可用性和分区性是须要有所权衡,Couchbase 服务器提供了多种选择的方式让用户根据本身的业务场景选择不一样的非功能性的需求点,来 实现对数据的储存。