【整理学习Hadoop】Hadoop学习基础之二：分布式

haixin3036

分布式系统就是将系统的应用层，数据层或其它部分构架成分布（物理和逻辑上的都可以）状（通常是网状）。分布式系统通常是为了增强系统的可扩展性、稳定性和执行效率。比如在线游戏通常就是分布系统，里面所谓的“区”就是分布系统里子例程。而分布式数据库其实也可以称作分布式系统，数据持久化层是分布的（数据存在不同的数据库中，可交互，有一套综管系统来维护数据的完整性和准确性）。　　
所以说分布式系统更准确地说是一种系统构架概念，不是一种技术。
　　在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件（middleware）负责实现这个模型。一个著名的分布式系统的例子是万维网（World Wide Web），在万维网中，所有的一切看起来就好像是一个文档（Web页面）一样。
　　在计算机网络中，这种统一性、模型以及其中的软件都不存在。用户看到的是实际的机器，计算机网络并没有使这些机器看起来是统一的。如果这些机器有不同的硬件或者不同的操作系统，那么，这些差异对于用户来说都是完全可见的。如果一个用户希望在一台远程机器上运行一个程序，那么，他必须登陆到远程机器上，然后在那台机器上运行该程序。
　　分布式系统和计算机网络系统的共同点是：多数分布式系统是建立在计算机网络之上的，所以分布式系统与计算机网络在物理结构上是基本相同的。
　　他们的区别在于：分布式操作系统的设计思想和网络操作系统是不同的，这决定了他们在结构、工作方式和功能上也不同。网络操作系统要求网络用户在使用网络资源时首先必须了解网络资源，网络用户必须知道网络中各个计算机的功能与配置、软件资源、网络文件结构等情况，在网络中如果用户要读一个共享文件时，用户必须知道这个文件放在哪一台计算机的哪一个目录下；分布式操作系统是以全局方式管理系统资源的，它可以为用户任意调度网络资源，并且调度过程是“透明”的。当用户提交一个作业时，分布式操作系统能够根据需要在系统中选择最合适的处理器，将用户的作业提交到该处理程序，在处理器完成作业后，将结果传给用户。在这个过程中，用户并不会意识到有多个处理器的存在，这个系统就像是一个处理器一样。
　　同集中式系统相比较，分布式系统的另一个潜在的优势在于它的高可靠性。通过把工作负载分散到众多的机器上，单个芯片故障最多只会使一台机器停机，而其它机器不会受任何影响。理想条件下，某一时刻如果有5%的计算机出现故障，系统将仍能继续工作，只不过损失5%的性能。对于关键性的应用，如核反应堆或飞机的控制系统，采用分布式系统来实现主要是考虑到它可以获得高可靠性
　　业务对象原封不动的情况下部署在客户端和服务器端，可以根据配置文件选择是连接服务器还是连接本地的数据库，这个问题让我绞尽脑汁，我总是设想的客户端与服务器端通信的方式是最低端的Socket。花了两个晚上研究CSLA.NET框架关于数据门户这块代码，才发现问题的关键所在：客户端与服务器端通信不能采用最低端的Socket，而要用高端的WebService、.NET Remoting或者是自己定义一种协议等，只要它们支持客户端直接根据服务器端的服务URL、类名、方法名和方法参数四个信息就可以调用服务器对应的类和方法就行。

　　说明：本文中所表达的思想与CSLA.NET有很大区别，不要看了本文就以为是CSLA.NET的设计思想，也不要以为本文错误的解释了CSLA.NET，这不是一篇介绍CSLA.NET的文章，但纯思想上它们是相同的。

• 分布式系统的部署
  

　　平常我们都说三层架构，我认为它是一个广义的模型，更多层的设计可以合并相邻几层的方式最终回归到三层这个宽泛的概念上来，我的意思是：这些都只是概念，忘记这些概念去实际分析设计会离这些概念更近一些。
　　接下来我要把三层变的更简单点，两层，数据访问层合并到业务层，统称为业务层，因为我们面对的问题不是分层的问题，而是分布式系统中各层应该怎么部署的问题。在CSLA.NET书中也说到业务层和数据访问层放到同一台机器上可以提高性能和容错性。因此他们俩的合并不影响分布式系统的部署。
　　不过要解释的是数据库系统（CSLA.NET中说的数据存储和管理层）并没有考虑到三层中来，也就是它不包含在数据访问层中，如果把它算进来，那么它是在数据访问层之下单独存在的。
　　综上，在分布式系统部署角度考虑的分层实际是三层：界面层、业务层（包含数据访问层的业务层）、数据存储层。
　　下面举例说明可能的部署情景，带阴影的框框表示一台机器，虚线框表示根据使用场合可有可无，虚横线表示从此处划开单独出服务器。在B/S应用中，Web浏览器为客户端，其他全部为服务器。在C/S应用中，处在最上层的界面层+业务层为客户端，其他为服务器。
非分布式系统的部署

　　单机版

　　两三台机器
分布式系统的部署

　　分布式的Web系统

　　分布式的C/S系统

　　有几点要说明：
　　1． 客户端上的验证等业务逻辑是不可信的，因此任何一种部署都需要服务器端包含业务层；
　　2． 为了开发、维护和部署中的高度可伸缩性，图中的各业务层所包含的代码都是一模一样的；
　　3． 因为第2点，所以我遇到了业务层的同一个操作是与其他机器上的业务层通信还是访问数据库这个难题。

解决业务层的数据访问问题
　　这个问题是关键问题，也就是上面几点说明中的第3个问题，为了解决这个问题我们引入数据门户的概念。
　　下面以WebService为例说明：界面层访问本机的业务对象的增删改查中的“查”方法时，跳过数据库的查询操作，访问另一台机器中的同一个业务对象类的“查”方法。

　　以上是向另一台机器发送请求，该请求并不直接调用另一台机器上的业务对象类的“查”方法，而是将要调用的业务对象和方法参数信息转为一个“二进制包”，作为参数去调用另一台机器上通用的“查”方法，另一台机器上的“查”方法再解开这个包，然后去调用解开的包中所表示的业务对象类型，下面的静态图是另一台机器接受到请求后的工作。

　　又有些说明：
　　1． 关于原理都已在图中做了描述，不另写大段文字解释了；
　　2． 上面两个图中，除了“实际业务对象类”以外的部分全部属于架构或者框架部分；
　　3． 如果用OO的思想去审查上面的两个图，你一定会为这糟糕的设计而抱怨，这里只是为了尽可能简单的表述分布式系统的工作原理，你可以采用策略模式使数据门户不改变的情况下适应各种请求响应场合，采用工厂模式实现不同的请求响应场合的切换。

　　
关于数据库的分布
　　为了解决数据库服务器的负担，我们可能希望把数据分布存储在多个服务器上，我设想的数据库分布方案是，各服务器上的数据库在结构上一模一样，而表里的数据存储到不同服务器上，这样数据访问层在查数据的时候分别向所有数据库服务器发送同样的sql命令，然后数据访问层得到数据后整合，这样减轻每台服务器的工作量。亦或者根据表里的某个代表性的字段（如：省份）分布数据到不同服务器。