开发者社区> 亦征> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

表格存储如何实现高可靠和高可用

简介: 本文会介绍表格存储(阿里自研的一款分布式NoSQL数据库)如何实现数据高可靠和服务高可用,读者可以通过本文了解高可靠和高可用的一些概念和技术,以及分布式系统是如何进行高可靠和高可用设计的,此外,我们还会有一篇专门的文章介绍容灾相关的话题。
+关注继续查看

系列文章

表格存储如何实现高可靠和高可用
表格存储如何实现跨区域的容灾

前言

本文会介绍一款分布式NoSQL如何实现数据高可靠和服务高可用,这是一款云上的NoSQL服务,叫做表格存储。对于分布式NoSQL,大家可能会想到很多名字,比如HBase、Cassandra,AWS的DynamoDB等,这类NoSQL在设计之初就作为一个分布式系统支持超大规模的数据量与并发。此外大家可能还会想到MongoDB和Redis,这两个也提供集群功能,但是一般需要人为的配置sharding和复制集/主从等。

表格存储是阿里自主研发的一款NoSQL服务,在架构设计上参考了google的bigtable论文,与上述的HBase、Cassandra、DynamoDB有一些相似之处。表格存储的一些功能优势可以见下图。

image.png | center | 704x378

本文会重点介绍表格存储在高可靠和高可用方面的技术。表格存储按照11个9的数据可靠性和4个9的服务可用性进行标准设计,作为一款云服务,提供10个9的可靠性和3个9的可用性SLA。

容错、高可靠、高可用

容错、高可靠、高可用是相互关联的几个概念。容错是指系统能够快速检测到软件或硬件的故障并快速从故障中恢复的能力,容错的一般实现方式是冗余,冗余可以保障一份坏掉系统不受影响。高可靠是衡量数据安全性,高可用是衡量系统的可用时间,一般高可靠和高可用的指标都用几个9来表示。

冗余可以实现容错,在数据层面一般表现为数据有多个副本,任意一份损坏不会影响数据完整性,在服务层面可以表现为有多个服务节点,任意一个节点宕机可以将服务迁移到另外的节点。服务高可用会依赖于数据高可靠,因为假如数据的完整性都没有保障,那么谈不上服务的可用性。

容错系统并非一定是高可用的,高可用衡量的是系统的可用时间,假如系统不支持热升级,或者不支持动态扩缩容等,就需要停机进行运维操作,这也是不满足高可用的。

为了获得更高的可用性,可以将两套系统或者多套系统组成主备,搭建容灾,常见的比如同城双机房场景。同城双机房配合自动切换或者快速的人工切换,可以使系统达到更高的可用性。此外,业务可以对应用进行一些弹性的架构设计,在某些服务出现异常时可以自动降级,提高业务的可用性。

表格存储如何实现高可靠和高可用

传统的MySQL主备同步方案,当主库出现故障时,HA模块会将服务迁移到备库,实现高可用。这种方式存在的问题就是,如果要保障数据的强一致,那么一定要主库和备库都写入成功才能返回,即最大保护模式。如果备库出现不可用,主库写入也会失败,所以实际上可用性和一致性无法兼得。

分布式系统中,单机故障率相同情况下,集群中存在单机故障的概率随着集群规模增加而增加,高可靠和高可用成为分布式系统最基本的设计目标。分布式系统中,实现数据高可靠往往通过多副本加Paxos等分布式一致性算法,实现高可用一般是实现快速的故障迁移机制,实现热升级和动态的扩缩容。

那么表格存储如何来实现高可靠和高可用呢,我们首先看下面的架构图:

image.png | center | 704x497

图中的Table Worker代表表格存储的后端服务节点,在它下层有一个系统叫做盘古。盘古是阿里自研的一款先进的分布式存储系统,分布式存储是一种共享存储,Table Worker的任意一个节点都可以访问盘古中的任意一个文件。同时,这也是一种存储与计算分离的架构。

数据高可靠

盘古会专注于解决好分布式存储领域的问题,最基本的就是保证数据高可靠,并且提供强一致性保证。我们使用盘古时配置了三份数据副本,任意一份副本丢失不会影响读写和数据完整性。在写入时,盘古保证至少两份写成功后返回,并在后台修复可能存在的一份副本写入失败的情况。读取时,大部分情况只需要读取一份副本即可。

服务高可用

1. 表格存储的数据模型

首先我们来看一下表格存储的数据模型,如下图所示:

image.png | center | 704x363
表格存储中的一张表由一系列行组成,每行分为主键和属性列,主键可以包含多个主键列,比如用如下方式表示的一个主键就包含三个主键列,三列的类型都为string:
PrimaryKey(pk1:string, pk2: string, pk3: string)
第一列主键列作为分片键(Partition Key),上面的例子中分片键就是pk1。表中的所有数据会按照主键(包含三个主键列)进行排序,按照分片键的范围进行分片。当一个表的数据或者访问量越来越多时,分片就会进行分裂,做动态的弹性扩展,一张较大数据量的表会有几百到几千个分片。

为什么要这样设计?简单来说,一方面所有数据按照主键排序,整个表就可以看作一个巨大的SortedMap,可以在任意主键区间进行范围查询,另一方面第一列主键列是分片键,所有第一列主键列相同的数据都在一个分片中,便于做分片内的功能,比如自增列、分片内的事务、LocalIndex等。

为什么分片键可以做成sorted key,而不是hash key?这是因为我们使用了共享存储的能力,对一个分片进行不断的切分时,不需要搬运数据,而且数据本身就已经被盘古打散了。假如没有共享存储,就需要考虑如何处理数据分布,比如使用一致性hash算法等,分片键一般都是hash key,就失去了全表任意主键区间范围查询的能力。

2. 高可用实现

那么回到正题,如何来实现服务高可用呢?假如一张表有100个分片,这些分片会被不同的worker加载,当一台worker挂掉时,上面的分片会自动迁移到其他可用的worker上。一方面,单台worker故障只会影响一部分分片,不会影响全部分片。另一方面,由于我们使用的是共享存储盘古,任意一台worker都可以加载任意一个分片,计算资源是与存储资源分离的,这就可以把failover过程做的非常快,架构也更加简单。

上面讲的是故障迁移(failover),其实这种架构下也可以做非常灵活的负载均衡(load balance)。当一个分片上的读写压力过大时,可以迅速的将一个分片切分成两个或者更多个分片,加载到不同的Worker上。分片切分时不需要将父分片的数据迁移到子分片中,而是在子分片中建立父分片的文件的link,后续再通过后台的compaction来将数据真正切分出来,消除link。一个分片切分后可以继续向下切分,所有分片会均摊到集群的不同Worker上,充分利用集群的CPU和网络资源。

3. 运维、升级、硬件更新

作为一款云服务,服务端的日常运维、升级、硬件更新换代对于用户而言是完全透明的,这些运维操作也都必须按照高可用标准进行设计。分布式系统的运维是一项非常复杂的工作,假如不使用云服务,运维将是一项繁重而且风险极高的事情,可能经常会有停机升级,还需要处理各种故障。另外,机器硬件也在不断更新换代,云服务为了提供给用户更好的性能,会不断更新新的硬件,建设更好的网络。我们相信,作为一款云上的数据库,可以提供给用户更好的性能,更高的可用性和更好的使用体验。

总结

表格存储通过共享存储盘古来实现数据高可靠,通过快速的failover、灵活的负载均衡实现高可用,在总结上面两个技术实现过程中,我们也可以看到共享存储带给分布式NoSQL很大的优势,而云服务又提供给用户非常大的便利,我们在此再做一些总结:
使用共享存储盘古的优势:

  1. 存储与计算的分离,带来架构的灵活性和功能解耦,存储层和应用层都可以专注于解决自身领域的问题。盘古除了提供基本的数据可靠性保障,还可提供混合存储、冷热数据分离、纠删码、跨可用区的多副本分布等能力。
  2. 盘古带来诸多功能优势的同时,还可以带来性能的提升。随着新硬件和新技术的使用,共享存储的性能已经开始超越应用层通过系统内核接口读写本地磁盘的性能。

表格存储作为一款云服务的优势:

  1. 提供给用户高可靠和高可用的SLA保障,自动化地快速解决分布式系统的单点故障问题、热点问题,运维、升级和硬件更新对用户完全透明,最大化的减少用户的运维负担。
  2. 即开即用,按量付费。通过数据分片和快速的分片切分能力,灵活的适应用户业务量的变化,提供千万级别的qps能力,并且用户也不会因为为了给高峰期预留资源而浪费成本。
  3. 服务端会定期的进行功能迭代和升级,推出新的功能,不断优化性能,提高可用性等,云上用户会得到越来越好的体验。
  4. 有任何使用上的问题,或者表设计上的疑问,都可以加我们钉钉公开群进行交流,我们的研发同学会在其中进行解答,二维码如下,钉钉公开群群号:11789671

image.png | center | 353x400

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
前言 前文架构篇,可以看到 MySQL + Tablestore 非常适合大规模订单系统这一类需求场景。那么,我们首先要做的是,利用 CDC(Change Data Capture) 技术将订单数据实时从 MySQL 同步到 Tablestore 中。对于订单系统的数据同步,我们需要关注同步的稳定性、实时性。目前,存在多款工具可以实现这一功能,他们有的是开源工具如 Canal,有的是阿里云端服务如
0 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 Canal 篇
前言 在基于 MySQL + Tablestore 分层存储架构的大规模订单系统中,利用 CDC 技术将 MySQL 数据同步到 Tablestore 是不可缺少的一步。前文已经详细讲述了如何使用 DTS 向 Tablestore 同步数据。对于中小规模的数据库,或者个人开发者,还可以使用 Canal 从 MySQL 向 Tablestore 同步数据。Canal 部署简单,易于运维,且相比于 D
0 0
基于DTS+Tablestore的海量订单系统架构设计
DTS支持MySQL同步Tablestore Beta版上线,合力打造完善的订单系统。 本文主要介绍一套基于DTS与Tablestore实现一套完善的订单系统架构。实时订单数据主要针对用户侧的实时生产与修改,实例订单数据则是基于数据同步服务DTS,全、增量订阅TP库中的订单数据,从而保证Tablestore中数据与TP库数据的最终一致性。异步同步的方式不可避免的存在延时,但历史订单库在实时性上要求会适当放宽,但其派生出来的数据在服务能力与功能扩展上得到了极大的提升,尤其是Tablestore这种分布式服务能力强、下游计算生态丰富的NoSQL存储服务。
0 0
大数据同步利器: 表格存储全增量一体消费通道
本文会给大家详细介绍表格存储重磅推出的一项新功能--全增量一体数据通道。文章会为大家阐述数据通道的主要使用场景,表格存储数据通道的功能优势,并带大家快速入门如何使用数据通道来消费数据。本文会给大家详细介绍表格存储重磅推出的一项新功能--全增量一体数据通道。
2552 0
阿里云表格存储TableStore全新升级 打造统一在线数据存储平台
3月6日,阿里云表格存储 TableStore 全新升级,突破原生 NoSQL 数据库边界。提供多元索引、二级索引能力,支持数据便捷查询,与计算生态无缝集成,打通数据实时消费通道,打造统一在线数据存储平台,深度挖掘数据与业务价值。
2714 0
解读数据传输DTS技术架构及最佳实践
在阿里云数据库技术峰会上,阿里巴巴高级技术专家付大超(千震)针对于云计算时代最好的数据传输产品阿里云DTS的架构设计、基本原理以及相关的应用场景进行了精彩分享。帮助大家了解了阿里是如何实现异地多活和异构多活的,以及通过DTS轻松实现迁移、双同同步、容灾、订阅的真实案例。
9052 0
基于表格存储的高性能监控数据存储计算方案
概述         随着软件架构的愈发复杂,了解系统现状、调查问题的困难度也增加了很多。此时,一套完善的监控方案能够让开发和运维工程师快速排查问题,更好的维护系统的稳定性。        开源监控方案中,Zabbix、Nagios都是不错的监控软件,可以针对数十万的设备监控数百万的指标,强大的
1185 0
避免单点,云上应如何实现网站高可用和高性能架构设计(系列干货)
高可用架构一直都是云计算技术圈的实践热点,尤其是在互联网应用的典型场景下。云栖社区特别盘点出多位业内技术专家的实践分享干货,希望能帮助同样有此痛点的朋友们。
8160 0
+关注
亦征
阿里云数据库表格存储(TableStore) 高级开发工程师
文章
问答
来源圈子
更多
阿里云存储基于飞天盘古2.0分布式存储系统,产品包括对象存储OSS、块存储Block Storage、共享文件存储NAS、表格存储、日志存储与分析、归档存储及混合云存储等,充分满足用户数据存储和迁移上云需求,连续三年跻身全球云存储魔力象限四强。
+ 订阅
相关文档: 对象存储 文件存储NAS
文章排行榜
最热
最新
相关电子书
更多
效率提升:表格存储实时数据流:Stream的技术揭秘和应用场景
立即下载
POLARDB 产品特性和通用业务场景
立即下载
基于Lindorm快速构建高效的监控系统
立即下载