网站开发文档编写,wordpress说明,传奇霸主,推广案例目录 五、分布式存储系统Megastore#xff08;一#xff09;设计目标及方案选择#xff08;二#xff09;Megastore数据模型#xff08;三#xff09;Megastore中的事务及并发控制#xff08;四#xff09;Megastore基本架构#xff08;五#xff09;核心技术——复制… 目录 五、分布式存储系统Megastore一设计目标及方案选择二Megastore数据模型三Megastore中的事务及并发控制四Megastore基本架构五核心技术——复制六产品性能及控制措施 六、大规模分布式系统的监控基础架构Dapper一基本设计目标二Dapper监控系统简介三关键性技术四常用Dapper工具五Dapper使用经验 五、分布式存储系统Megastore 互联网的迅速发展带来了新的数据应用场景和传统的数据存储有别的是互联网上的应用对于数据的可用性和系统的扩展性具有很高的要求。一般的互联网应用都要求能够做到7天×24小时的不间断服务达不到的话则会带来较差的用户体验。热门的应用往往会在短时间内经历急剧的用户数量增长这就要求系统具有良好的可扩展性。在互联网的应用中为了达到好的可扩展性常常会采用 NosQL 存储方式。但是从应用程序的构建方面来看传统的关系型数据库又有着 NoSQL 所不具备的优势。Google 设计和构建了用于互联网中交互式服务的分布式存储系统 Megastore该系统成功的将关系型数据库和 NoSOL 的特点与优势进行了融合。将向大家介绍该系统着重突出 Megastore 设计与构建过程中的核心思想和技术。
一设计目标及方案选择
设计目标 设计一种介于传统的关系型数据库和NoSQL之间的存储技术尽可能达到高可用性和高可扩展性的统一。
两种方法
针对可用性的要求实现了一个同步的、容错的、适合远距离传输的复制机制。针对可扩展性的要求将整个大的数据分割成很多小的数据分区每个数据分区连同它自身的日志存放在 NoSQL 数据库中具体来说就是存放在 Bigtable 中。
数据的分区和复制 在Megastore中这些小的数据分区被称为实体组集Entity Groups。每个实体组集包含若干的实体组Entity Group相当于分区中表的概念。一个实体组中包含很多的实体Entity相当于表中记录的概念。 二Megastore数据模型
传统的关系型数据库不合适的三个原因 传统的关系型数据库是通过连接Join来满足用户的需求的但是就 Megastore 而言这种数据模型是不合适的主要有以下三个原因
1对于高负载的交互式应用来说可预期的性能提升要比使用一种代价高昂的查询语言所带来的好处多。 2Megastore 所面对的应用是读远多于写因此好的选择是将读操作所需要做的工作尽可能地转移到写操作上。 3在 Bigtable 这样的键/值存储系统中存储和查询级联数据Hierarchical Data是很方便的。
Megastore数据模型怎么设计
1、细粒度控制的数据模型和模式语言 同关系型数据库一样Megastore的数据模型是在模式schema中定义的且是强类型的strongly typed每个模式都由一系列的表tables构成表又包含有一系列的实体entities每实体中包含一系列属性properties属性是命名的且具有类型这些类型包括字符型strings、数字类型numbers或者 Google 的 Protocol Buffers。
2、照片共享服务数据模型实例 表Photo就是一个子表因为它声明了一个外键User则是一个根表一个Megastore实例中可以有若干个不同的根表表示不同类型的实体组集三种不同属性设置既有必须的如user_id也有可选的如thumbnail_urlPhoto中的可重复类型的tag属性
3、Megastore索引 4、Bigtable中存储情况
行键Row KeyUser.namePhoto.timePhoto.tagPhoto._url101John101,50012:30:01Dinner, Paris…101,50212:15:22Betty, Paris…102Mary
三Megastore中的事务及并发控制
Megastore 提供的三种读
current总是在单个实体组中完成。snapshot总是在单个实体组中完成。系统取出已知的最后一个完整提交的事务的时间戳接着从这个位置读数据。inconsistent忽略日志的状态直接读取最新的值。
完整的事务周期 Megastore中的事务机制 四Megastore基本架构 Megastore 基本架构如下。在Megastore中共有三种副本完整副本Full Replica见证者副本Witness Replica只读副本Read-only Replica。 1、快速读 利用本地读取实现快速读带来更好的用户体验及更低的延迟。关键是保证选择的副本上数据是最新的。协调者是一个服务该服务分布在每个副本的数据中心里面。它的主要作用就是跟踪一个实体组集合。协调者的状态是由写算法来保证。
2、快速写 如果一次写成功那么下一次写的时候就跳过准备过程直接进入接受阶段。Megastore 没有使用专门的主服务器而是使用 leaders。leader 主要是来裁决哪个写入的值可以获取0号提议。客户端、网络及 Bigtable 的故障都会导致一个写操作处于不确定的状态。
五核心技术——复制
1、复制的日志 每个副本都存有记录所有更新的数据。Megastore 允许副本不按顺序接受日志这些日志将独立的存储在 Bigtable 中。 2、数据读取 1本地查询Query Local 查询本地副本的协调者来决定这个实体组上数据是否已经是最新的。
2发现位置Find Position 确定一个最高的已经提交的日志位置选择一个己经在该位置上生效的副本。
本地读取Local Read如果本地查询确定当前的本地副本已经是最新的则从副本中的最高日志位置和时间戳读取数据。这实际上就是前面提到的快速读。多数派读取Majority Read如果本地副本不是最新的或者本地查询或本地读取超时从一个副本的多数派中发现最大的日志位置然后从中选取一个读取。选择一个响应最快或者最新的副本并不一定就是本地副本。
3追赶 一旦某个副本被选中就采取如下方式使其追赶到已知的最大日志位置处。
对于所选副本中所有不知道共识值Consensus Value的日志位置、从其他的副本中读取值。对于任意的没有任何可用的已提交的值的日志位置将会利用 Paxos 算法发起一次无操作的写。Paxos 将会促使绝大多数副本达成一个共识值——可能是无操作的写也可能是以前的一次写操作。接下来就所有未生效的日志位置生效成上面达成的共识值以此来达到一种分布式一致状态。
4验证Validate 如果本地副本被选中且数据不是最新发送一个验证消息到协调者断定entity group, replica对(entity group, replica) pair能够反馈所有提交的写操作。无须等待回应如果请求失败下一个读操作会重试。
5查询数据Query Data 在所选的副本中利用日志位置的时间戳读取数据。如果所选的副本不可用了重新选中一个替代副本执行追赶操作然后从中读取数据。单个的较大查询结果可能是从多个副本中汇聚而来。 需要指出的是本地查询和本地读取是并行执行的。
3、数据写入 1接受leader请求 leader 接受值作为0号提议。这实际上就是前面介绍的快速写方法。如果成功跳至步骤3。
2准备在所有的副本上使用一个比其当前所见的日志位置更高的提议号进行 Paxos 准备阶段。将值替换成拥有最高提议号的那个值。
3接受请求剩余的副本接受该值如果大多数副本拒绝这个值返回步骤2。
4失效将不接受值的副本上的协调者进行失效操作。
5生效将值的更新在尽可能多的副本上生效。如果选择的值和原来提议的有冲突返回一个冲突错误。
4、协调者的可用性 协调者在系统中是比较重要的——协调者的进程运行在每个数据中心。每次的写操作中都要涉及协调者因此协调者的故障将会导致系统的不可用。Megastore 使用了 Chubby 锁服务为了处理请求一个协调者必须持有多数锁。一旦因为出现问题导致它丢失了大部分锁协调者就会恢复到一个默认保守状态。除了可用性问题对于协调者的读写协议必须满足一系列的竞争条件。
六产品性能及控制措施
可用性的分布情况 Megastore 在 Google 中已经部署和使用了若干年有超过100个产品使用 Megastore 作为其存储系统。从图中可以看出绝大多数产品具有极高的可用性99.999%。这表明 Megastore 系统的设计是非常成功的基本达到了预期目标。 产品延迟情况的分布 应用程序的平均读取延迟在万分之一毫秒之内平均写入延迟在100至400毫秒之间。避免Megastore的性能下降可采取以下三种应对方法
1重新选择路由使客户端绕开出现问题的副本。 2将出现问题副本上的协调者禁用确保问题的影响降至最小。 3禁用整个副本。 六、大规模分布式系统的监控基础架构Dapper Google 认为系统出现故障是一种常态基于这种设计理念Google 的工程师们结合 Google 的实际开发出了 Dapper。这是目前所知的第一种公开其实现的大规模分布式系统的监控基础架构。
一基本设计目标 两个基本要求
监控系统设计两个基本要求。
1广泛可部署性Ubiquitous Deployment设计出的监控系统应当能够对尽可能多的 Google 服务进行监控。 2不间断的监控Google 的服务是全天候的如果不能对 Google 的后台同样进行全天候的监控很可能会错过某些无法再现的关键性故障。
三个基本设计目标
低开销这个是广泛可部署性的必然要求。监控系统的开销越低对于原系统的影响就越小系统的开发人员也就越愿意接受这个监控系统。对应用层透明监控系统对程序员应当是不可见的。如果监控系统的使用需要程序开发人员对其底层的一些细节进行调整才能正常工作的话这个监控系统肯定不是一个完善的监控系统。可扩展性Google的服务增长速度是惊人的设计出的系统至少在未来几年里要能够满足Google服务和集群的需求。
二Dapper监控系统简介
1、基本概念 在监控系统中记录下所有这些消息不难如何将这些消息记录同特定的请求本例中的X关联起来才是分布式监控系统设计中需要解决的关键性问题之一。下图是典型分布式系统的请求及应答过程。 Dapper监控系统的三个基本概念
监控树Trace Tree一个同特定事件相关的所有消息区间Span区间实际上就是一条记录注释Annotation注释主要用来辅助推断区间关系也可以包含一些自定义的内容 区间Helper.Call的详细信息 区间包含了来自客户端的注释信息“Start”、“Client Send”、“Client Recv” 和 “End”也包含了来自服务器端的注释信息“Server Recv”、“foo” 和 “Server Send”。
2、监控信息的汇总
Dapper监控信息的汇总的步骤
1将区间的数据写入到本地的日志文件 2所有机器上的本地日志文件汇集 3汇集后的数据写入到Bigtable存储库中 三关键性技术
1、轻量级核心功能库 最关键的代码基础是基本RPC、线程和控制流函数库的实现主要功能是实现区间创建、抽样和在本地磁盘上记录日志。将复杂的功能实现限制在一个轻量级的核心功能库中保证了Dapper的监控过程基本对应用层透明。
2、二次抽样技术 利用二次抽样技术成功地解决了低开销及广泛可部署性的问题。
第一次抽样 实践中设计人员发现当抽样率低至1/1024时也能够产生足够多的有效监控数据即在1024个请求中抽取1个进行监控也是可行的从而可以捕获有效数据。
第二次抽样 发生在数据写入 Bigtable 前具体方法是将监控 id 散列成一个标量z0≤z≤1如果某个区间的z小于事先定义好的汇总抽样系数则保留这个区间并将它写入 Bigtable否则丢弃。
四常用Dapper工具
1、Dapper存储API Dapper的 “存储API” 简称为 DAPI提供了对分散在区域 Dapper 存储库DEPOTS的监控记录的直接访问。一般有以下三种方式访问这些记录。
1通过监控id访问Access by Trace id 利用全局唯一的监控id直接访问所需的监控数据
2块访问Bulk Access 借助MapReduce对数以十亿计的Dapper监控数据的并行访问
3索引访问Indexed Access Dapper存储库支持单索引Single Index
2、Dapper用户界面
1选择监控对象 2用户对这些执行模式进行排序并选择查看更多细节 3分布式执行模式图形化描述呈现给用户 4根据最初选择的开销度量标准Dapper以频度直方图的形式将步骤3中选中的执行模式的开销分布展示出来 5用户选择了某个监控样例后就会进入所谓的监控审查视图Trace Inspection View 五Dapper使用经验
1、新服务部署中Dapper的使用 利用 Dapper 对系统延迟情况进行一系列的跟踪进而发现存在的问题。
2、定位长尾延迟Addressing Long Tail Latency 端到端性能和关键路径上的网络延迟有着极大的关系。 3、推断服务间的依存关系Inferring Service Dependencies Google 的 “服务依存关系” 项目使用监控注释和 DPAI 的 MapReduce 接口实现了服务依存关系确定的自动化。
4、确定不同服务的网络使用情况 利用 Dapper 平台构建了一个连续不断更新的控制台用来显示内部集群网络通信中最活跃的应用层终端。
5、分层的共享式存储系统 没有 Dapper 之类的工具的情况下对于这种共享式服务资源的争用也同样难以调试。
6、利用Dapper进行“火拼”Firefighting with Dapper Dapper 用户可以通过和 Dapper 守护进程的直接通信将所需的最新数据汇总在一起。
