原帖:http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html
觉得这篇文章很好,尝试翻译了一下,翻得很烂,大家随便看看。
数据同步方案设计
为了避免数据中心成为单点错误节点,当一个数据中心出了严重问题的时候,能很快恢复提供正常服务,双数据中心或者多数据中心是显而易见的解决思路。这种模式一般称为
multihoming
(多宿主)。多数据中心有下面一些模式:
1.
Backup
2.
Master-Slave
3.
Multi-Master
4.
2PC
(
两阶段提交
)
5.
Paxos
我们将由下面几个方面来分析这些模式之间的差异:
Google App Engine
采取是多数据中心间的
Master-slave replication
。他们采取这种模式,主要是为了达成以下的目标:
-
最低的写入延迟
-
数据中心灾难生存能力
-
强一致性保证
没有一个方案能够面面俱到,折中不可避免,你需要根据你认为最重要的需求来选择合适的方案。
仍然有很多概念需要理解,下面我们需要一个一个的来讨论:
一致性
当你写入一个值以后尝试读取那个值会怎么样?
在多数据中心上读写数据是最困难的问题之一。用户会期待某种程度的可靠性和一致性。
-
Weak
(弱一致性)
---
尽量使数据一致,但是数据可能会一致,可能会不一致。就像
MemoryCached
做的那样。如果应用类型对数据一致性要求并不高的话,比如
VOIP
应用,
RTP
应用,在线视屏,多人网络游戏等,这个程度的一致性就已足够。
-
Eventual(
最终一致性
)-
--
你不会马上就能看到你写入的东西,但最终会看到你写入的东西。
Email
就是一个很好的例子,人家发给你的邮件你不会马上就能收到,但过会儿你终将会收到。
DNS
改动传播,
SMTP
,
Amazon S3, SimpleDB,
搜索引擎建立索引都是这类。这类一致性对数据存储还不是很理想。
-
Strong
(强一致性)
---
这个级别的一致性非常适合存储结构化的数据。你能马上读到你刚写入的数据。这也能减低程序开发的难度。
Google App Engine,
文件系统,
Microsoft Azure,
大多数关系型数据库都以这种方式工作。
当我们跨越多个数据中心读写数据时,应该提供哪个级别的一致性保证呢?我们可以放弃一些保证,但是我们应当知道在放弃这些保证的同时我们得到了什么。
Transactions
(事务)一种扩展
形式的一致性,特指在一个行为包含多步操作时的一致性
事务的四种属性:正确性,一致性,有效性,原子性
但你一个行为跨越多个数据中心时,你要保证你行为支持事务是很困难的,因为太多的地方可能出错,而且延迟会大大提高。
为什么我们需要多数据中心呢?
-
性能
---
我们可以让用户的操作发生在地理上更接近他的数据中心上。光的速度限制着数据传输的速度,一旦一个用户的操作跨越世界时,让数据中心接近用户的效果就会显著出来了。数据传输时经过太多的路由器也会增加延迟。让用户的操作路由到地理上更接近他的数据中心上无疑是种好的做法。
CDN
(内容分发网络)就是这么干的,特别在处理静态数据的时候。它们把数据放得到处都是。
为什么我们会选择单数据中心呢?
-
在单数据中心上操作更简单:更低的带宽消耗,更低的延迟,更容易操作,更容易编码。
-
在多数据中心上操作更困难:更高的成本,更高的延迟,操作更困难,编码更困难
-
特别困难情形是你读写的是结构化的数据,而且你允许在多个点写入。这会带来数据一致性的问题。在面对距离和错误的同时,保持数据的一致性并非易事。
你不同的架构选择
-
Single Datacenter(
单数据中心
)
。不再为在多数据中心上操作烦神。这是最简单的选项,大多数人都是这么干的。但是如果你的数据中心挂了,你会丢失数据,而且你的网站也不能提供服务了。
-
Bunkerize(
单数据中心强化
)
。为你终极的数据中心加固一条马奇诺防线。保证你的数据中心无论如何也不会挂掉。
SimpleDB
和
Azure
就是使用这种策略。
-
Single Master
(单主节点)
。选择一个数据中心为主节点,主节点支持写操作,别的节点(从节点)会复制主节点的数据。从节点仅仅支持读操作。
-
看起来不错,但不是伟大的
-
数据复制是异步的,所以仍然有数据遗失的窗口期(数据复制没完成,
master
挂掉)。
-
在出错时,从数据中心可能与
master
数据中心并不一致。
-
这种方式在金融机构比较流行
-
可以根据数据中心的地理位置选择比较近的读取。数据中心的一致性取决于实现的技术。写操作还是限定在
master
数据中心上。
-
Multi-Master(
多主数据中心
)
。真正的多数据中心,圣杯级的。所有的数据中心都同时支持读
/
写操作。事务真正需要起效。这个真的非常难。
-
有人仅仅在两个数据中心上实现这种模式。纳斯达克有两个位置非常接近的数据中心(低延迟),所有的事务都会以
2
阶段提交的方式执行,而且它需要很低的延迟。
-
这个模式在超过
2
个数据中心时是非常难以实现的。因为你将为排队延迟,路由延迟,光速(电磁波的速度)付出代价。你不得不在多个数据中心间对话。你会提高你的数据处理能力和吞吐量,但是你毫无疑问地会在延迟上付出代价。
你要选择如何做呢?
下面是这些方案的权衡比较:
|
Backup
|
Master/slave
|
Multi-Master
|
2PC
|
Paxos
|
一致性
|
弱
|
最终一致性
|
最终一致性
|
强一致性
|
强一致性
|
事务
|
无
|
支持
|
本地支持(限于一个数据中心内)
|
支持
|
支持
|
延迟
|
低
|
低
|
低
|
高
|
高
|
吞吐量
|
高
|
高
|
高
|
低
|
中等
|
数据丢失
|
多
|
一些
|
一些
|
无
|
无
|
故障转移
|
不能
|
只读
|
读
/
写
|
读
/
写
|
读
/
写
|
选择一个特定的方案我们将得到何种类型的一致性,事务支持,延迟,吞吐量?是否会在出错的时候丢失数据?会丢失多少?我们何时可以故障转移,比如子在维护或者移动东西的时候,或者让一个数据中心废弃?我们怎么可以做到故障转移?这个方案是如何支持故障转移的?
-
Backup
-
给你的数据制作一份拷贝,这种做法是隐秘和安全的。一般来说它只能提供弱一致性。通常不能提供事务支持。这种方案可以用来为系统第一次内部运行时数据备份,生产环境你最好别这么干。一旦出错它会丢失你自上次备份以来的新数据。而且你不得不停止你的服务直到你在另外一个数据中心上使用备份复原好数据。
数据写入
Master
导致数据也会被复制到一个或者多个
Slave
。
由于复制是异步的,对降低写延迟和提高吞吐量有利。
除非你非常小心,这种方案只能提高弱一致性或者最终一致性。
由于你的数据在多个数据中心中有多份拷贝,所以当出错时,你会丢失一些数据,但不会太多。故障转移仅仅支持读操作直到你把
Master
角色转移到另一个数据中心上。
Datastore
当前就是使用了这种机制。真正的多数据中心
(Multi-Master
)
会增加延迟,因为你不得不在各个数据中心间增加一些额外的通讯消耗。
App Engine
已经在写操作上比较慢了,所以这种额外的负担更显得痛苦。
Master/Slave
模式会让你得到大多数的好处的同时,还会让写操作延迟较低。
在多个数据中心上同时支持写操作。
你必须设计好如何在写入数据冲突的时候合并结果。这种做法跟异步复制很相像,但是你支持多点写入。你最好选择实现最终一致性。写入数据不会立刻影响到所有的数据中心。但这样的话又貌似回到了原点。我们追求
Backup
和
Master/Slave
所不能提供的强一致性。这种系统运行有了显而易见的变化,因为我们必须考虑写入合并的问题。
为了合并你必须找一个一种方法在写入操作上加入时序性。这里没有全局时钟,而且写操作是并行发生的。你甚至不知道那个动作是最先发生的。因此你需要使用时间戳,本地的时间戳
+
偏斜,本地的版本号,分布式的共识协议(
chubby
,
zookeeper
)等手段。
这种方案无法支持全局事务。因为在多点同时写的情况下,你是无法保证事务支持的。你不得不设想接下来怎么做。
App Engine
想要强一致性,因为这会使编写应用更简单,因为他们没有采取这个方案。
-
Two Phase Commit
(
2PC
)
-
两阶段提交是在分布式系统上实现事务的一种协议。
半分布式
-
因为一定存在一个主仲裁者(
master coordinator
)
.
它是同步的。所有的事务会串行的进入
master
,这会减低吞吐量和增加延迟。
如果你很在乎吞吐量的话,你绝对不能考虑这种方案。这种方案没有单点错误。由于额外的协调通讯,它会提高延迟。一个写操作的时间要达到
200
毫秒的级别。
然而这种方案能工作。你将写入所有的数据中心或者什么都没写入。你会得到强一致性和事务支持。
-
Paxos
—
一组独立节点为一个提案达成大多数共识的协议。
协议:有提案提出和达成共识
2
个步骤。只要有多数的节点同意提案通过,那么提案将会被视为通过。
跟
2PC
不同的是它是完全分布式的。不存在单个的主协调者。
很多事务可以并行执行。
写操作会有高延迟因为这种协议需要
2
轮额外的协调。
要做到如此,不得不为一次写操作付出
150
毫秒延迟,相对关系型数据库一此写入操作大概
5
毫秒来说,这未免有点高。
他们倾向使用物理上很接近的数据中心,然而一些天生的多数据中心开销(路由器延迟等)也会显得太高。就算是在一个数据中心内部也还是显得太慢了。
Paxos
仍然在
goolge
内部使用得很多。特别是在锁服务方面(
chubby
),用来协调所有的跨数据中心的一切操作。特别用来协调状态在数据中心间转移。如果你的应用为一个数据中心提供数据,当它需要把数据转移到另外一个数据中心时,这些协调的工作就需要通过
Paxos
。
Paxos
也会用来管理
memcache
和离线处理。
杂项
Entity Groups
是
AppEgine
的一致性单元。
Entity Groups
上的操作都是串行化的。同时所有在
Entity Group
上的提交的操作的日志都会有备份。这样做是为了维持一致性和提供事务支持。
Entity Groups
本质上就是分片(
shards
)
.
分片(
sharding
)是为了提供伸缩性因为它使你可以处理很多写操作。
Datastore
就是按照
entity group
块大小来分片的。
BuddyPoke
有
4
千万的用户,每个用户都有一个
entity group
,也就是有
4
千万个不同的分片。
Eating your own dog food(
自食其力
)
在
google
内部是一种常用战略。先让人们在内部反复的使用一个新的功能。反复使用不断改进直到真正发布出去。
AppEngine
把关系型数据库看成竞争者,就像
Azure
跟
SimpleDB
一样。往关系型数据库插入一条数据只需要几毫秒。
AppEngine
写入一条数据需要
30
到
40
毫秒
,
读却很快。他们喜欢这种权衡折中,因为对于
web
应用来说,读往往比写多得多。
讨论
我尚有一些事不明。他们是否考虑过
MVCC
(
Multi-version
concurrent control---
多版本同步控制)的实现模式?这可能很有趣,但是它未被列为一种选项。显然目前
Google
对于内存中的数据伸缩性实现还不是很适当。
对于强一致性的偏好,以至它被一再列为主要设计目标,主要是让程序员编程更容易。就算如此在
google app engine
上编程已经非常困难了。由于它的局限性和缺乏关系型数据库的编程特性,在编写一个可伸缩的应用的时候,程序员被迫承接了太多的责任。我很好奇,如果放弃了强一致性,那相比而言又会如何呢?
我真的很欣赏那个特性评价矩阵,以及
google app engine
做技术选择的讨论。
对于
Google app
engine
来说,写已经相当慢了,因此它没有太多的动态余量用在太多层次之间的协调通讯。这类东西是
Google
的开发人员在设计评审会议上讨论的东西,但是他们通常很少让这类东西流传出来。我貌似听见
Ryan
说道:为什么我们不能得到一切?但是事实就是如此,我们不能得到一切,总得有所取舍。感谢
Ryan
的分享。
分享到:
相关推荐
多数据中心高可靠性解决方案 数据中心三级等保建设方案 数据中心机房可视化能源管理系统方案 《数据中心机房管理制度》 XXX数据中心机房服务器管理制度 数据中心门禁卡使用管理规范 VDFW技术详解 SSL外置数据中心...
云数据中心与传统数据中心的区别?如何建设? 云计算数据中心与传统IDC(互联网数据中心)与EDC(企业数据中心)的区别是什么 ?传统数据中心与云计算数据中心的区别在于应对的业务模式不同。传统IDC多数是 支撑电信...
T/GZBC XX—2020 3 医疗数据中心建设规范 第 3 部分 科研数据中心 1 范围 本标准规定了科研数据中心科研数据规范、数据治理要求、数据储存和对外服务等方面内容。 本标准适用于医疗机构全疾病谱科研数据中心建设,不...
政务云数据中心解决方案.pptx 桂林市房地产交易管理数据中心解决方案.doc 华盛云数据中心解决方案.pptx 华为云数据中心解决方案.pptx 基于超融合架构的数据中心云化解决方案....SDN技术多活数据中心解决方案分享.pptx
本标准可为以上人群进行数据中心场地基础设施的运维管理提供系统性的建议,也 可作为用户评价数据中心场地基础设施运维服务水平的参考。 本标准专注于数据中心场地基础设施层面。 本标准从安全、人员、设施以及运行...
MongoDB multiple Data center,官方推荐的指导文档。
15.1 多数据中心互联规划-1 15.2 多数据中心互联规划-2 15.3 多数据中心互联规划-3 16.1 数据中心网络安全规划 17.1 敏捷数据中心SDN网络设计(上) 18.1 敏捷数据中心SDN网络设计(中)- 18.2 敏捷数据中心SDN...
数据中心建设规划方案数据中心建设规划方案数据中心建设规划方案数据中心建设规划方案数据中心建设规划方案数据中心建设规划方案数据中心建设规划方案数据中心建设规划方案数据中心建设规划方案数据中心建设规划方案...
数据中心节能改造调研检查表 (仅供内部使用) (For internal use only) 数据中心机房现场数据采集表全文共7页,当前为第1页。 数据中心机房现场数据采集表全文共7页,当前为第1页。 目录 1. 目的 3 2. 适用范围 3 3. ...
为了消除数据中心存在的安全隐患,为医学院校核心数据提供可靠、便捷的使用环境。方法:从使用、管理、审计等方面全面分析了医学院校数据中心所面临的安全威胁,提出了将数据中心安全区域划分为管理、应用和存储备份为...
通过系统 化的能耗审计能够提供数据中心能耗的实时概况和模型, 明确了解数据中心的总体能耗以及 能耗的具体分布状况,同时可以建立基线供未来改造规划之用。 能耗的审计可以通过手动计量, 也可以采用先进的自动化...
由于我国新医改不断深入,医院与社会对医院综合信息资源处理与应用的需求不断提高,各种...大数据量多用户同步数据交换,与区域数据中心接口与运行环境完全不同。不能将建立区域数据中心技术,照搬到医院数据中心的建立
淘宝官方数据中心旨在将数据还给卖家,提高卖家的数据安全性,并且提供看数据、学数据、用数据一体化的服务,帮助卖家更好的经营店铺! 商家数据中心 ---------让数据成为一种核心竞争力 2012年是数据被重视的一年...
数据中心建设的必要性 随着经济发展,以前大家觉得遥不可及的科技已经慢慢融入我们的生活(微信支付,网上购物等)这些科技能够融入我们的生活主要依据大数据,互联网及人工智能。而数据的产生、存储、计算技术...
什么是数据中心及数据中心的特点全文共3页,当前为第1页。什么是数据中心及数据中心的特点全文共3页,当前为第1页。什么是数据中心及数据中心的特点 什么是数据中心及数据中心的特点全文共3页,当前为第1页。 什么是...
用的数据中心 距离地铁的距离 不宜小于 100m 不宜小于 80m 不包括地铁公司自身 使用的数据中心 在飞机航道范围 内建设数据中心 距离飞机场 不宜小于8000m 不宜小于1600m - 不包括机场自身使用 的数据中心 距离甲、...
CDR具有数据共享特点C 贯穿医护人员的整个诊疗过程,准确提供病患信息 CDR数据具有实时性特点 CDR具备多类型数据处理能力 CDR具备可扩展性 医疗数据的安全性 面向患者提供完整的诊疗信息DR定义 4 临床数据中心CDR-...
(整理)《商业银行数据中心监管指引》-..pdf(整理)《商业银行数据中心监管指引》-..pdf(整理)《商业银行数据中心监管指引》-..pdf(整理)《商业银行数据中心监管指引》-..pdf(整理)《商业银行数据中心监管指引》-..pdf...
数据中心建设概述 数据中心建设方式分析和对比 数据中心建设不确定性分析 数据中心建设的发展方向预则 数据中心建设建议 目录 数据中心建设全文共23页,当前为第2页。 上世纪九十年代,互联网兴起,虽经2000年...