分布式资源共享服务器有利于任务在整个计算机系统上进行分配与优化，克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷，解决了网络GIS中存在的数据异构、数据共享、运算复杂等问题，是地理信息系统技术的一大进步。
分布式资源共享服务器的特点：
1、其具有一个以全局数据库管理员为基础的分层控
既然是分布式系统，系统间通信的技术就不可避免的要掌握。
首先，我们必须掌握一些基本知识，例如网络通信协议（例如TCP / UDP等），网络IO（Blocking-IO，NonBlocking-IO，Asyn-IO），网卡（多队列等）。 了解有关连接重用，序列化/反序列化，RPC，负载平衡等的信息。
在学习了这些基本知识之后，您基本上可以在分布式系统中编写一个简单的通信模块，但这实际上还远远不够。 现在，您已经进入了分布式字段，您已经对规模有很多要求。 这意味着需要一种通信程序，该程序可以支持大量连接，高并发性和低资源消耗。
大量的连接通常会有两种方式：
大量client连一个server
当前在NonBlocking-IO非常成熟的情况下，支持大量客户端的服务器并不难编写，但是在大规模且通常是长连接的情况下，有一点需要特别注意 ，即服务器挂起时不可能所有客户端都在某个时间点启动重新连接。 那基本上是一场灾难。 我见过一些没有经验的类似案例。 客户端规模扩大后，服务器基本上会在重新启动后立即刷新。 大量传入连接中断（当然，服务器的积压队列首先应设置为稍大一些）。 可以使用的通常方法是在客户端重新连接之前睡眠一段随机的时间。 另外，重连间隔采用避让算法。
一个client连大量的server
有些场景也会出现需要连大量server的现象，在这种情况下，同样要注意的也是不要并发同时去建所有的连接，而是在能力范围内分批去建。
除了建连接外，另外还要注意的地方是并发发送请求也同样，一定要做好限流，否则很容易会因为一些点慢导致内存爆掉。
这些问题在技术风险上得考虑进去，并在设计和代码实现上体现，否则一旦随着规模上去了，问题一时半会还真不太好解。
高并发这个点需要掌握CAS、常见的lock-free算法、读写锁、线程相关知识（例如线程交互、线程池）等，通信层面的高并发在NonBlocking-IO的情况下，最重要的是要注意在整体设计和代码实现上尽量减少对io线程池的时间占用。
低资源消耗这点的话NonBlocking-IO本身基本已经做到。
伸缩性
分布式系统基本上意味着规模不小。 对于此类系统，在设计时必须考虑可伸缩性。 在体系结构图上绘制的任何点，如果请求量或数据量继续增加，该怎么办？ 通过添加机器来解决。 当然，此过程不需要考虑无限的情况。 如果您有经验的建筑师，从相对较小的规模到非常大型的范围，那么优势显然并不小，而且它们也将越来越稀缺。 。
横向可扩展性（Scale Out）是指通过增加服务器数量来提高群集的整体性能。 垂直可伸缩性（Scale Up）是指提高每台服务器的性能以提高集群的整体性能。 纵向可扩展性的上限非常明显，而分布式系统则强调水平可伸缩性。
分布式系统应用服务最好做成无状态的
应用服务的状态是指运行时程序因为处理服务请求而存在内存的数据。分布式应用服务最好是设计成无状态。因为如果应用程序是有状态的，那么一旦服务器宕机就会使得应用服务程序受影响而挂掉，那存在内存的数据也就丢失了，这显然不是高可靠的服务。把应用服务设计成无状态的，让程序把需要保存的数据都保存在专门的存储上(eg 数据库)，这样应用服务程序可以任意重启而不丢失数据，方便分布式系统在服务器宕机后恢复应用服务。
伸缩性的问题围绕着以下两种场景在解决：
无状态场景
对于无状态场景，要实现随量增长而加机器支撑会比较简单，这种情况下只用解决节点发现的问题，通常只要基于负载均衡就可以搞定，硬件或软件方式都有；
无状态场景通常会把很多状态放在db，当量到一定阶段后会需要引入服务化，去缓解对db连接数太多的情况。
有状态场景
所谓状态其实就是数据，通常采用Sharding来实现伸缩性，Sharding有多种的实现方式，常见的有这么一些：
21 规则Sharding
基于一定规则把状态数据进行Sharding，例如分库分表很多时候采用的就是这样的，这种方式支持了伸缩性，但通常也带来了很复杂的管理、状态数据搬迁，甚至业务功能很难实现的问题，例如全局join，跨表事务等。
22 一致性Hash
一致性Hash方案会使得加机器代价更低一些，另外就是压力可以更为均衡，例如分布式cache经常采用，和规则Sharding带来的问题基本一样。
23 Auto Sharding
Auto Sharding的好处是基本上不用管数据搬迁，而且随着量上涨加机器就OK，但通常Auto Sharding的情况下对如何使用会有比较高的要求，而这个通常也就会造成一些限制，这种方案例如HBase。
24 Copy
Copy这种常见于读远多于写的情况，实现起来又会有最终一致的方案和全局一致的方案，最终一致的多数可通过消息机制等，全局一致的例如zookeeper/etcd之类的，既要全局一致又要做到很高的写支撑能力就很难实现了。
即使发展到今天，Sharding方式下的伸缩性问题仍然是很大的挑战，非常不好做。
上面所写的基本都还只是解决的方向，到细节点基本就很容易判断是一个解决过多大规模场景问题的架构师，:)
稳定性
作为分布式系统，必须要考虑清楚整个系统中任何一个点挂掉应该怎么处理（到了一定机器规模，每天挂掉一些机器很正常），同样主要还是分成了无状态和有状态：
无状态场景
对于无状态场景，通常好办，只用节点发现的机制上具备心跳等检测机制就OK，经验上来说无非就是纯粹靠4层的检测对业务不太够，通常得做成7层的，当然，做成7层的就得处理好规模大了后的问题。
有状态场景
对于有状态场景，就比较麻烦了，对数据一致性要求不高的还OK，主备类型的方案基本也可以用，当然，主备方案要做的很好也非常不容易，有各种各样的方案，对于主备方案又觉得不太爽的情况下，例如HBase这样的，就意味着挂掉一台，另外一台接管的话是需要一定时间的，这个对可用性还是有一定影响的；
全局一致类型的场景中，如果一台挂了，就通常意味着得有选举机制来决定其他机器哪台成为主，常见的例如基于paxos的实现。
可维护性
维护性是很容易被遗漏的部分，但对分布式系统来说其实是很重要的部分，例如整个系统环境应该怎么搭建，部署，配套的维护工具、监控点、报警点、问题定位、问题处理策略等等。
1、需要注意DFS(分布式文件系统)根目录的放置。当用户访问WEB网页时，他们只知道要访问某个网站，而不知道网站后面可能还有其他服务器的存在。用户要访问的WEB服务器其实就是DFS根目录所在的主机。网络管理员要实现分布式文件系统，必须要先将网络中一台服务器内的共享文件夹设置为DFS根目录。这个DFS根目录主要用来存储分布式文件系统的映射关系。网络管理员要为该根目录取一个简约的名字，其他用户就可以通过这个名字访问这个分布式文件系统根目录下的文件。可见DFS根目录的安全性直接跟WEB服务器的安全相关。而且其也跟WEB应用服务的稳定性息息相关。因为如果这个目录出现了问题，映射关系遭受到破坏，则用户将无法正常访问文件资源。为了提高这个根目录的安全性，笔者建议是要把这个根目录部署在微软的NTFS文件系统上，并对此配置一定的安全措施。由于NTFS文件系统要比FAT32文件系统安全的多。无论是加密技术或者数据还原上，NTFS文件系统都有比较突出的表现。故笔者觉得，使用NTFS文件系统当作分布式文件系统的根目录，则其安全性与稳定性会更有保障一点。2、部署多台主机服务器。如果DFS在微软的域环境中，则必须是域的成员才能够存储DFS根目录。换句话说，要成为DFS服务器，则必须加入到微软的域中。这台存储DFS根目录的服务器被称为主机服务器。域DFS可以通过创建另一个新的DFS根目录目标的方式，将DFS根目录复制到其他的服务器内。如上图中，DFS根目录的目标有两个，分别映射到两台服务器的共享文件夹。即DFS根目录中的内容被同时存储到这两台服务器种，以实现服务器负载均衡以及提供比较高的容错性能。从理论上来说，主机服务器越多，其容错性能越好，用户访问服务器的性能也越好。这些主机服务器的设置数据可以通过活动目录自动同步。为此当一台存储DFS根目录的主机服务器发生故障时，用户还是可以从其他的主机服务器读取到根目录内的设置数据。所以可以说主机服务器它具备了DFS映射关系的容错功能。简单的说，主机服务器之间的数据会自动发生同步，从而保证各台服务器之间数据的一致性。但是这就会发生一个问题。如果服务器比较多的时候，那么这个数据同步就可能会占用比较多的网络带宽。而且架立服务器也需要不少的投入。为此笔者觉得，主机服务器也并不是越多越好。网络管理员需要根据预计访问的用户、对于容错性的要求等等角度，去考虑主机服务器的数量。对于普通企业来说，这主机服务器2台到3台也就够了。多了也是种浪费。
3、要选择合适的分布式文件系统类型。Windows服务器(以2003服务器 *** 作系统为例)其主要支持两种分布式文件系统类型。这两种类型分别为域DFS与独立的DFS。这两种分布式文件系统各有各的特点。网络管理员需要了解这两种分布式文件系统的特点，并根据企业自身的需求选择合适的实现方式。这里笔者要强调的是，无论是哪种分布式文件系统类型，他们都支持容错功能。无论是域DFS还是独立的DFS，一个DFS链接的目标可以同时映射到多台服务器的共享文件夹，这些共享文件夹中存储着相同的文件。当有一台服务器发生故障时，用户还是可以从其他的计算机获取文件。也就是说，无论哪种实现方式都可以提供DF链接容错功能。这也是这两种分布式文件系统类型的唯一共同之处。另外需要注意的是主机服务器之间文件的复制问题。在域DFS中，主机服务器之间的DS根目录复制，还有DFS链接的多个目标之间文件的复制，都可以通过文件复制服务来实现自动复制。但是如果是独立的DFS，则DFS链接的多个目标之间文件的复制，需要网络管理员手工 *** 作。这个差异让独立DFS只限于在小规模范围内使用。除了这个差异外，独立DFS还不具有DFS映射关系的同步功能与DFS根目录的容错功能。故当采用独立的DFS系统类型时，网络管理员需要花费比较多的时间去实现这个数据同步功能。故笔者建议对于独立的分布式文件系统要慎用。另外是否采用独立DFS，还有出于兼容性的考虑。这方面的内容笔者会在下一点进行说明。
4、要注意早期 *** 作系统对分布式文件系统的支持。一般来说只有安装了DFS客户端软件的客户端计算机，才可以访问DFS内的文件。另外也只有某些特定的计算机 *** 作系统才具备存储DFS根目录的功能。通常情况下，Windows2000(包含2000 *** 作系统)以及以后的系统默认情况下都已经安装了DFS客户端，故这些 *** 作系统对DFS文件系统的支持是没有文件的。需要注意的是早期的 *** 作系统对其的支持。如Windows95 *** 作系统，虽然其可以支持DFS分布式文件系统，但是另外下载并安装DS客户端软件。而Windows98 *** 作系统默认情况下已经安装了DFS客户端，可是这个客户端只能够支持独立的DFS分布式文件系统类型。如果要访问域DFS分布式文件类型，则必须对这个DFS客户端软件进行升级。所以如果企业网络中存在着比较老的计算机 *** 作系统，那么是网络管理员部署分布式文件系统的一大障碍。
另外最后需要强调的一点就是安全问题。从上面的描述中大家可以看出，分布式文件系统是在各个服务器的共享文件夹上实现的。为了分布式文件系统的安全性，最好能够把共享文件夹设置在NTFS文件系统下，并利用NTFS文件系统的权限与共享权限来提高这些共享文件的安全。不能因为采用了DFS文件系统而给数据安全带来了负面影响。否则的话，DFS的容错性与服务器性能负载均衡也无从谈起。
内容提要传统的数据库应用程序经常采用客户机/服务器结构（即C/S结构） 这种结构在技术上已经很成熟了并且应用也很广泛 但这种结构的应用系统有其不足之处 比如查询结果无法共享 即使两个客户发出的请求完全相同也要在服务器上执行两次查询 在客户端存储了具有商业价值的查询算法 数据库服务器负担过重导致效率低下等 如果在服务器和客户机之间再加一个服务器 专门用于存储查询算法和临时查询结果 则问题就得到了很好的解决 一方面不同的客户可以共用临时的查询结果而无须再访问数据库服务器 减轻了服务器的负担 同时在客户端也看不到作为商业机密的查询算法 这就是分布式系统的工作原理 本文将介绍如何应用PowerBuilder进行分布式应用程序的开发
一 分布式应用程序概述
分布式系统的出现源于传统的C/S结构的若干弊病 如效率低 安全性差等 结合到数据库方面来说 全球的DNS（域名解析系统）系统是一个很典型的例子 试想如果把全世界所有的域名都集中到一台服务器中来进行管理 那服务器肯定会因负载过重而无法正常工作 整个互联网也就瘫痪了
在编写C/S结构的数据库应用系统时 同样也会遇到这类问题 那就是如果客户数量很多 数据量又都很大的情况下 服务器的负载就会很重 而且重复性工作很多 因为很多客户发出的查询可能完全相同而服务器却需要一一进行查询 同时查询算法存储于客户端 这可能不适合一些商业环境 因为算法本身可能是需要保密的 如果能够在传统的服务器和客户机之间再加一个服务器用于存储查询算法和临时查询结果 则以上问题均得到了解决 这正是分布式系统的工作原理
二 在PB环境下如何进行分布式应用程序的开发
下图是分布式系统的工作原理图
图（一）
首先 分布式服务器必须建立与数据库服务器的连接 可以通过ODBC接口来实现 本文不在叙述 下面要讲述客户端如何通过分布式服务器来访问数据
在PB环境下要实现分布式的编程 首先在DTS端 需要用到两个对象 一个TransPort对象和一个不可视的用户对象（Classà Custom Nonvisible Object 以下简称NVO） 其中TransPort对象用于响应客户端的连接请求 NVO对象用于和客户端进行实际的数据传输 在客户端也需要用到两个对象 分别是Connection对象和代理对象（NVO Proxy） 其中Connection对象用于建立到DTS的连接 NVO Proxy实际上是与NVO一一对应的 它只是NVO的一个代理 在客户端通过此代理对象来调用NVO的函数来实现相关功能
以下是TransPort对象和Connection对象的常用属性及方法
TransPort对象
属性
Driver 可选的值有四个 分别是WinSock NamedPipes OpenClientServer和Local 由于Winsock的通用性 一般情况下都选择Winsock
Application 对于Winsock而言指的是端口号 用户可以任意指定 但必须大于
方法
Listen() 其调用方法是transport Listen（） 即开始监听 如果调用成功则返回
StopListening() 其调用方法是transport StopListening（） 即结束监听 如果调用成功则返回
Connection对象
属性
Driver 与Transport对象相同
Application 与Transport对象相同 但要注意两者必须一致
Location DTS的IP地址
方法
ConnectToServer() 其调用方法是connection ConnectToServer（） 即连接DTS 如果调用成功则返回 显然在调用该函数之前 DTS必须处于监听状态
DisconnectServer() 其调用方法是connection DisconnectServer ( ) 即断开与DTS的连接
CreateInstance() 其调用方法是connection CreateInstance（variable） 即建立一个NVO的代理以便调用NVO的相关函数 注意在调用该函数之前 必须保证客户端已经与DTS建立了连接
PB环境下分布式应用程序的开发（二） lishixinzhi/Article/program/SQL/201311/16222
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）