随着交流机会的增多(集中在金融行业,规模都在各自领域数一数二),发现大家对 Docker + Kubernetes 的接受程度超乎想象, 并极有兴趣将这套架构应用到 RDS 领域。数据库服务的需求可以简化为:
实现数据零丢失的前提下,提供可接受的服务能力。
因此存储架构的选型至关重要。到底是选择计算存储分离还是本地存储?
本文就这个问题,从以下几点展开:
来分享个人理解。
回顾:计算存储分离,本地存储优缺点
还是从计算存储分离说起。
计算存储分离
先说优点:
以 MySQL 为例
从部分用户的上下文来看,存在如下客观缺点:
选择商用,有 Storage Verdor Lock In 风险。
选择开源,大多数用户(包括沃趣)都测试过 GlusterFS 和 Ceph,针对数据库(Sensitive Lantency)场景,性能完全无法接受。
本地存储
如果在意计算存储分离架构中提到的缺点,本地存储可以有效的打消类似顾虑,无需引入分布式存储,避免Storage Verdor Lock In 风险,所有问题都由DBA 闭环解决,但是,需要依赖数据库自有方案实现数据零丢失。
以 MySQL 为例
还会引入类似问题:
接下来,进入正题,看一下 MySQL 基于本地存储如何实现数据库零丢失。
MySQL 基于本地存储数据零丢失
最常用的是基于 Replication 模型将数据复制到 MySQL Cluster 中所有成员。
MySQL Master-Slave Replication(类似 Oracle DataGuard)提供了基于 binlog 的数据库层的复制模型,在高并发压力下节点间同步数据速率最快,单位时间内的交易量受其他节点的影响极小,该架构可通过 vip 漂移的方式实现 “failover”。
MySQL Master-Slave Replication
但严格意义上来说,这是基于 binlog 的 Asynchronous Replication 模型,因此集群中所有成员存在数据不一致的可能,在“failover”时无法保证数据零丢失。
可见如果基于 Replication 模型,Synchronous Replication 是实现数据零丢失的前提。
传统的 Synchronous Replication 一般会采用两阶段提交或分布式锁,这会带来如下几个问题:
单位时间内事务能力(TPS)会跟集群成员数量成反比
增加集群成员会显著且无法预期的增加事务响应时间
增加了集群成员数据复制的冲突和死锁的可能性
针对以上问题 Galera Cluster 提出 Certification-based Replication 来解决传统 Synchronous Replication 中遇到的问题,实现如下:
Deferred Update Replication 延迟更新复制
这个流程图中,有几个细节需要分享:
GTID 类似 45eec521-2f34-11e0-0800-2a36050b826b:94530586304
94530586304 为 64-bit 有符号整型,用来表示事务在序列中的位置
本地阶段:乐观执行,在事务 Commit 前,假设该 Transcation 在集群中复制时不会产生冲突。
发送阶段:优化同步时间窗口,除去全局排序并获取 GTID 为同步操作,冲突验证和事务应用都为异步,极大的优化了复制效率。
验证阶段:只有收到该事务的所有前置事务后(不能有 “hole”),该事务和所有未执行的前置事务才能并发验证,不然不能保证 Global Ordering,因此这里需要牺牲效率,引入一定的串行化。
需要等待事务 3
于是就有了 Galera Cluster 在 MySQL 分支中的实现 MariaDB Galera Cluster(简称 MGC)和 Percona Xtradb Cluster(简称 PXC)。
为避免“split-brain”问题,需要至少三节点组成集群,对计算资源和存储资源的容量要求至少增加2倍,会进一步降低资源的部署密度。
越来越多的用户也期望通过该方案实现跨 IDC 多活,那么需要在规划阶段想清楚:
IDC 和数据库节点的拓扑架构,以保证在 1 个 IDC 出问题的情况,集群可以持续提供服务。
首先 IDC(物理或逻辑)最少需要3个,再看看数据库节点数量分别为 3、4、5、6、7 的拓扑关系 :
6 数据库节点:
7 数据库节点 : 可支持两种拓扑关系
同时,还有 MySQL Group Replication(简称 MGR)[1],类似 Galera Cluster:
这里还需要提一下 Vitess:
关于 MGR 和 Vitess 网上已有大量介绍,这里不再赘述。
性能对比
在数据零丢失的前提下,看看这几种架构在性能上的对比:
性能对比 1:MGR 5.7.17 / PXC 5.7.14-26.17
测试背景描述:
测试数据 :
来自于 MySQL 官方[2]
测试结果:
在设置 durability 的情况下,MGR ***吞吐约是PXC 5.7.14-26.17(基于 Galera 3 实现)的3倍,优势明显。
以上数据来自于MySQL 官方,公平起见,再来看看 Percona 在相同负载模型下的测试数据。
性能对比 2:MGR 5.7.17 / PXC 5.7.17-29.20 / MariaDB 10.2.5 RC
测试背景描述:
测试数据:
设置 durability,数据来自于 Percona[3]
设置 non-durability,数据来自于 Percona[3]
测试结果:
在负载模型相同的情况下(durability 和 non-durability)PXC 5.7.17-29.20 性能与 MGR 5.7.17 不分伯仲。如果使用 PXC,推荐使用 5.7.17-29.20 或以上版本。
性能对比3:本地存储 / 计算存储分离
为了对比本地存储和计算存储分离,专门使用 MGR + 本地存储架构和 基于分布式存储的计算存储分离架构做性能对比。
测试结果:
在负载模型相同的情况下,前者比后者 OLTP 下降32.12%,Select 下降5.44%,Update 下降 24.18%,Insert 下降 58.18%,Delete 下降 11.44%。
基于 Docker + Kubernetes 的实现
Docker + Kubernetes + MGR / Galera Cluster
在 GitHub 上,可以看到基于 Docker + Kuberetes + PXC 的 demo[4]。需要说明的是,这仅仅是个玩具,离部署到生产环境还有极大差距。
我们已有计划实现满足生产环境的:
并集成到 QFusion 来支持计算存储分离架构和本地存储架构混合部署,架构示意图如下:
目前原型验证阶段已通过,预计2018年Q2发布。
Docker + Kubernetes + Vitess
在 GitHub 上,同样可以看到基于 Docker + Kubernetes 的 demo[5],有兴趣的同学可以玩一下。
性能只是选型需要考量的一部分,要使用到生产环境或者产品化,实际要考量的因素更多:
以现有软硬件的开放程度,各种架构或者产品狭义上的“黑科技”并不多,常常看到的:『xxx 比 xxx 快 xxx 倍』严格来说应该是『xxx 比 xxx 在特定场景 xxx 下快 xxx 倍』。
并不存在“一枪毙命”的“Silver Bullet”,只是 Docker + Kubernetes 为混合部署带来可能。哪种更受青睐,拭目以待,用户会是***的老师。
在麦肯锡公司的播客节目中,西蒙伦敦(Simon London)与麦肯锡公司高级合伙人希琳...
今年发生的冠状病毒疫情使人们更接近数字工作世界,这并不让人感到惊讶。很多组...
随着互联网的发展,现在的网站内容也在逐渐进步,图片更清晰、或者添加了各种各...
【51CTO.com原创稿件】AI、大数据、物联网、云计算等在推动企业创新,驱动业务高...
2017年可谓是网页应用与API之年,开发者不用每次重新发明轮子,而是利用脚手架和...
长期以来,人员缺乏和资金不足是信息安全领域的常态。在当下经济低迷的情况下,...
面试题: Nginx 是如何实现并发的?为什么 Nginx 不使用多线程?Nginx常见的优化手...
无论是个人还是企业,对于网站的需求都是越来越大,很多企业建立网站都是为了进...
【51CTO.com原创稿件】OA可以很小,小到只能打卡; OA也可以很大,大到把ERP和SC...
一般情况下,网站访问速度过慢,延迟低的时候就需要使用cdn对前端进行加速,那么...