天涯若比邻- AWS全球数据库解决方案

议 程

• 全球数据库的挑战

• AWS上全球数据库解决方案

• 客户案例

全球数据库的挑战

全球数据库的原因与挑战

为什么我们需要全球部署数据库？

• 为了灾备，需要将数据库跨region部署

• 为了性能，需要将数据库在多个region分布，贴近我们的用户

全球部署数据库的挑战？

• 搭建多个region内数据库之间复制环境带来的技术挑战

• 维护多个数据库环境带来的运维压力

• 未来的扩展压力

• 尽量降低secondary region与primary region数据库之间的复制延迟

AWS全球基础设施

2006-2010: 4 区域

2016–2018: 9 区域

2011-2015: 7 区域

AWS GovCloud

US-West

Montreal

OhioN. Virginia

Oregon

N. California

São Paulo

IrelandLondon Frankfurt

Paris

Mumbai

Singapore

Sydney

SeoulNingxia

Beijing

Tokyo

BahrainHong Kong

Stockholm

AWS GovCloud

US-East

22 区域

70可用区216边缘节点

Osaka

当地区域 Cape Town

计划建设

Milan

区域与可用区

Availability

Zone AAvailability

Zone B

Datacenter

Datacenter

Datacenter

ZHY Region

Availability

Zone

Availability Zone 可用区

_ 每个region区域至少有两个可用区

_ 每个可用区都由多个数据中心组成

_ 可用区之间地理与网络都是独立设计与运营

_ 可用区专为实现物理冗余而设计，具有弹性，即使

在出现断电、互联网停机、洪水和其他自然灾害的情

况下也能实现不间断的性能。

Availability

Zone C

AWS上全球数据库解决方案

Common data categories and use cases

Relational Key-value Document In-memory Graph Time-series Ledger

QLDBTimestreamNeptuneElastiCacheDocumentDBDynamoDBRDS

Aurora CommercialCommunity

Managed

Cassandra

Service

with MongDB

Compatibility

with

Cassandra

Compatibility

Wide Column

Aurora Global Database

媲美高端商业数据库的速度与可用性

媲美开源数据库的简单性与成本效益

与MySQL及PostgreSQL全面 兼容

按使用量计费的简单定价模式

以托管服务形式交付

Amazon Aurora

Amazon Aurora…以开源级成本交付的企业级数据库

Amazon Aurora: 横向扩展、分布式架构

将Log机制推送至存储层

Master Replica Replica Replica

主

共享存储卷

副 副

SQL

事务

缓存

SQL

事务

缓存

SQL

事务

缓存

不再需要妥协！

AZ1 AZ2 AZ3

写入性能

读取横向扩展

可用区+1容错机制

即时数据库重做恢复

4/6写入仲裁与本地跟踪

“可用区+1”容错机制

为什么？ 在大规模集群体系中，故障总会出现

可用区故障是一种“命中注定”

AZ 1 AZ 2 AZ 3

可用区故障时的仲裁中断

2/3读取2/3 写入

AZ 1 AZ 2 AZ 3

可用区故障时仲裁仍可继续起效

3/6读取4/6写入

如何实现？ 6份副本，每可用区2份

2/3仲裁无法满足需求

写入与读取吞吐量Aurora MySQL的速度可达MySQL的5倍

0

50,000

100,000

150,000

200,000

250,000

MySQL 5.6 MySQL 5.7 MySQL 8.0

Aurora 5.6 Aurora 5.7

0

100,000

200,000

300,000

400,000

500,000

600,000

700,000

800,000

MySQL 5.6 MySQL 5.7 MySQL 8.0

Aurora 5.6 Aurora 5.7

写入吞吐量 读取吞吐量

在R4.16XL实例上运行Sysbench处理250份表，每份表包含20万行

负载条件下的性能变化Amazon Aurora >一致性提升200倍

SysBench OLTP（只写）工作负载与250份表，每表20万行，采用R4.16XL实例

0

2

4

6

8

10

12

0 100 200 300 400 500 600

时间以秒为单位

写入响应时间（秒）Amazon Aurora

MySQL 5.6 on EBS

页面缓存更新Aurora 主节点

30% 读取

70% 写入

Aurora副节点

100% 新读取

共享多可用区存储

MySQL 主节点

30% 读取

70% 写入

MySQL副节点

30% 读取

70% 写入

单线程二进制日志

数据卷 数据卷

Aurora region内高可用与只读副本的实现

使用完整的变更逻辑

相同的写入工作负载

独立存储

以物理方式使用delta变更

不向副节点写入

共享存储

MYSQL 读取扩展 AMAZON AURORA 读取扩展

“在MySQL当中，我们看到复制延迟达到近12分钟。从实际应用的角度来看，这显然是种近乎荒谬的情况。利用Aurora，4个副本的最大读取延迟从未超过20毫秒。”

Binlog Replica Lag (sec.) Aurora物理复制延迟（毫秒）Aurora逻辑复制延迟（秒）

Amazon Aurora MySQL region内逻辑与物理复制延迟

Amazon Aurora cluster

Aurora single-Region failover

Application

W R

Writ

erRead

er

AWS Region

Database storage

M RRead

er

R

Amazon Aurora cluster

Aurora single-Region failover

Application

W R

Writ

er

AWS Region

Database storage

M

Read

er

RWrit

er

MRead

er

RRead

er

R

将远程的readers 提升为 master

快速的跨region灾难恢复

更方便的跨region迁移数据方法

让客户的数据分布到不同region，更贴近用户

次秒级跨region数据复制

更快的灾难恢复和数据贴近用户

快速跨Region 灾难恢复

Reade

r

Writ

er

Applicatio

n

US

East

EU

West

全局低延迟读取

US

East

EU

West

Reade

r

Writ

er

Applicatio

n

AP

Southeast

Reade

r

Reade

r

US

West

Reade

r

全局物理复制

Primary region Secondary region

1ASYNC 4/6 quorum

Continuous backup

AZ

1

Primary

instance

Amazon

S3

AZ

2

Replica

instance

AZ

3

Replica

instance

Replication

server

Replication Fleet

Storage fleet

11

4

AZ

1

Replica

instance

AZ

2

AZ

3

ASYNC 4/6 quorum

Continuous

backup

Amazon

S3

Replica

instance

Replica

instance

Replication

agent

Replication Fleet

Storage fleet

3

3

2

① 主实例将日志记录并行发送到存储节点, 只读实例和复制服务器② 复制服务器将日志流发送到secondary region的复制代理③ 复制代理将日志并行发送给存储节点和只读副本④ 复制服务器可以从存储节点拉日志记录以弥补故障造成的间隙

高吞吐: 即使高达150K writes/second的负载; 复制对性能的影响也是微乎其微低复制延迟: 高负载下依然保持次秒级跨区域复制延迟快速恢复: 区域故障后1分钟以内即可承担全面读写

逻辑复制 物理复制

0

100

200

300

400

500

600

0

50,000

100,000

150,000

200,000

250,000

se

co

nd

s

QP

S

QPS Lag

0.00

1.00

2.00

3.00

4.00

5.00

0

50,000

100,000

150,000

200,000

250,000

seco

nd

s

QP

S

QPS Lag

逻辑复制 vs. 物理复制

全局复制性能

Active-active cross-Region setup with Aurora Global

Database

Version of the application stack is set up in another Region to

recover from disasters and serve fast local reads

Application

W R

Read

erWrit

er

Read

er

Primary Region

Database storage

Application

R

Read

er

Read

er

Secondary Region

Database storage

Read

er

DNS

Failover with Aurora Global Database

Application stack can be spun up in the secondary region and traffic can begin to be

routed there (via DNS) with the promoted writer serving write requests within 1 minute

Application

W R

Read

erWrit

er

Read

er

Primary Region

Database storage

Application

W R

Read

erWrit

er

Read

er

Promoted Region

Database storage

DNS

全局数据库

Primary region (US West) Secondary region (US East)

1ASYNC 4/6 quorum

Continuous backup

Primary

instance

Amazon

S3

Replication

server

Replication Fleet

Storage fleet

1

4

Replica

instance

ASYNC 4/6 quorum

Continuous

backup

Amazon

S3

Replication

agent

Replication Fleet

Storage fleet

3

3

2

持续插入 持续读取

U S West(Writer)

U S East(Reader)

2019-11-28

07:48:15.614.1242019-11-28

07:48:15.725.479

Replication Lag ~110ms

DynamoDB Global Table

为何选择 NoSQL？

针对存储 针对计算优化

规范化/关系型 去规范化/层级型

即席查询 实例化视图

垂直扩展 水平扩展

适合 OLAP 转为大规模 OLTP 构建

SQL NoSQL

Amazon DynamoDB

键-值和文档数据结构

可扩展支持任意负载

全托管NoSQL

访问控制

事件驱动编程

快速与一致性

Table

Items

Attributes

PartitionKey

Sort Key

• Local Secondary Index

• Global Secondary Index

00 55 A954 FFAA00 FF

分区键

分区键唯一的标识了一条记录

分区键用来构建一个非排序的散列索引

使得表可以进行分区，从而满足扩展性的需求

Id = 1

Name = Jim

Hash (1) = 7B

Id = 2

Name = Andy

Dept = Eng

Hash (2) = 48

Id = 3

Name = Kim

Dept = Ops

Hash (3) = CD

Key Space

Partition 3

分区键:排序键

分区键和排序键共同唯一的标识一条记录

在一个分区键决定的散列索引里，数据按照排序键进行排列

00:0 FF:∞

Hash (2) = 48

Customer# = 2

Order# = 10

Item = Pen

Customer# = 2

Order# = 11

Item = Shoes

Customer# = 1

Order# = 10

Item = Toy

Customer# = 1

Order# = 11

Item = Boots

Hash (1) = 7B

Customer# = 3

Order# = 10

Item = Book

Customer# = 3

Order# = 11

Item = Paper

Hash (3) = CD

55 A9:∞54:∞ AAPartition 1 Partition 2

本地二级索引 - Local Secondary Index (LSI)

可以选择与表不同的排序键

每个表分区对应一个索引分区

A1

(partition)

A3

(sort)

A2

(item key)

A1

(partition)

A2

(sort)A3 A4 A5

LSIs A1

(partition)

A4

(sort)

A2

(item key)

A3

(projected)

Table

KEYS_ONLY

INCLUDE A3

A1

(partition)

A5

(sort)

A2

(item key)

A3

(projected)

A4

(projected)ALL

每个分区键可以存储最多10 GB的数据，包括表分区和索引分区的数据量。

全局二级索引 - Global Secondary Index (GSI)

可以选择与表不同的分区键以及排序键

每个索引分区会对应所有的表分区

A1

(partition)A2 A3 A4 A5

A5

(partition)

A4

(sort)

A1

(item key)

A3

(projected)INCLUDE A3

A4

(partition)

A5

(sort)

A1

(item key)

A2

(projected)

A3

(projected)ALL

A2

(partition)

A1

(itemkey)KEYS_ONLY

GSIs

TableGSI的RCUs和WCUs是独立于表的容量而单独计算的

Partitions are three-way replicated

Id = 2

Name = Andy

Dept = Engg

Id = 3

Name = Kim

Dept = Ops

Id = 1

Name = Jim

Id = 2

Name = Andy

Dept = Engg

Id = 3

Name = Kim

Dept = Ops

Id = 1

Name = Jim

Id = 2

Name = Andy

Dept = Engg

Id = 3

Name = Kim

Dept = Ops

Id = 1

Name = Jim

Replica 1

Replica 2

Replica 3

Partition 1 Partition 2 Partition N

客户选择DynamoDB的原因

个位数毫

秒性能

支持

Global

table

自动扩容，

自动分区，

弹性伸缩

架构举例：推送服务中如何应对突发大业务量

推送服务的特点：

• 业务量变化快

• 低峰与高峰数值跃动大

• 难于预测与预留资源

• 订阅关系分布不均匀

• 实时性要求高

完全托管

AWS

Lambda

Amazon

DynamoDBAmazon API

网关

Amazon

DynamoDB

Streams

Lambda

Amazon

S3

Amazon

ES

Amazon

Athena

DynamoDB

查询端在线事务处理（OLTP）端

无服务器

利用DynamoDB进行全球扩展

客户可以采用业务层判断行数据的主写区域来避免冲突

客户可以使用DynamoDB触发Lambda做缓存更新

DynamoDB流

• DynamoDB流是针对表里的数据变化的顺序记录• 在流里，针对表的变化的记录只会出现一次• 在流里的记录的顺序与表上发生修改操作的顺序是一致的• 流里的数据保存24小时，24小时以后自动删除• 可以把表的数据被更新前的值以及更新后的值都写到流里• 流里的数据通过API进行消费

访问DynamoDB流记录

• DynamoDB和DynamoDB流记录使用了不同的终端节点。

• 使用DynamoDB终端节点来访问表和索引。• 要访问DynamoDB流记录，则使用相同区域里的流

的终端节点。• DynamoDB流的终端节点的命名规则为

streams.dynamodb.<region>.amazonaws.com。• 使用DynamoDB Streams Kinesis Adapter来访问

DynamoDB流记录。同时Kinesis Adapter实现了Kinesis Data Streams接口，因此可以使用Kinesis

KCL来消费DynamoDB流的记录。• 也可以使用DynamoDB流的Low-Level的API来消费

DynamoDB流的记录。

DynamoDB流里记录的数据内容

DynamoDB流可以配置为四种写入的数据内容：

• KEYS_ONLY – 只有分区键和排序键的数据被写入流

• NEW_IMAGE – 修改后的整条记录都被写入流

• OLD_IAMGE – 修改前的整条记录都被写入流

• NEW_AND_OLD_IMAGES – 修改前和修改后的整条记录都被写入流

Partition Key

Partition Key

修改前的记录

修改后的记录

DynamoDB的流记录

DynamoDB流的应用场景

• 表之间的数据复制

• 触发器

• 容灾和多区域复制

• 数据汇总

• 数据安全和通知

DynamoDB流和AWS Lambda结合构建触发器

AWS Lambda把数据变化通知出去Amazon Kinesis

Data FirehoseAmazon Simple

Notification Service

Amazon Elasticsearch

Service

DynamoDB流和AWS Lambda触发器举例

StreamReader

多区域复制

Region

区域 1

Region

区域 3

Region

区域 2

StreamReader

StreamReader

创建Global Tables

创建Global Tables

创建Global Tables

管理Global Tables

Amazon CloudWatch metrics

• ReplicationLatency: 预计传播时间• PendingReplicationCount: 写入一个region但尚未传播到其他region的items

written 数

ElastiCache Global Datastore

Redis 概述

高速

大部分命令的时延小于1ms

开源

易学易用

高可用

复制

原子操作

支持事务

内存中的

键值存储

功能强大

200条左右的命令, Lua脚本, 地理空间

, 发布/订阅模式

不同的数据结构Strings, lists, hashes, sets, sorted sets, bitmaps, streams,以及 HyperLogLogs

备份/恢复

快照

很难伸缩难于管理 很难做到高可用

Redis 在管理方面的挑战

成本昂贵

在线伸缩可能会出

需要监控复制的性能

管理工作包括但不仅限于：

硬件部署，软件升级，配

置，以及备份

Redis集群故障会导致系

统性能受影响

需要为运维人员， 流程，

硬件和软件进行投入

Amazon ElastiCache for Redis 介绍--全托管, 兼容 Redis, 内存数据存储在云端

极致性能

内存数据存储并提供小于1ms的响

应时间

全托管

AWS管理所有的硬件以及软件的配

置和监控

易伸缩

通过副本提供读操作的伸缩通过

分片提供写操作的伸缩非中断的

伸缩

兼容 Redis

支持 Redis 5

兼容不同 Redis clients

可靠性

多可用区

深度监控

自动故障转移

安全与合规

Amazon VPC

HIPAA, PCI, FedRAMP

存储和传输中进行加密

身份认证

Redis 使用场景

游戏排行榜

聊天应用

缓存

会话存储 机器学习

实时分析 流媒体地理空间

消息队列

所有的键都在同一台节点上

VPC

Public subnet

Availability zone 1

Public subnet

Availability zone 2

Auto Scaling group

Private subnet Private subnet

Cache node

Cache node

Primary Endpoint Replica Endpoints

Keysp

ace

连接到主节点进行读写操作，连接到副本进行读操作

Elasticache Redis 禁用集群模式 (垂直伸缩)

( CW 指标: CurrItems )

VPC

Public subnet

Availability zone 1

Public subnet

Availability zone 2

Auto Scaling group

Private subnet Private subnet

Cache node

零宕机伸缩

ConfigurationEndpoint

Cache node

Cache node

Cache node

Shard 1 Slot 0 - …

Shard 2 Slot … to …

Keysp

aceShard 3 Slot … to …

Shard 4 Slot … to 16383

根据分片进行分区

Cluster Map

客 户 端 对 键 使 用CRC16 算法计算散列值，并用该散列值对16384取模

DistributionEqual | Custom

Elasticache Redis 集群 (水平伸缩)

特性 启用 禁用

配置数据在不同的分片之间进行分区（最高 15 个），每个分片有一个主节点以及最多5个副本节点

数据保存在一个主节点里，最多具有 5 个副本节点

Redis compliant 与开源的 Redis 集群 API 以及客户端生态完全兼容与开源的 Redis 集群API以及客户端生态完全兼容

集群规模 90 个节点 – 15 个主节点 + 每个分片的 0–5 个副本 6 个节点 ( 1 个主节点 + 0–5 个副本)

伸缩性和性能• 吞吐量随着分片的数量进行伸缩• 内存容量最高可到 9.5 TiB

• 吞吐量由 1 个主节点和5个副本所决定• 内存容量最高到 635 GiB

最大连接数• 主节点 (65,000 x 15 = 975,000)• 副本 (65,000 x 75 = 4,875,000)

• 主节点: 65,000• 副本: (65,000 x 5 = 325,000)

Redis 启用集群模式 vs. 禁用集群模式

Redis 启用集群模式 vs. 禁用集群模式

特性 启用 禁用

伸缩操作集群在线调整尺寸• 水平伸缩：添加或删除分片• 只读活动的伸缩：添加或删除副本

垂直伸缩• 写操作被中断• 禁止在主节点上进行读操作

故障转移 15–30 秒 (无需DNS切换) 30-45 秒 + 额外的 DNS 广播时间

故障转移风险• 部分数据集上的写操作被影响• 读操作无影响

• 整个数据集上的写操作被影响• 读操作无影响

成本

举例: 假设当前的工作负载需要140 GB的缓存

多个小机型组成

15 x cache.r4.large ($0.228hr) = $3.42 hour 184.5 GB

一个大机型组成

1 X cache.r4.8xlarge = $3.64 hr, 203.26 GB

Cache node

主节点 副本

分片

x5

x15

Cache node

异步复制

CW 指标: ReplicationLag

启用集群模式下的故障转移

Cache node

主节点 副本

分片

Cache node

异步复制

检测到故障

启用集群模式下的故障转移

Cache node

主节点 副本

分片

Cache node

异步复制

自动故障转移

(无需DNS广播)

使用故障转移 API 进行测试

SNS 事件: ElastiCache:CacheNodeReplaceComplete

SNS 事件: ElastiCache:FailoverComplete

启用集群模式下的故障转移

Global Datastore in Amazon ElastiCache for Redis

快速、可靠、安全的完全托管式跨区域数据复制

主集群在一个区域，从集群在其它区域

跨区域数据复制延迟通常小于 1 秒

为全球化应用提供低延迟的快速本地数据读取

更快的跨区域灾难恢复

把从集群提升为主集群的时间通常小于1分钟

Global Datastore in Amazon ElastiCache for Redis

• 支持1个主集群（写/读），最多2个从集群（只读）• 目前支持11个AWS区域：美国东部（弗吉尼亚北部）、美国东部

（俄亥俄）、美国西部（加利福尼亚北部）、美国西部（俄勒冈）、亚太地区（首尔）、亚太地区（新加坡）、亚太地区（悉尼）、亚太地区（东京）、欧洲（法兰克福）、欧洲（爱尔兰）和欧洲（伦敦）

• 支持Amazon ElastiCache for Redis 5.0.6 或更高版本• 支持 M5 和 R5 节点• 从集群与主集群具有相同的节点类型、引擎版本、和分片数目• 修改一个集群的本地参数组将应用于整个Global Datastore中的集群

设置 Global Datastore

• 使用现有集群作为主集群

• 或者直接创建一个新集群作为主集群

添加/删除/修改 集群

将从集群提升为主集群

• 在主集群（区域）降级的情况下，手动启动故障转移

• 从集群的故障转移和升级通常会在一分钟内完成

• 当从集群升级为主集群时，ElastiCache 会将旧的主集群（如果可访问）重新配置为从集群，并设置复制以将所有次要区域与新的主集群同步

客户案例

以 游 戏 直 播 为 核 心 业 务

致力于打造全球领先的直播平

台

虎牙

I n t r o d u c t i o n中 国 直 播 行 业 领 军 者

虎牙直播

NimoTV

YomeTV

风靡海外的移动游戏直播平台

国内领先的游戏直播平台

全球化的娱乐直播生力

军

2012YY推出游戏直播业务（虎牙直播前身） 2014

2016虎牙公司正式独立发展战略ALL in移动游戏直播 2018

成功上市NYSE:

HUYA

中国游戏直播第一股

发 展 历程

YY游戏直播正式更名虎牙直播

产 品 矩阵

应用场景:

• 2018年初，虎牙直播上线海外产品 Nimo TV，年底，月活用户已达千万级。

产品成功登陆东南亚及拉美地区，2019 年进入西语市场。

• 数据库后台，动态信息由 Amazon DynamoDB 存储，包括支付、状态、好

友关系等。相对静态的信息则存储在 Aurora 上，如用户的基础信息。

获得的收益:

• 与MySQL相比，5倍以上的性能表现。Aurora 能够自动扩容，且计算和存储

分离。数据量较大时，能够单独升级计算实例，确保性能。

• 支持故障转移。异常情况下，通常只需要几十秒就能够自动实现故障转移，终

端用户无感知。

• 利用全球数据库功能，提升本地用户体验。虎牙直播在 AWS 亚太（新加坡）

区域部署数据库，并在其它区域建立副本。

广州虎牙信息科技有限公司是一家以游戏为核心的直播平台，致力于成为受年轻人欢迎的技术驱动型娱乐社区。虎牙直播覆盖全品类游戏内容，全年直播电竞赛事超过360场。在游戏直播的成功基础上，虎牙直播已发展为包含泛娱乐、真人秀、二次元、户外等内容的综合性互动平台。2018年5月，虎牙直播成功在美国纽交所上市，一个月内涨幅超过400%，市值超过百亿美元，创造直播行业新的里程碑。

”

“

Amazon Aurora 客户案例 – 虎牙直播

https://amazonaws-china.com/cn/solutions/case-studies/huya/

• 统一业务中心

Amazon

Aurora

Amazon DynamoDB Amazon ElastiCache

Amazon

SQS

Amazon SNSAmazon

Autoscaling

关键服务

• 全球快速部署

• 自动灵活扩展

AWS助力虎牙快速出海

• 全球用户实时互

动

总 结

• 全球数据库的挑战

• AWS上全球数据库解决方案

• 客户案例

我们希望您喜欢今天的内容！也请帮助我们完成反馈问卷。

欲获取关于 AWS 的更多信息和技术内容，可以通过以下方式找到我们：

感谢参加 AWS 在线研讨会

微信订阅号：AWS 云计算（awschina）

新浪微博：https://www.weibo.com/amazonaws/

视频中心：http://aws.amazon.bokecc.com/

更多线上活动：https://aws.amazon.com/cn/about-aws/events/webinar/

微信服务号：AWS Builder 俱乐部（amazonaws）

抖音：AWS 云计算（抖音号：266052872）

博客：https://aws.amazon.com/cn/blogs/china/

AWS 中国账户注册

AWS 全球账户注册