介绍
本篇笔记是分布式系统全书最后一部分的内容了，本身不会有新的知识点，主要还是给出一个具体的例子，去全面的了解一个完整的分布式系统的一些细节，包括设计个一些注意点，比如数据存储设计，协调服务，节点通信和分布式计算服务等等。首先设计一个全新的分布式系统的时候，重新回顾一下分布式系统存在的挑战：异构性，开放性，安全性，扩展性，并发控制等等，可见完成一个恶完整的分布式系统还是有很多的功课要做的。
Google 介绍
为什么要介绍Google呢，作为全球搜索引擎的领头羊，他本身就是一个巨大的分布式系统。别小看Google只是一个搜索引擎，在这背后可蕴藏着十分庞杂的部分，因为搜索的查询要去查阅巨大的信息，而且这些信息的存放也是非常有讲究的，Google最早用的是PageRank算法最为搜索算法，具体PageRank的算法步骤不是本文讨论的重点，他是一个网页重要度排名算法，Google就是以每个页面的rank值作为一个参照结果返回给用户的。
Cloud Provider
现在的Google已经不仅仅是单纯的搜索引擎服务了，他也逐渐的变为一个云提供商了，例子就是Google App Engine(GAP)，可以提供SAAS和PAAS，也就是说开发者的应用也可以跑在Google的基础设施上了。
Google系统的整体结果和设计机理
整体结构
这里的结构主要指Google采用的物理结构和公共服务的系统的结构，Google采用的物理结构是普通的PC机作为一个分布式存储和计算服务的媒介，用普通的PC机就减少了低开销的问题，这样就不可避免的就要解决普通PC机易出错的问题了，所以你要有自己的容错机制。当然在这里会有一定的数据副本。整体结构包括3层，最上面是Application层，都是一些具体的应用，中间的是middleware中间层，主要包括了一些Google的分布式服务，最下面的是Google的platform，更加底层的东西了。整个系统结构有几点要求：
1、扩展性，主要体现在3个方面，第一能处理更多的数据，第二能接受更多的查询，第三能找出更好的结果。
2、可用性，主要指容错这块的工作了。
3、开放性，这就关系到整个Web 应用的更深的发展了。
设计原则
下面是系统的设计原则的几条总结：
1、简单化，任何部件做的要单一，API要尽可能能的简单，小化，把他所要求的事情做好。
2、强调性能的重要性。
3、问题的检测机制，发现问题了，要能够通过一定的手段找出问题所在。
Google Infrastructure
Google的基础设施服务在这里分为了3个子领域。
underlying communication paradigms
底层通信方法包括remote invocation远程调用和间接通信的一些方法，具体的实现例子为Protocol Buffer和Google的publish-subscribe发布订阅模式。前者是Google一套自己的序列化框架。
data and coordination service
数据协调服务在这里指的GFS （Google文件系统），Chubby(分布式锁服务)和BigTable（数据存储系统）。
distributed computering service
分布式计算服务在这里指的是MapReduce计算模型和Sawzall更小一层级的计算模型。
underlying communication paradigms
Google的底层通信模块采用的是自己的Protocol Buffer，他是支持RPC调用的，用了框架自带的序列化功能，他的序列化比起java等这些序列化的原理来说，更加的轻量级，并且更加适应Google自己的系统，而且Protocol Buffer平台独立，语言独立。在发布-订阅模式方面，Google采用的是基于主题的发布订阅模式。通过channel去连接各个事件。
Data storage and coordination services
数据协调服务主要指一下3个例子。
GFS
GFS文件系统是构架在Google基础设施上的文件系统，他的组成由GFS Client，GFS chunkserver和GFS master metadata，显然master会监视管理各个chunkServer，一个类似主从结构的关系。在GFS系统中，有一点做的比较好，就是分离了控制关系和数据流关系，意为separation of control and data flows。在一致性上，GFS采用的是被动副本技术，之前的文章也提到过这个概念。
Chubby
Chubby在Google的基础设施服务中是起到一个很关键的作用。他的主要作用包括通过分布式的锁服务来同步分布式的活动，还有一个作用是支持领导选举法，常用于从从副本中选取一个新的副本作为primary。Chubby还能在Google中作为name service。Chubby的系统结构由Chubby cell和Client构成。Chubby cell中包含了一堆的副本数据，客户端通过Chubby Client library 向远程服务端进行请求。说到Chubby就不得不说Paxos算法，这是什么算法呢，他是基于消息传递的算法，功能是使多个Server端保持一致性的算法，说白了就是用于同步数据的算法。算法的步骤共分为3个步骤，角色2个，Coordinator协调者，Replicas副本数据段。
Step1：Coordinator：Propose(seq_number)，Replicas:Promise。
Step2：Coordinator：Accept(value)，Replicas：Acknowledge。
Step3：Coordinator：Commit。
BigTable
提到BigTable，与其说他是分布式存储系统，让我立即想到的更加是他的一种新的存储思想。不同于传统型的表结构的存储。他是一种面向列的稀疏存储。他有一个叫"列簇"的概念，在每行的记录中都会有timestamp的值，这样可以记录多个新老版本的数据了。
Distributed computation services
MapReduce
跟很多人一样，最早听到MapReduce，都是听到了Hadoop，其实MapReduce计算模型很早在Google出现了。MapReduce是一个离线计算模型，顾名思义，分为Map，和Reduce 2个方法。大致过程是首先将输入数据分割，送入Map()方法做处理，将map处理好的结果分区放到指定的位置，然后再由Reduce方法做最终处理。
Sawzall
Sawzall作为一种查询语言，适合于海量数据处理，是一种类型安全的脚本语言，因为Sawzall自身解决了很多的小问题，所以完成MapReduce相同功能的代码量比MapReduce要少很多。他的很多的表达式借鉴了传统的Pascal的形式，看上去非常的简洁。参考文献:<<Distributed Sysytems Concepts And Design>>原版第五版，author：George Coulouris，Jean Dollimore, Tim Kindberg,Gordon
Blair