第九讲GoogleMegastoreDapper解读.ppt

设计目标及方案选择 数据分区和复制 Megastore数据模型 数据模型实例 索引（Index） Bigtable中数据存储情况 Megastore中的事务及并发控制 Megastore中的事务及并发控制 Megastore中的事务机制 Megastore的基本架构 复制的日志 数据读取 数据写入 协调者的可用性 可用性分布情况 产品延迟情况分布 设计目标 基本概念 基本概念 基本概念 监控信息汇总 轻量级核心功能库 二次抽样技术 Dapper存储API Dapper用户界面 Dapper用户界面 Dapper用户界面 Dapper使用经验 Dapper使用经验 Dapper使用经验 ?应用程序的平均读取延迟在万分之一毫秒之内，平均写入延迟在100至400毫秒之间 ?避免Megastore的性能下降，可采取以下三种应对方法（可能结合使用）： （1）重新选择路由使客户端绕开出现问题的副本 （2）将出现问题副本上的协调者禁用，确保问题的影响降至最小。 （3）禁用整个副本 平均延迟的分布 需要指出：Megastore已经是Google相对过时的存储技术。Google目前正在使用的存储系统是Spanner架构，Spanner的设计目标是能够控制一百万到一千万台服务器，Spanner最强大之处在于能够在50毫秒之内为数据传递提供通道 Google Dapper ?基本设计目标 ?Dapper监控系统简介 ?关键性技术 ? 常用Dapper工具 ?Dapper使用经验 用户将一个关键字通过Google的输入框传到Google的后台，在我们看来很简单的一次有哪些信誉好的足球投注网站实际上涉及了众多Google后台子系统，这些子系统的运行状态都需要进行监控 广泛可部署性 不间断的监控 监控系统设计两个基本要求 03 02 01 广泛可部署性的必然要求。监控系统的开销越低，对于原系统的影响就越小，系统的开发人员也就越愿意接受这个监控系统 Google的服务增长速度是惊人的，设计出的系统至少在未来几年里要能够满足Google服务和集群的需求 如果监控系统的使用需要程序开发人员对其底层的一些细节进行调整才能正常工作的话，这个监控系统肯定不是一个完善的监控系统 低开销 应用层透明 可扩展性 大规模分布式系统的监控基础架构Dapper ?基本设计目标 ?Dapper监控系统简介 ?关键性技术 ? 常用Dapper工具 ?Dapper使用经验 ?图中，用户发出请求X，前端A发现该请求的处理需要涉及服务器B和服务器C，因此A又向B和C发出两个RPC（远程过程调用）。B收到后立刻做出响应，但是C在接到后发现它还需要调用服务器D和E才能完成请求X，因此C对D和E分别发出了RPC，D和E接到后分别做出了应答，收到D和E的应答之后C才向A做出响应，在接收到B和C的应答之后A才对用户请求X做出一个应答X ?在监控系统中记录下所有这些消息不难，如何将这些消息记录同特定的请求（本例中的X）关联起来才是分布式监控系统设计中需要解决的关键性问题之一 典型分布式系统的请求及应答过程 方案一 黑盒（Black Box）方案——方案比较轻便，但在消息关系判断过程中，主要是利用一些统计学知识来进行推断，有时不是很准确 方案二 基于注释的方案 ——利用应用程序或中间件给每条记录赋予一个全局性的标示符，借此将相关消息串联起来（Google最终选择 ） ?Dapper监控系统中三个基本概念：监控树（Trace Tree）、区间（Span）和注释（Annotation） ?图示是一个典型的监控树，实际上就是一个同特定事件相关的按照一定的规律以树的形式组织起来所有消息，每一个节点称为一个区间（一条记录），所有记录联系在一起就构成了对某个事件的完整监控。 ?每个区间包括如下的内容：区间名（Span Name）、区间id（Span id）、父id（Parent id）和监控id（Trace id） 监控树 监控id图中并没有列出，一棵监控树中所有区间的监控id相同，随机分配且唯一 区间Helper.Call的详细信息 ?图中区间包含来自客户端的注释信息：“Start”、“Client Send”、“Client Recv”和“End”，也包含来自服务器端的注释信息：“Server Recv”、“foo”和“Server Send”。 ?除“foo”是用户自定义的注释外，其他的注释信息都是和时间相关的信息。 ?Dapper不但支持用户进行简单的文本方式的注释，还支持键-值对方式的注释 监控信息的汇总 监控信息汇总 （1）将区间的数据写入到本地的日志文件 （2）所有机器上的本地日志文件汇集 （3）