先来扯淡，几天是14年12月31日了，茫茫然，2014就剩最后一天了。这两天国大都放假，我给自己安排了四篇博客欠账，这就是其中的第一篇，简单介绍一些分布式系统的一些概念和设计思想吧。后面三篇分别是**Network File System(NFS)**、**Andrew File System(AFS)**以及**The design of naming schemes**。废话不多说了，开始吧。 ##1. 本文讲什么 前面也提到了，本文会简单介绍一下分布式系统的一些概念和设计思想。 ##2. 分布式系统是什么 分布式系统，听起来好像很玄乎，跟自己没啥关系，但其实你每天都在用，每次你用百度谷歌，都是在使用分布式系统。 分布式系统，说白了就是将很多机器组织在一起，然后获得一些需要的性能，如存储能力、计算能力等等。 ##3. 设计时的考虑 首先来看的话，那么多机器，经常性的会有一两个（甚至更多）机器的磁盘损坏啊、网络故障啊、软件故障甚至就是机器断电了！！总之，林子大了，什么事儿都会碰到。此外还有安全性、系统性能啊等等吧。 - 机器故障 这个怎么处理呢？要想避免机器故障是不可能的。于是乎有两条路，第一条路就是使用高性能机器，其故障概率非常的低，但是这样一来即使能解决问题（事实上几乎不能，降低故障并没有 解决问题 ）也太贵了不划算。于是乎就有这样的设计思路，我们用一大堆普通机器组建分布式系统，通过设计确保整个系统的健壮性而不是某一个机器的健壮。 设计的目标是给用户的感觉是这个系统一直没问题，但是事实上可能系统中的很多机器已经损坏了！ 设计的所有问题在于**如何在不可信机器部件上建立可靠的分布式系统**。话说回来，这跟计算机网络是不是很像！我们在设计网络协议的时候首要的考虑不就是认为网络数据传输不可信么。下面就以通讯为例子看看是怎么设计。 ##4. 通讯 分布式系统各个机器之间主要依靠网络通信，而数据传输本身的可靠性已经被各种网络协议解决了，所以我们不用考虑网络数据传输问题。集中注意力在建立怎样的通讯抽象来管理各个部件之间的通讯。 - 分布式共享内存(**DSM**) 这种系统层面的抽象就是说将整个分布式机群看做一个机器，各个机器的存储都是可以通过虚拟地址来访问。在这种设计下，分布式系统计算有点像多线程了。 具体而言，当需要访问数据的时候（页），如果正好这个页数据在本机，那就直接访问了，否则就产生页错误了，这时候向其他机器发送错误信息，如果在其他机器上找到了页数据，就传输过来。 听起来不错，但是如果一个机器正好就是宕机，访问上面的数据的时候会发生什么？一直页错误却一直找不到数据。 这种设计有待考虑。 - 还有一种设计是编程语言层面的抽象，远程程序调用(**RPC**) 举个例子，两个线程A和B，A线程需要B线程上面的数据来计算，那么与其将B上面的数据拷到本地再计算，不如直接将A线程准备计算的各个参数发给B线程，B线程在本地执行代码之后将结果返回给A线程。 这种设计是不是很炫~~ 至于**RPC**的具体实现这你就不赘述了，感兴趣的话自行看论文去，而且也有开源的实现，需要的时候直接用就可以了 **RPC**的作用可不简简单单这样而已，它可以诠释一种设计模式，使得分布式系统真正成为一种系统。之前的**DSM**设计的系统名义上是一个系统，但是实际上就是一个“集合”，每个机器干的事情基本一样。但是有了**RPC**之后，就不一样了，可以实现分工了，每个机器做自己的任务。这里说的比较笼统，但是很显然，这样的分工实现之后，分布式系统才能成为真正的系统！ 举例子的话有点太多了，简单说一个框架吧，也是我现在正在做的epic存储系统。数据存储在一个个shard中，于是我们有一种机器称之为shardEnvironemnt用来实际存储和管理这些shard、此外用户查询数据需要定位到具体的shardEnvironment机器上，这就需要一种机器称之为shardServer了、然后为了处理机器故障问题，还需要有一种机器专门检测整个系统机器的健康状况，这一类机器称之为shardTracker，一旦发现某个机器宕机了，则可以按照预先的设计执行恢复操作或者其他。这样一来，**机器各司其职， 每个机器只需要做好自己的事情，就可以保证整个系统健康运行**。 哈哈，当然了，事实上远比这里描述的要复杂得多，但是大概思路就是这样，而这，需要归功于**RPC**这种抽象。 但是，具体怎么设计自己的分布式系统则需要考虑实际需要，并不一定要各个机器各司其职啥的，一句话，看情况吧。 ##5. 参考文献 > 1.http://pages.cs.wisc.edu/~remzi/OSTEP/dist-intro.pdf