第八章命名服务与透明性
数据库编码规范
数据库编码规范V1.02022-8-28目的范围术语设计概要命名规范(逻辑对象)数据库对象命名脚本注释数据库操作原则常用字段命名(参考)1)目的为了统一公司软件开辟的设计过程中关于数据库设计时的命名规范和具体工作时的编程规范，便于交流和维护，特制定此规范。
2)范围本规范合用于开辟组全体人员，作用于软件项目开辟的数据库设计、维护阶段＜3)术语数据库对象：在数据库软件开辟中，数据库服务器端涉及的对象包括物理结构和逻辑结构的对象。
物理结构对象：是指设备管理元素，包括数据文件和事务日志文件的名称、大小、目录规划、所在的服务器计算极名称、镜像等，应该有具体的配置规划。
普通对数据库服务器物理设备的管理规程，在整个项目/产品的概要设计阶段予以规划。
逻辑结构对象：是指数据库对象的管理元素，包括数据库名称、表空间、表、字段/域、视图、索引、触发器、存储过程、函数、数据类型、数据库安全性相关的设计、数据库配置有关的设计以及数据库中其他特性处理相关的设计等。
4)设计概要设计环境＜数据库：ORACLE9i、MSSQLSERVER2000 等，操作系统：LINUX7.1 以上版本，显示图形操作界面；RedHat9 以上版本WINDOWS2000SERVER 以上设计使用工具手使用PowerDesigner 做为数据库的设计工具，要求为主要字段做详尽说明。
对于SQLServer 尽量使用企业管理器对数据库进行设计,并且要求对表，字段编写详细的说明(这些将作为扩展属性存入SQLServer 中) 手通过PowerDesigner 定制word 格式报表，并导出word 文档，作为数据字典保存。
(PowerDesignerv10 才具有定制导出word 格式报表的功能)＜对于SQLServer 一旦在企业管理器进行数据库设计时加入扩展属性，就可以通过编写简单的工具将数据字典导出。
4 编写数据库建数据库、建数据库对象、初始化数据脚本文件设计原则4 采用多数据文件手禁止使用过大的数据文件，unix 系统不大于2GB,window 系统不超过500MB$oracle 数据库中必须将索引建立在索引表空间里。
DCS9(命名服务)
第8章 命名服务主要内容：分布式系统中的命名方式，名字服务器设计，实例分析学时：45′*1重点：名字服务器设计难点：导航与定位8-1概述一、名字与属性名字(Name)：文本名（用户使用的外部名，可读性），系统标识符（系统使用的内部名）名字举例：1、物理/逻辑网址：表示名字的位置或者地址2、端口、进程等标识符：表示名字的地址——消息的目的地3、资源标识符：资源的低层独立定位标识符4、文件标识符：用于定位文件一个名字标识一个对象，它们之间的联结叫做绑定(Banding)。
属性值：基本值（如整数），自身的符号值（如Internet地址：230.103.125.078）二、名字服务系统名字服务系统实现名字的文本名与属性的映射，可以认为，该服务系统管理一个用于实现名字绑定的“数据库”。
有两个重要的问题需要解决：1、一致性(Unification)——使用一致的命名规则，名字一致2、集成(Integration)——多子系统集成时，解决冲突问题三、名字服务的一般要求1、处理任意数量的名字并为任意数量的管理组织服务；2、长生命期3、高可靠性4、故障隔离5、容忍怀疑8-2 一般的命名方式为了命名的方便，在一个大系统中，人们常常使用多层目录结构来管理文件和资源，因此这些资源就有了路径名。
8-3分布式系统中的命名方式一、名字管理器的主要功能主要功能：符号串名映射为物理地址。
z通过管理名字在系统中的地址去定位命名过的对象；z创建、删除、更改对象的名字；z改变对象的位置，支持对象在系统中的迁移；z利用对象名字来支持对象的共享；z创建对象组，支持组内名字操作（添加、删除、枚举、测试等）；z支持对象组的递归结构；z完成外部名到内部名的映射工作。
二、分布式系统中的命名方案1、绝对命名全系统范围内唯一。
在机内，可以是由时钟、计数器产生的串。
2、相对命名依赖于上下文，不同的使用者，可用不同的名字，即名字不惟一。
3、层次式命名z对象被分成组；z每组有全局唯一的组名；z每个对象具有组内唯一的名字；z组中对象可以进一步分成若干组。
餐饮店全案策划
餐饮店全案策划餐饮店的全案策划是一个涉及到营销、品牌、设计、装修、人员管理等方面的综合性工作。
全案策划的目标是打造一个让顾客愉悦、员工舒适、管理高效、盈利稳定的餐饮店。
本文将从以下几个方面进行论述：一、市场调研市场调研是餐饮店全案策划的前置工作，通过市场调研可以了解消费者的需求、竞争对手的情况、行业发展趋势等信息，从而制定出针对性的营销策略。
在市场调研中，可以采用问卷调查、访问调查、网络调查等方式，针对不同的人群、不同的信息需求进行调研。
同时，也可以通过观察竞争对手的经营模式、营销手段等，了解行业发展趋势、市场空间等信息。
二、品牌命名与设计品牌命名和设计是构建餐饮店品牌的核心环节。
一个好的品牌可以吸引到更多的消费者，提高餐饮店在市场中的竞争力。
品牌命名要简洁、有力、易记，同时要与餐饮店的定位相符合。
品牌设计则需要注重商标设计、形象设计、文字设计等方面的统一性和协调性，让顾客能够直观地感受到餐饮店的服务特色和品牌文化。
三、餐厅装修设计餐厅装修设计是表现餐饮店品牌特色的重要一环。
餐厅的装修设计要与品牌的定位和特色相符合，同时也要考虑到空间结构、照明、色彩等方面的设计。
在餐厅装修设计中，可以采用主题包装、艺术装饰、灯光设计等手法，打造出一个让顾客舒适愉悦的就餐环境，加强餐饮店品牌的印象和感受。
四、透明化、多样化菜肴的研发餐饮店的菜肴是吸引消费者的重要因素，透明化、多样化菜肴的研发可以让顾客更清晰、更直观地了解餐饮店的菜品。
通过菜单的设计、食材的选择、口味的调整等，可以研发出透明化、多样化的菜肴，吸引更多的顾客，提高消费者的满意度和忠诚度。
五、员工招聘培训员工招聘培训是保障餐饮店管理和运营的重要手段。
通过精准的招聘、合适的培训、良好的激励机制等手段，可以打造高效的管理和运营团队。
在员工招聘培训中，需要关注员工的素质、能力和经验等方面的匹配度，注重员工的职业生涯规划和发展，提高员工的积极性和效率。
六、公关活动和营销策略公关活动和营销策略是餐饮店全案策划的重要一环。
CORBA入门
1.CORBA什么是?
CORBA是Common Object Broker Architecture简称,即公共对象请 求代理体系。
2. COBRA的发展
1991年CORBA的第一个版本问世，可是他只是规范了如何再C程 序中使用它。 随着OMG(Object Management Group,对象管理组)公布RFP(Request for proposals,征求提案)作为将CORBA映射到C++的标准，1994年 秋天才完成了标准化。 最初为CORBA2.0。在CORBA2.0种提供了IIOP(Internet Inter-ORB Protocol)。随后的2.1、2.2、2.3作了部分修改
应用对象 公共设施 ORB
对象服务
第2章 CORBA概述
1.公共设施 (1) 横向设施：是指在通用领域内定义的对象 (2) 纵向设施：是指在专用领域内定义的对象 2.对象服务 (1) 命名服务 (2) 事件服务 (3) 事件处理服务 (4) 交易服务 (5) 生命周期服务 (6) 安全服务 (7) 通知服务 3. 对象请求代理(ORB) 它是CORBA的基础，是在分布式环境下，CORBA应用所使用的基 于对象模型的软件总线。
第2章 CORBA概述
静态调用和动态调用的区别： 国王就是客户，哲学家就是存根，国王询问哲学家就是 客户调用存根，名片就是对象引用，电话就是ORB核 心，哲学界伙伴就是静态框架，先知就是对象实现。 秘书就是DII，名片薄就是接口库。
国王 先知
6 哲学家
1
2
3 哲学家伙伴
4
5
第2章 CORBA概述
TUXEDO技术培训
TUXEDO技术培训
TUXEDO系统的应用基础、通信缓冲区以及通信方式（三）
n WSL工作原理及其配置
n WSL (workstation Listener)是tuxedo提供的工作站监听服务器，应用程序启 动时它开始监听服务器上的某个端口，并根据配置自动启动若干个WSN（ workstation Handler),形成”WSL pool“,WSN类似于客户端在服务器的代理 ，并且WSL会根据配置动态调整WSN的进程数量
改进 n TUXEO10.0 增加了TSAM（Tuxedo system and application monitor)应
用监控管理平台。为TUXEDO提供全方位的性能监控和管理服务，根据 时间规则产生告警，并协助进行性能调优。
TUXEDO技术培训
TUXEDO产品介绍以及各版本概述（五）
n TUXEDO系统的关键特点
n 具有三大独特功能：事务监视器、中间件角色、应用服务 器平台角色 1、协调分布式事务，使用XA和两阶段管理协调数据库事务
2、相对独立的结构为用户提供应用开发的简单性和实现自身的价值 3、封装逻辑层的处理，作为应用的统一部署
TUXEDO技术培训
TUXEDO产品介绍以及各版本概述（二）
n 1983年诞生于美国贝尔实验室，最初被命名为 UNITS(Unix Transaction system)，之后被开发为 C/S接口的系统架构TUX（Transaction for UNIX) ，最后被命令为“TUX has been Extended for Distirbuted Operation”
数据库设计中的命名规范与约定
数据库设计中的命名规范与约定在数据库设计和开发过程中，命名规范与约定起着至关重要的作用。
准确、一致且易于理解的命名可以提高代码的可读性和可维护性，减少开发人员之间的沟通成本，同时还能规范化操作，提高工作效率。
本文将介绍数据库设计中常见的命名规范和约定。
1. 表名规范：表名应该具有描述性，能够清晰地反映出该表存储数据的实际含义。
通常，表名使用名词复数形式，并采用下划线或驼峰命名法进行分隔。
例如，使用"users"表示用户信息表，"order_items"表示订单明细表。
2. 字段名规范：字段名应该具有描述性，能够清楚地表示字段所存储的数据内容。
命名应该避免使用缩写、缺乏含义的名称或过于通用的名称。
建议使用名词或名词短语，使用下划线或驼峰命名法进行分隔。
例如，使用"first_name"表示用户的名字，“price”表示商品价格。
3. 主键命名：主键字段通常是唯一标识表中每个记录的字段。
主键字段的命名规范是将表名加上后缀"_id"，例如，对于用户表"users"，主键字段可以命名为"user_id"。
4. 外键命名：外键字段通常用于关联两个表之间的关系，可以用于查询相关数据。
外键字段的命名规范是将被关联的表的表名加上后缀"_id"。
例如，对于订单表"orders"和用户表"users"，关联用户的外键字段可以命名为"user_id"。
5. 索引命名：索引是提高数据库查询效率的重要方式之一。
在命名索引时，应明确表示所涉及的字段或字段组合，建议在字段名之前加上前缀"idx_"。
例如，使用"idx_last_name"表示基于姓氏进行的索引。
6. 视图命名：视图是根据查询语句创建的虚拟表，可以简化复杂查询操作。
服务器命名规则(一)2024
服务器命名规则（一）引言概述：服务器命名规则是在计算机网络中用来标识和管理服务器设备的一种规范，它对于网络管理员和系统维护人员来说具有重要的意义。
良好的服务器命名规则可以提高管理效率、降低操作错误，为整个网络架构提供良好的可维护性。
本文将介绍服务器命名规则的基本原则和注意事项，并提供一些常用的规则实践。
1. 基本原则1.1 一致性：服务器命名应该遵循统一的规则，以便于管理员和用户能够快速识别服务器的用途或位置。
1.2 可读性：命名规则应该简洁清晰，使用易于理解的词汇或缩写，以方便人们快速辨识服务器。
1.3 可扩展性：在为服务器命名时，应该考虑到未来的网络扩展，避免使用与其他服务器重复的名称。
2. 命名规则实践2.1 用途标识：在服务器命名中可以使用缩写或特定词汇来表示服务器的用途，例如，web表示Web服务器，db表示数据库服务器。
2.2 位置标识：可以使用位置信息来标识服务器，例如，NY表示纽约机房，LDN表示伦敦机房。
2.3 规模标识：可以使用数字来表示服务器的规模，例如，01表示第一台服务器，02表示第二台服务器。
2.4 业务标识：在多业务环境中，可以使用特定的业务名称来标识服务器，例如，Finance表示财务业务的服务器。
2.5 扩展标识：在服务器命名规则中要预留部分标识位，以便于将来网络扩展时新增服务器的命名。
3. 注意事项3.1 避免使用特殊字符：命名规则中应禁止使用特殊字符，以避免引起操作系统或网络设备的命名异常。
3.2 避免使用过长命名：命名规则中应尽量避免过长的名称，以避免造成书写、输入或查询的不便。
3.3 避免使用敏感信息：命名规则中应禁止使用包含敏感信息的词汇或缩写，以确保服务器信息的安全性。
4. 服务器命名规则实例4.1 规则实例一：用途_规模_位置，例如，WEB_01_NY表示纽约机房的第一台Web服务器。
4.2 规则实例二：业务名称_用途_规模，例如，Finance_WEB_01表示财务业务的第一台Web服务器。
项目命名及管理规范
项目命名及管理规范引言概述：在软件开发过程中，项目命名及管理规范是非常重要的，它不仅能提高团队协作效率，还能方便项目的维护和扩展。
本文将从项目命名规范、项目管理规范、版本控制规范、文档管理规范和代码规范五个方面详细阐述。
一、项目命名规范：1.1 项目名称：项目名称应简洁明了，能够准确表达项目的功能和目的。
避免使用缩写或过于复杂的词汇，以免给团队成员带来困扰。
1.2 文件命名：文件命名应具有描述性，能够清晰地表达文件的内容和作用。
采用驼峰命名法或下划线命名法，统一命名风格，便于团队成员的理解和查找。
1.3 目录结构：项目目录结构应合理划分，按照功能或模块进行分类，以便于团队成员的协作和维护。
同时，应遵循统一的命名规范，方便团队成员的理解和使用。
二、项目管理规范：2.1 项目计划：在项目启动阶段，制定详细的项目计划，包括项目目标、里程碑、资源分配等内容，明确项目的时间和质量要求，确保项目的顺利进行。
2.2 任务分配：根据项目计划，合理分配任务给团队成员，明确每个人的责任和工作内容。
同时，建立良好的沟通机制，及时了解项目进展和解决问题。
2.3 进度管理：定期进行项目进度的跟踪和评估，及时发现和解决项目中的问题和风险。
同时，建立项目管理工具，记录项目的进展和问题，方便团队成员的参考和回顾。
三、版本控制规范：3.1 分支管理：根据项目的需要，合理划分分支，如开发分支、测试分支和发布分支等。
每个分支应有明确的目的和规范的操作流程，确保代码的稳定性和可维护性。
3.2 提交规范：团队成员在提交代码时，应遵循统一的提交规范，包括提交信息的格式和内容要求。
提交信息应简洁明了，能够清晰地表达代码的修改内容和目的。
3.3 版本发布：在代码经过测试和审核后，进行版本的发布。
每个版本应有明确的版本号和发布说明，方便用户了解和使用。
同时，建立版本回退机制，确保项目的稳定性和可靠性。
四、文档管理规范：4.1 文档分类：根据项目的需要，将文档进行分类，如需求文档、设计文档和测试文档等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
8.3.3惟一标识符和字符串名 系统中的每一对象给定一个惟一的标识符 （UID），即在系统中，它惟一地指称该对象。一 个对象的UID在其整个生命期内决不改变。特别， 当一个对象从一站点迁称到另一站点时其UID仍保 持不变。 事实上，一个UID是相关对象的绝对名字，它 通常是利用系统时钟产生的。UID也可作为一种权 限（capability）使用，在这种情况下，与其相关 的对象是受保护的，它既不能由用户改变，也不应被 用户忘却。 为了使UID在全系统范围内惟一，也可以将局 部宿主ID作为它的一部分。此外，它还可含有一些 随机生成的位，使得它难以猜测，从而起到保密作用。
例如，VMS的命名体系是层次式的。如图8.4所示。
例如，DEC网的命名方式，如图8.5所示
远程站点上的文件可通过把该站点名加在相应文件 的路径名之首来进行访问。例如， site1::userdisk:\dir2\me\letter.dom 在这种方案中，站点名必须惟一，且每个站点必须 知道系统中所有其他站点的名字。这种方案很容易实现， 用户也比较容易掌握。不过，它存在下面的问题： 1. 由于文件的位置作为文件名的一部分，当文件迁 移时，文件名需改变，相关文件操作也需修改。 2.若一文件有多个文件副本位于不同站点上，就有 不同的名字，对其中任何一个的更改都容易导致不一致 性。 3.系统的某些细节（如站点）对用户是可见的，这 是分布式系统所不希望的。 *设计命名方案的一个基本观点是：名字是依赖于 位置还是独立于位置。
图8.1 给出了当客户用文本名字对某一资源（如文件）进行操作时，一 些不同类型的名字是如何组合在一起的。 分布式系统中使用的许多名称都是有特定含义的，客户（用户或进程） 使用这样的名称请求服务系统对它管辖的命名对象和资源进行操作。如图 8.1所示。 引用超出任何单一服务系统范围的实体时，也需要命名。这些实体的典 型例子包括用户、计算机及服务系统本身。这些命名要求在范围上应该是全 球的。 名称和对象之间的联结称为联编（binding）。 一般而言，属性值或是基本值，如整数，或是自身的名称，如 internet地址。最终，所有的名称都要被简化成基本值或不能再进一步 “查找”的基本名，如以太网址。与名称相关的属性不仅对用户而且对其他 服务都是有用的。
8.2 一般的的命名方式 在计算机系统中，每个对象一般有两个名字，一个是由用户识别的文 本名（符号名），另一个是由系统使用的内部名。内部名可以是该对象的 实际位置，也可以是查询该对象之地址的一种表示形式。同一对象可能有 多个名字，一个名字也可用来代表不同的对象（在不同的作用域内）。通 过某种映射，系统可以把用户定义的符号名转换成相应的内部名。 图8.2 给出了一个简单的文件目录结构。
8.1.2 命名服务系统 命名服务系统管理着一个联编数据库，其中存 储着文本名（可读的）及其相关的属性。命名服务 系统支持的主要操作是解析一个名字——在该数据 库中查找给定名字的相关属性，此外还有为新名字 生成新的联编、删除联编以及列出已联编的名字等 操作。名字管理从其他服务中独立出来很大程度上 是因为分布式系的开放性，此外还有以下原因： 一致性：让不同的服务器或服务系统管理的资 源出现在同一命名方案中是比较方便的。 集成（integration）：在分布式系统中，不 一定总能预测共享的范围。有时候，需要共享和命 名在不同管理域中创建的资源，这可能会引起问题。 例如，合并两个用户集，可能发生用户名冲突。
8.3.2 分布式系统中的命名方案 分布式系统中常用的命名方案有绝对命名、相对命名和 层次式命名三种。 · 由绝对命名方案命名的名字是全系统范围惟一的、无二义 性的。在机内，这类名字通常是由时钟或计数器之值产生的位 串。 · 由相对命名方案命名的名字依赖于使用它的上下文。对于 不同的使用者，一个对象的名字可以是不同的，或者说，一个 对象的名字不惟一。 · 层次式命名方案用如下方式组织系统中的对象名： （1）对象被分划成若干组； （2）每组给定全局唯一的组名； （3）每组中的每个对象在组内给定唯一的名字； （4）一个组中对象名还可按此方式进一步分划成若干组；
8.4名字服务器的设计 名字服务器（name server）的主要功能是将一个符号串名（一个 整数串名或字符串名）映射成系统内惟一的物理地址。名字服务器管理着 包含有“名字及其物理地址”的对照表，系统中的所有服务程序都由名字 服务器来寻址和定位。 设计名字服务器一般有中央方式、复制方式和分划方式三种途径。 · 用中央方式设计时，全系统仅有一个（中央）名字服务器，系统中的 所有服务器程序都由它来寻址和定位。但由于性能及可靠性方面的原因， 这种方式不常用。 · 用复制方式时，每个站点都有一个名字服务器的副本，用以管理该站 点上的所有服务程序及本站点与其他站点间相互请求的服务信息。 · 分划方式意指： （1）若系统由若干子系统（子网）组成，则对于每个子系统，用一 个名字服务器管理本子系统上的所有服务程序及本子系统与其他子系统相 互请求的服务信息。 （2）若系统的命名空间可根据某种方式来分划，则对于每个经这样 分划后的实体，用单独的或复制式的名字服务器管理。 （3）将命名空间组织成层次结构来管理。
8.1.3 命名服务的一般要求 命名服务起初是很简单的，它只需要在单一的 管理域中将名字和对应的地址联编起来。网络互连 和分布式系统规模的扩大，使得名字映射问题变得 越来越复杂。 1、处理任意数量的名字并为任意数量的管理组 织服务 2、长生命期： 3、高可靠性： 4、故障隔离： 5、容忍怀疑： Internet域命名系统（DNS）使用得非常广泛， 它命名Internet上的对象（用户和计算机）。
字符串名（简称串名，即文本名或符号名）具有如 下特征： ●同一串名可由不同的用户用来访问不同的对象； ●不同的串名可由（不同的）用户用来访问相同的对 象； ●对象可以在站点间迁移不必改变其串名。
实际上，在大多数系统中，字符串名主要供用户使用， 而UID仅供操作系统使用。UID通常是定长、压缩形 式的。字符串名一般较长且往往是可变长的。操作系统 提供了从字符串名到UID的映射。
8.5.2 与透明性相关的几个问题 在一个实用的分布式操作系统中提供完全的透明 性是比较困难的，而且也未必总是需要的。因为透明 性与分布式系统的下面几点要求相冲突： （1）局部自治性：在一个分布式系统中，某个站 点的管理者或拥有者总希望对它的资源保持尽可能多 的局部控制，这一点有时可能与系统的透明性相冲突。 （2）优化：在某些情况下，用户可能希望知道资 源位置的显示信息并对它进行控制，这可能出于优化 系统性的要求。这方面的要求显然与透明性是相冲突 的。 （3）异构：完全透明性是很难的，这个问题体现 在两个方面。第一是基础硬件可随站点的不同而异。 第二是各站点上都可能运行不同的系统软件。
8.3 分布式系统中的命名方式 8.3.1 名字管理器的主要功能 分布式操作系统中名字管理部分的主要功能是： · 通过管理名字在系统的地址去定位命名过的对象。 · 创建、删除、改变对象的名字。 · 改变对象的位置，以支持对象在系统中的迁移。 · 利用对象名字来支持对象的共享。 · 创建一个对象组。 · 从组中删除成员或将成员加入其中。 · 枚举组中的成员。 · 测试组中成员之间的关系。 · 借助组名共享资源或共享服务程序。 · 支持对象组的递归结构。 · 完成外部名（符号名）到内部名（系统名）的映射 工作。
由于系统可以有多个用户，因此，目录常常组织成层次结构，如图 8.3所示。 文件名不仅指文件名本身，而且也应包括它与根之间所有目录的名字 （路径名）。 大多数系统允许用户设置一个默认目录或当前目录，在这种前提下， 用户不必写出完全路径名。 由于分布式环境中的名字可用来指称不同站点或不同站点的不同层次 结构上的对象，因此与单机系统相，其命名和名字的映射工作更加复杂。 下面讨论分布式环境下的命令方式及有关问题。
第八章 命名服务与透明性 8.1 概述 在一个分布式系统中，名字可用于指称或索引各种类型的资 源，包括计算机、服务、端口、个体对象以及用户。分布式系统 中资源的共享与通信需要名字，用户（客户）请求计算机操作诸 多资源中的某个特定对象时需要使用名字。 8.1.1 名字与属性 名字可分为人们可读的文本名和系统标识符。前者便于人们 识别和记忆，后者是软件用来对资源进行有效地解释和存储的名 字形式，是一个定长的位串，二者统称为名称（name），下面 是本书中出现的几中名称： · 物理网址和逻辑网址：这类名称可视为名字的位置或地址； · 端口、进程和组标识符：这类名称可视为消息的目的地； · 资源标识符：由服务器和内核管理的资源的低层独立定位的 标识符； · 文件：使用人们可读的文本名字进行存取的信息集。
8.5 分布式系统的透明性 系统的透明性（transparency）是指系统的内部细节对用户是隐藏的。 一个真正透明的分布式系统的用户把该系统看成是一个统一的整体。例如，它可 以任意迁移系统中的某一文件而不必改变文件的名字。 8.5.1 透明性 分布式系统的透明性主要包含以下方面： （1）名字透明性：每个对象有一个全局名字 （2）位置透明性：对象的名字独立于该对象的位置 （3）程序执行的透明性：可在系统内任意处理机上调度程序执行 （4）存取透明性：存取一个对象与该对象的位置无关 （5）并发存取透明性：任意一个用户并不知道有多个用户在并发存取 （6）进程透明性：为一台机器编写的程序可在多台机器上运行 （7）复制透明性：某个用户并不知道某个对象是复制的 （8）故障透明性：系统的某些故障可以隐藏而不影响系统 （9）文件系统透明性：不知文件的存放位置、文件的副本有多少等信息 （10）性能透明性（又称网际透明性）：访问远地资源与本地资源无异 （11）全局透明性：用户像使用单机一样使用分布式系统 不难看出，命名方案与透明性问题极为相关，系统的透明性隐含了下面的事 实： · 资源的位置不应嵌入其名字中： · 名字应该是全局惟一的。