① 什么是分布式系统
分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。
(1)分布式如何配置资源扩展阅读
分布式系统系统优点
1、经济：微处理机提供了比大型主机更好的性能价格比
2、速度：分布式系统总的计算能力比单个大型主机更强
3、固有的分布性：一些应用涉及到空间上分散的机器
4、可靠性：如果一个机器崩溃,整个系统还可以运转
5、渐增：计算能力可以逐渐有所增加
② java的框架spring如何配置分布式事务
分布式事务本身不是程序做的，我们不需要在代码中明确地做这些事，因为是不是分布式对于代码来说，代码写起来完全相同。
只是选择支持 JTA XA （也叫 2-Phase Commit, 2PC) 的数据源就可以了，你默认使用的 DataSource 可能不是 XA ( Weblogic 把它叫 TX）。
一般在网站编程时多数人可能是用 Spring 搭配 tomcat commons-dbcp 那个数据源，那个可能就不是支持 XA 的数据源，如果你打算在复杂企业应用生态系统中使用J2EE 就不要用 Spring 提供 commonbs-dbcp 那种小作坊式的做法，因为它是假设自己的程序就是独立生态系统，当你需要与外界打交道时就碰到诸多问题，这也是为什么很多大企业依然还是会使用 EJB 的原因（EJB 已经考虑到这点，并把它写入到J2EE 标准中），我们推荐用服务器自己的数据源，也就是 lookup JNDI，这样的话，是不是 XA 事务就由服务器的配置来定制，代码就不需要任何配置来决定是不是 XA 了 ；事务本身是不是 XA (分布式的）是服务器的事，服务器来管理“资源” （包括数据源，JMS 连接等，一个资源（JDBC连接）如何参与事务是“资源管理器”（驱动程序）的职责，跟程序无关），服务器提供事务管理并作为“事务协调者”来处理多个“资源管理器”（不同的数据库连接）之间的事务一致性，，而 Spring 的职责很简单，对于我们希望 Spring 自动提交或回滚事务时，在配置中指定需要回滚的异常的类型。
不过我没有实际使用过 Spring，我有多年的 EJB 经验，这其中的原理是相同的，因为这是 J2EE 标准规范要求达到的。
③ 怎么搭建分布式服务器
如何搭建分布式网站服务器，比如我有3台服务器ABC，需要搭建分布式服务。也就需要建立IIS 还由DNS WIN 服务器的 还有更改主机名 很麻烦的,这个需要专业的IT人员来操作的。
以下资料作为参考：
DNS轮循
首先介绍一个DNS系统:传统的DNS解析都是一个域名对应一个IP地址,但是通过DNS轮循技术(负载平衡技术)可以做到一个域名对应到多个IP 上. 这样大家难免就会问,这个技术有什么用呢?
DNS轮循是指将相同的域名解释到不同的IP，随机使用其中某台主机的技术,该项技术可以智能的调整网站的访问量到不同服务器上，减轻网站服务器的压力，实现负载匀衡;如果您感觉到单一的主机已经不堪负载你网站日益增长的访问，那么建议您采用我们的DNS轮循技术。
DNS轮循系统可以根据您的需求设置N台主机作为WEB服务器。目前已有越来多大型的WEB服务器使用DNS轮循来实现负载均衡，服务的分布规划更便捷，扩展性更好，从而提高了网站的稳定性和访问效率，那些大量数据文件请求的客户也得到了更快的响应。
DNS轮循还将给您的网站提供这样的改进，诸如您的网站的数据使用量一直处于不断的增长当中，当达到服务器资源运行瓶颈的情况
下，由于采用了DNS轮循技术，您只需要增加服务器数量就可以平滑升级，而且偶然故障或其他意外情况造成的损失得以避免，7×24小时可靠性的持续的运行
成为可能。
如果您真的希望自己的网站能够一直稳定的在线运行，尽量的减少宕机的比率，那么除了采用比较好的网站空间技术支持之外，还可以采用时代互联域名的DNS轮循功能来实现网站的永久在线负载平衡
负载均衡是由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无须其
他服务器的辅助。通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。均衡负载
能够平均分配客户请求到服务器列阵，籍此提供快速获取重要数据，解决大量并发访问服务问题。这种群集技术可以用最少的投资获得接近于大型主机的性能。
网络负载均衡的优点
第一，网络负载均衡能将传入的请求传播到多达32台服务器上，即可以使用最多32台服务器共同分担对外的网络请求服务。网络负载均衡技术保证即使是在负载很重的情况下，服务器也能做出快速响应;
第二，网络负载均衡对外只需提供一个IP地址(或域名);
第三，当网络负载均衡中的一台或几台服务器不可用时，服务不会中断。网络负载均衡自动检测到服务器不可用时，能够迅速在剩余的
服务器中重新指派客户机通讯。这项保护措施能够帮助你为关键的业务程序提供不中断的服务，并可以根据网络访问量的增加来相应地增加网络负载均衡服务器的数
量;
第四，网络负载均衡可在普通的计算机上实现。
网络负载均衡的实现过程
在Windows Server 2003中，网络负载均衡的应用程序包括Internet信息服务(IIS)、ISA
Server 2000防火墙与代理服务器、VPN虚拟专用网、终端服务器、Windows Media
Services(Windows视频点播、视频广播)等服务。同时，网络负载均衡有助于改善服务器的性能和可伸缩性，以满足不断增长的基于
Internet客户端的需求。
网络负载均衡可以让客户端用一个逻辑Internet名称和虚拟IP地址(又称群集IP地址)访问群集，同时保留每台计算机各自的名称。下面，我们将在两台安装Windows Server 2003的普通计算机上，介绍网络负载均衡的实现及应用。
这两台计算机中，一台计算机名称为A，IP地址为192.168.0.7;另一台名为B，IP地址为192.168.0.8。
规划网络负载均衡专用虚拟IP地址为192.168.0.9。当正式应用时，客户机只需要使用IP地址192.168.0.9来访问服务器，网络服务均衡
会根据每台服务器的负载情况自动选择192.168.0.7或者192.168.0.8对外提供服务。具体实现过程如下：
在实现网络负载均衡的每一台计算机上，只能安装TCP/IP协议，不要安装任何其他的协议(如IPX协议或者NetBEUI协议)，这可以从“网络连接属性”中查看。
第一步，分别以管理员身份登录A机和B机，打开两台机的“本地连接”属性界面，勾选“此连接使用下列项目”中的“负载均衡”项并进入“属性”对话框，将IP地址都设为192.168.0.9(即负载均衡专用IP)，将子网掩码设置为255.255.255.0;
第二步，分别进入A机和B机的“Internet协议(TCP/IP)”属性设置界面，点击“高级”按钮后，在弹出的“高级TCP/IP设置”界面中添加IP地址192.168.0.9和子网掩码设置为255.255.255.0。
第三步，退出两台计算机的“本地连接属性”窗口，耐心等一会儿让系统完成设置。
以后，如果这两台服务器不能满足需求，可以按以上步骤添加第三台、第四台计算机到网络负载均衡系统中以满足要求。
④ 如何 配置 NET 下的 分布式系统
至开发上的一个巨大进步，.net程序员以对象方式操作数据，以类sql语法在程序里查询数据，大大减少了繁琐的构造SQL语句的工作，可以更加专注于编写业务逻辑代码。但是在多层架构的分布式应用系统中，实体对象通过远程序列化到客户端时，这些实体会与其数据上下文(也就是实体容器)分离，在客户端无法对实体直接进行查询以及CUD(Create,Update,Delete)操作，下面以SQL Server为数据库，Remoting+Entity Framework3.5作为数据服务层，WinForm作为客户端，讲述一下如何使用EF框架搭建多层分布式应用系统。 二、 技术分析 1. 通过远程客户端传输过来的实体，都是处于分离状态(EntityState属性值为Detached)，所以在多层应用程序中的服务端实现实体的更新或删除时，关键是如何把实体附加回实体容器中。MSDN上关于对分离实体的查询和CUD操作描述如下: 1) 附加对象(实体框架) 在实体框架的某个对象上下文内执行查询时，返回的对象会自动附加到该对象上下文。还可以将从源而不是从查询获得的对象附加到对象上下文。您可以附加以前分离的对象、由 NoTracking 查询返回的对象或从对象上下文的外部获取的对象。还可以附加存储在 ASP.NET 应用程序的视图状态中的对象或从远程方法调用或 Web 服务返回的对象。 使用下列方法之一将对象附加到对象上下文: · 调用 ObjectContext 上的 AddObject 将对象附加到对象上下文。当对象为数据源中尚不存在的新对象时采用此方法。 · 调用 ObjectContext上的Attach 将对象附加到对象上下文。当对象已存在于数据源中但当前尚未附加到上下文时采用此方法。有关更多信息，请参见如何:附加相关对象(实体框架)。 · 调用 ObjectContext的AttachTo，以将对象附加到对象上下文中的特定实体集。如果对象具有 null(在 Visual Basic 中为 Nothing)EntityKey 值，也可以执行此操作。 · 调用 ObjectContext上的ApplyPropertyChanges。当对象已存在于数据源中，并且分离的对象具有您希望保存的属性更新时采用此方法。如果简单地附加该对象，则属性更改将丢失。有关更多信息，请参见如何:应用对已分离对象的更改(实体框架)。 2) 应用对已分离对象的更改(实体框架)示例代码 View Code 2. 实现动态条件查询。在本地环境中，对于Linq，我们可以通过动态构造Lambda表达式树来实现动态条件查询，但是在远程环境中，Lamdba表达式不支持远程序列化传输，只能通过ObjectContext的CreateQuery方法实现，但幸好微软后来又提供了一个LINQ动态查询扩展库Dynamic.cs，使用起来更方便,于是采用它实现。 3. EF中核心抽象类是ObjectContext,实体容器都从它派生，实体容器上的CUD方法其实都是通过调用ObjectContext的CUD操作方法实现的。1) AddObject(string,object):表示添加实体object到实体容器，只要实体的EntityKey值为空，无论是否Detached状态均可以通过此方法实现添加操作。2) ApplyPropertyChanges(string,object)表示把分离状态的实体object上的所作的修改更新回容器中已存在的对应的实体，执行条件有两个:①实体处于分离状态，②实体容器中存在主键值与其相同的且为Unchanged状态的实体,所以，当我们需要更新一个Detached状态的实体时，可以先把一个具有原始值的相同键值的实体附加回容器中，或者直接执行一下查询，从数据库中取出该实体。3) DeleteObject(object)表示从实体容器中删除一个实体,执行条件是该实体存在于实体容器中,所以删除一个Detach状态的实体之前，需要把它通过Attach方法附加回实体容器中。 4. 实体对象也是基于抽象类EntityObject派生的，由此我们完全可以用ContextObject和EntityObject实现服务端对实体的查询和CUD方法，其实现子类在运行时由客户端注入，从而使服务端和数据库实现松耦合。 5. 下图是MSDN上关于在数据访问层中使用 LINQ to SQL 的 n 层应用程序的基本体系结构图，其实EF的结构也是一样的，不过是把DataContext换成ObjectContext。 三、 动手开发 1. 利用EF建立数据库概念模型新建一个解决方案EFServiceSystem，添加一个新项目，命名为EFModel,添加项目，在项目下添加一个ADO.NET Entity Data Model项，命名为EFModel.edmx,选择从数据库生成(假设我们已经建好了一个SQL Server数据库)，一路点击下一步，直至完成。编译项目成功后就算完成。为什么要把数据库模型单独编译成一个dll呢，我将在后面给予解释。 2. 建立数据服务层在解决方案下再添加一个类库项目，命名为EFService。1) 利用外观模式，我们把客户端常用的查询和CUD操作方法简化为3个方法Query<T>,Save(T t),Delete(T t)，根据针对接口编程的设计原则，定义一个CUD方法接口供客户端调用。 View Code 2) 实现类EntityHelper的代码。主要思路是通过构造函数注入数据上下文实例名称，在配置文件取出其程序集限定名，通过反射创建实例，调用实例的相应方法实现接口。 View Code 3) 最后，我们创建一个服务工厂类，暴露给客户端，负责以接口方式向客户端提供远程服务对象，数据服务层创建完毕。 View Code 4) 补充一下Dynamic.cs的内容，省得你去网上找了View Code 3. 创建运行服务的宿主程序。实际开发中，通常选择创建一个windows服务程序来运行Remoting，但是服务需要安装才能启动，运行和调试起来都比较繁琐，所以这里创建一个简单的控制台程序来运行它。在解决方案下添加一个控制台程序项目，在program.cs编写如下代码: View Code 配置文件App.Config主要包括数据库连接信息以及自己定义一个数据上下文名称(这里和数据库连接名称相同，事实上不必相同)，数据库连接信息可以从EFModel项目中配置文件中直接拷贝过来。内容如下: View Code 编译成功后，拷贝EFModel和和EFService两个项目生成的dll文件至可执行文件EFServiceHost.exe同一目录下，点击运行EFServiceHost.exe。 4. 最后，我们建立一个winform客户端作为测试。在program.cs注册远程服务: View Code 四、 部署应用 1. 至此，整个系统搭建完毕。在本例中，我把所有项目都统一建立在一个解决方案下，其实是为了演示方便，实际开发时候，完全可以各自独立创建。下面我们来分析一下各个项目的职能和相互之间的引用关系。 1) EFModel:由Visual Studio 的数据模型工具生成的数据库实例模型，提供数据的查询以及CUD操作。不需引用其它项目。 2) EFService:使用数据库实例模型以及实体的抽象基类编写完成，代码里不涉及具体数据库模型实例，运行时通过客户端注入参数和读取配置文件动态生成数据库模型实例，并调用实例的查询和CUD方法实现客户端的请求。不需引用其它项目。 3) EFServiceHost:负责运行Remoting服务，如果通过配置文件方式发布服务的话，编译时也不需引用其它项目，我这里引用了EFService项目，是因为使用了代码方式暴露EFSservice的服务类。运行时需要将EFService和EFModel的dll文件拷贝至运行目录下。 4) EFClient:需要引用EFModel和EFService。(注:因为本例中式使用了Remoting作为远程服务，如果是WebService或者WCF则只需添加服务引用，然后在本地生成客户端代理类)。事实上EFService中的实现类EntityHelper也可以独立出去，不必让客户端引用，对于客户端而言，仅仅是使用ServiceFactory和接口IentityHelper就足够了。这样只要接口不变，EntityHelper更新的时候，客户端无须更新引用，而且服务端代码可以完全被隔离开客户端，对一些服务端和客户端之间的保密性比较敏感的项目尤为有利。 2. 通过分析我们发现，在开发下一个新项目的时候，即使整个数据库都变了，从SQL SERVER变成Oracle，数据库服务名变了，表也变了，我们仍然无需修改服务端代码，只需针对新的数据库，生成新的EFModel，然后拷贝DLL文件至EFServiceHost的运行目录下(这也就是我为什么要把EFModel独立成一个项目的原因)，再修改一下EFServiceHost的配置文件中的数据库连接和实体容器名称即可完成新系统的部署。对于客户端来说，也就是更新一下EFModel.dll，还是调用服务端提供的那几个API，便可完成查询和CUD操作，不用关心底层的数据库是SQL Server还是Oracle，更不用自己实现对新库新表的查询和CUD操作(本来也不用)。当然，对于正在运行的系统，我们也可以针对新建数据库生成新的实体模型DLL，拷贝至EFServiceHost运行目录下，实现热插拔方式扩展数据库，而对原来的系统毫无影响，即使新加的库是不同类型的库。 五、 系统架构图示 六、 总结 从以上分析可以看出，该系统运用到项目开发中，对服务端来说，实现了最大程度组件重用(零代码修改)，对客户端开发来说，高度简化了对数据的操作命令，并封装了实现细节,大大降低了开发的技术难度，提高了开发速度。当然，我这里写的代码仅仅是最简单的演示代码，在实际项目开发中，服务端要处理的细节和扩展的功能要比这复杂得多。比如性能优化，实现复杂查询和批量CUD操作，并发处理，事务控制，日志跟踪，数据缓存等等。另外，如果各层采用不同的技术实现，服务层实现的代码也有差异。比如EF可以选择最新版的更完善更强大的EF4.0，远程服务可以选择Remoting,WebService,WCF等，不同的远程服务，宿主程序也有所不同，Remoting和WCF可以选择winform，控制台程序，IIS，而Web Service只能选择IIS。不同的服务，不同的宿主程序，会有不同的通信通道 (Http,Tcp),不同的数据传输格式 (二进制，XML,JSON)。如果你嫌上面的实现方式涉及的技术太多，开发起来太麻烦，那么，微软现成的具有REST风格的远程数据服务WCF Data Services会是你的最佳选择。
⑤ 如何配置ceph分布式存储方案
1、对象存储：即radosgw,兼容S3接口。通过rest api上传、下载文件。
2、文件系统：posix接口。可以将ceph集群看做一个共享文件系统挂载到本地。
3、块存储：即rbd。有kernel rbd和librbd两种使用方式。支持快照、克隆。相当于一块硬盘挂到本地，用法和用途和硬盘一样。
⑥ 什么叫分布式事务，在SQL Server中如何配置
MSDTC(Microsoft Distributed Transaction Coordinator)中文叫微软分布式事务处理协调器，负责WINDOWS平台的分布式事务处理。SQL SERVER的事务如果需要和本数据库之外（包括别的数据库）的事务协同完成同一个事务，那么就需要MSTDC来掌控，否则SQL SERVER的事务就是普通的本地数据库事务，和MSDTC没有关系，数据库自身就能处理了。
很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。
将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。
当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。
什么是Microsoft集群服务器
MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。
这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。
MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。
在集群服务器上的SQL Server
SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。
SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”
注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。
单个的大的SQL Server集群还是小的集群
下面是大的、由更多的节点组成的集群的优点：
◆更高的可用新(更多的节点来灾难恢复)。
◆更多的负载均衡选择(更多的节点)。
◆更低廉的维护成本。
◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。
◆增强的管理性和简化环境(需要管理的少了)。
◆更少的停机时间(灾难恢复更多的选择)。
◆灾难恢复性能不受集群中的节点数目影响。
下面是单个大的集群的缺点：
◆集群节点数目有限(如果需要第9个节点怎么办)。
◆在集群中SQL实例数目有限。
◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。
◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。
虚拟化和集群
虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。
在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。
集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。