‘壹’ eoq模型的优缺点
优点：经济订货批量模型是目前大多数企业最常采用的货物定购方式.该模型适用于整批间隔进货、不允许缺货的存储问题，即某种物资单位时间的需求量为常D，
存储量以单位时间消耗数量D的速度逐渐下降，经过时间T后，存储量下降到零，此时开始定货并随即到货，库存量由零上升为最高库存量Q，然后开始下—个存储周期，形成多周期存储模型。
缺点：
①它是一项鲁莽的投资政策——不顾有多少可供使用的资本，就确定投资的数额。
②它强行使用无效率的多阶段订货办法，根据这种办法所有的部件都足以不同的周期提供的。
③它回避准备阶段的费用，更谈不上分析及减低这项费用。
④它与一些成功的企业经过实践验证的工业经营思想格格不入。
(1)存储模型问题背景扩展阅读
虽然EOQ模型可以确定最佳的补给数量，但它需要某些相当严格的假设才能直接应用。在简单的EOQ模型中需要做出的主要假设有：
①已知全部需求的满足数；
②已知连续不变的需求速率；
③已知不变的补给完成周期时间；
④与订货数量和时间保持独立的产品的价格不变（即购买数量或运输价格不存在折扣）；
⑤不限制计划制定范围；
⑥多种存货项目之间不存在交互作用；
⑦没有在途存货；
⑧不限制可得资本等。不过，通过计算上的延伸，可以克服这些假设强加的限制。总而言之，EOQ概念说明了与存放成本和收购成本有关的优选问题的重要性。
‘贰’ 语义信息的存储
无论是知识库还是服务的语义描述都需要具有良好的组织和存储，以支持高效推理和服务检索发现。目前对于本体的存储方法基本有三种(李勇等，2008):
(1)纯文本，如 OWL 文件。由于 XML 的信息组织和存储方式结构复杂，而且存在冗余等，基于其上的查询检索效率通常会比较低。纯文本的方式适合本体比较小的时候，不适合本体大规模应用的情况。
(2)数据库: 是一种比较好的持久化存储方式，最大好处是便于查找，可存放大本体，查询效率高，特别在 I/O 效率上。但是数据库方式存在本体查询语言到 SQL 的转换问题，需要借助于第三方中间件或自定义实现。
(3)专门的管理工具: 比如说 OMM(Ontology Middleware Mole)支持对 RDF、OWL 的存储管理，还提供各种接口，可以使用查询语言对 RDF 或者 OWL 进行查询。综合对比这三种本体存储方式，由于关系数据库存储几十年的技术积累，以及它的海量存储特点而成为了许多研究者的首选。
5.4.3.1 本体的关系数据库存储模式
由于本体模型和关系模型的差异，目前存在多种在关系模型中存储本体的方法，其主要可以分为以下四类(陶皖等，2007; 陈光仪，2009)。
5.4.3.1.1 水平模式
该模式只在数据库中保留一张通用表，表中列为本体中的属性。整个本体库中定义了多少个属性，这张表就有多少个列，具体如图 5.28 所示。本体中的每个实例对应该表中的一条记录。这种存储模式结构简单，执行查询操作比较方便。但是该通用表包含了大量的列，而现有的数据库系统对一张表中列的个数都是有限制的，所以该模式无法存储规模较大的本体。而且表中的数据过于稀疏。由于每个实例对应关系表中的一行，如果其在某些属性列上没有值，那么必须将对应的属性值设置为空，这将导致大量空字段的出现，不仅浪费存储空间，而且增加了索引维护的代价。另外该通用表中一个实例的属性和属性值只能是一对一，而实际情况往往是一对多，因此无法存储具有这种特征的本体。随着应用中本体的进化，还需要时常更新通用表中的列，重新组织表结构，这将耗费极大的系统代价。
图 5.28 水平存储模式
5.4.3.1.2 垂直模式
垂直模式包含一张三元组表，表中的每条记录都对应一个 RDF 三元组(主语，谓词，宾语)，具体如图 5.29 所示。因此这种模式下，需要将本体中的所有信息都以 RDF 三元组的形式表示出来。Protege(2002)中便是使用了这种存储模式将本体存储于数据库中。这种模式设计简单，并且结构稳定。如果本体进行了更新，只需修改表中相应的元组即可。另外，该模式通用性好，因为现有的本体模型都可以转换为 RDF 模型表示。但是这种模式的可读性较差，若对本体信息进行查询，那么设计对应的 SQL 语句比较麻烦。除此之外，由于所有信息都存放在三元组表中，导致任何一个本体信息查询都必须遍历整个数据表，特别是那些需要进行表连接的查询，使得查询效率非常低，这是这种模式最大的不足之处。
图 5.29 垂直存储模式
5.4.3.1.3 分解模式
该模式与水平模式和垂直模式的一个显着的区别是它使用了若干张表，其基本思想是将数据库进行模式分解。根据分解的对象不同，现有的采用分解模式的方法有两种。①基于类的分解模式，即为本体中的每个类都创建一张单独的表，表名为类名，表的列为类的属性，具体如图 5.30 所示。这种模式结构清晰，但是很难适应本体动态变化的情况，因为随着本体中类或者属性的变化，表结构都要随着变化。②基于属性的分解模式，即为本体中的每个属性创建一张单独的表，表名为属性名，每个表都包含两个列，分别代表RDF 三元组中的主语和宾语，具体如图 5.31 所示。在该模式中对类的隐含实例的查询代价很大，而且在现有的这两种分解模式的方法中，随着本体的变化都要不断的创建和删除表，而在数据库系统中创建和删除表的效率很低。
图 5.30 按类分解模式
图 5.31 按属性分解模式
5.4.3.1.4 混合模式
该模式通常将上述几种模式进行混合使用。例如，Pan 等(2003)提出这样一种将基于类的分解模式与基于属性的分解模式混合的存储模式，即在本体中定义一个类就为该类创建一个表(创建方法类似于基于类的分解模式)，在本体中定义一个属性就为该属性创建一个表(创建方法类似于基于属性的分解模式)。然而，与基于类的分解模式不同的是，该混合模式在类对应的表中不记录相应实例的所有信息，而只记录实例的 ID。实例在各个属性上的取值则分别记录在各属性对应的表中，所以和基于属性的分解模式类似，该模式在属性对应的表中仍然需要两列: 主语和宾语。对于本体类数目不多的情况下，这种模式在简单检索的情况下，运行得很好。但是，如果本体的类比较多，这种方式就会存在一些问题，例如: 数据库无法容纳这么多表，或者效率低下。
针对上述四种模式，陈光仪(2009)从四个方面对适用场合、查询和更新效率、结构清晰以及易理解性、可扩展性四个方面对他们进行了综合对比(表 5.4):
表 5.4 不同存储模式的综合对比
(修改自陈光仪，2009)
通过上述对本体存储模式的阐述及之间的综合对比发现，本体存储模式除了应该具有尽量高的规范化程度(例如满足第三范式或 BCNF 范围等)，还应该满足以下三个原则。
(1)模式结构易于理解。该原则是为了便于本体查询的实现。如果模式结构不直观，会给查询语句的设计带来困难。例如，垂直模式不满足该要求，它将所有的信息都采用三元组的形式存储在一张表中，不容易理解表中元组的含义，加重了本体查询设计的负担。
(2)模式结构稳定。即本体的变化不会引起数据库表结构的变化。因为本体是不断进化的，如果设计的模式结构会随着本体的变化而变化，数据库系统对其维护代价太大。现有的水平模式、分解模式和混合模式都不满足该要求。
(3)查询效率高。该原则是评价各种存储模式的一个重要指标。因为本体中不仅包含大量的数据，而且查询中还经常需要进行表连接。例如在现有的垂直模式和基于属性的分解模式中，那些涉及表连接的查询效率非常低。
目前在基于数据库的本体存储的实践上，一些学者开展了相关的研究工作:
燕云鹏(2007)和陈光仪(2009)提出了类似的针对于针对 OWL 的本体数据库的混合本体存储模式(图 5.32，5.33)。可以看出这种模式是以基于属性的分解模式与垂直模式的混合体，具有较好的扩展性。但是存在的问题是效率不够高，所有的类存储在一个表中，所有的实例也存储在一个表中，这种方式的检索效率比较低。另外存储实例的表(Instance，Proterty，Value)中字段 Value 必须存储许多种不同类型的数值，比如有的是文本型，而有的却是数值型，使得数据不够清晰。此外，在针对几何体这种复杂的地理对象，这种字段就比较难以存储。
图 5.32 本体的数据库混合存储模式(据燕云鹏，2007)
ebRIM(ebXML Registry Information Model)是一个主流的信息注册模型，已成为事实上的标准，得到了 OGC 等支持。OGC 已经实现了基于 ebRIM 的目录服务，并推荐其作为目录服务的实现规范。但是目前基于 ebRIM 的目录服务只支持普通的基于关键字的检索。为此，一些学者已经开始研究如何扩展 ebRIM 实现对语义信息特别是 OWL 的注册。Dogac 等(2004)提出了如图 5.34 所示的一种通过将 XML 形式存储的 OWL 文件转换为以数据库形式存储，使得查询检索更加快速，管理维护也更加方便。为了能在 ebRIM 存储复杂的地理空间信息对象，一些学者开展了基于 ebRIM 的地理扩展方面的研究工作。乐鹏(2007)在其论文中提出了两种扩展方式: ① 从类 “ExtrinsicObject” 派生了“CSWExtrinsicObject”来描述那些不是 ebRIM 自身定义的元数据对象。比如类 “Dataset”继承了 “CSWExtrinsicObject”来描述空间数据集。②对 ebRIM 已有的类别增加 “Slot”。每一个从 “RegistryObject”继承下来的类均允许添加 “Slot”。ebRIM 中的 “Service”类可以用来描述空间服务，但是已有的属性不足以描述空间网络服务。因此，通过添加“Slot”到 “Service”类中以定义从 ISO 19119 派生的属性。如图 5.35 所示为经扩展后的ebRIM 高层模型图，其中 灰 色 填 充 的 矩 形 框表示 扩 展 的对 象 类。该 模 式 与 前 面 燕 云 鹏(2007)和陈光仪(2009)提出的模式相比，本质上差别不大，也是以基于属性的分解模式与垂直模式的混合体，只不过是基于标准的 ebRIM 注册模型，并且将其中的分类系统相关的类单独以两张表存储。该模式也具有很好的扩展性，也存在同样的一些问题。
图 5.33 本体的数据库混合存储模式(据陈光仪，2009)
海洋信息网格技术与应用
续表
5.34 OWL 元素到 ebRIM 元素的映射(Dogac et al.，2004)
5.4.3.2 基于多分解策略的混合存储模式实现
对知识库以及服务语义注册信息的存储的实现上，本书在现有的研究成果的基础上，结合本体组织构成及特点等实际需求，提出了一种基于多分解策略的混合关系数据库存储模式。
该方法的指导思想是: 先按类对其中的数据专题、数据模式、处理模型等进行类的分解，然后结合属性的特性进行基于属性的分解。其中基于类的分解中，可能粒度的大小不一，可能是一个类或者具有相关或相似的一些类划分为一张表存储; 而基于属性的剖分，也并不是所有具有该属性的类以一个表存储，而可能是只针对一个类也单独组织为一张表，其具体思路如下:
图 5.35 经扩展的 ebRIM 高层模型图(据乐鹏，2007)
(1)类的分解: 因为本研究的存储模型不是为了实现一个通用的本体存储模型，而是为了实现一个服务于海洋信息服务领域的本体存储模型。海洋信息服务领域必然会牵涉到一些对象，比如对服务、模型、参数等对象，并且对这些对象的认识也基本上确定(也就是说这些对象类所具有的属性及之间的关系基本明确)，所以没必要像上面几种实现方案那样因为不能预知都有哪些类，各类都有哪些属性而将所有的实例的组织按垂直方式进行存储，也没有必要有一些表(比如独立的属性表，属性的作用域和值域表等); 而有必要针对海洋信息服务领域内的这些类的信息内容独立出一些表: 对于海洋专题，地理名实体、处理模型、数据模式等海洋信息检索发现中常用的对象，则有必要进行分开存储，否则必然使得结构不清晰，且检索查询效率低。
(2)对于专题、空间形态以及模型功效等只是简单的分类系统，所具有的属性少，而且今后存在派生新的种类的可能，因此必须具备一定的扩展性。针对这类数据。它们的存储方式是(ClassID，ParentClassID，ClassType)，其中 ClassType 标注本体类是属于专题(比如 “海流”)或者其他。
(3)对于取值不唯一的属性，且大部分类或实例都具有的属性，则采用基于属性的分解模式。比如对于别名属性(hasAliasName)，有可能一个类实例具有多个别名，这种情况下，则采取基于属性的组织方式。该表的形式是:(OntologyID，AliasName)，其中OntologyID 可以是本体类的 ID，也可以是本体实例的 ID，还可以是本体属性的 ID，因为类、实例和属性都可以有别名。
(4)对于复杂的属性，采取大二进制存储的方式。比如对于地名实例的空间覆盖范围，则不考虑其实际内部是包含多少个组成部分，统一按一个 shape 存储在数据库中。当然这里借助了 ArcGIS 的 GDB 的 FeatureClass 矢量数据模型，并对于不同空间形态的则采用了多张表(点状地名类、线状地名类、面状地名类)，其组织方式是(GeoNameObjec-tID，shape)。同样，对于模型本体中的内部流程本体，也采用了大二进制方式存储，将整个流程 XML 描述文件，作为一个整体存放于字段中，其大体组织方式为(ModelID，FlowXML)。
(5)本研究采用 ArcGIS 的 GeoDatabase 作为存储模型。本体类(ontClass)的存储结构如图 5.36 所示，数据库的总体组织结构如图 5.37 所示。
图 5.36 本体类(onClass)的存储结构
‘叁’ 文件的逻辑存储模型为
逻辑文件一般指文件逻辑结构，文件的逻辑结构是用户可见结构。逻辑文件从结构上分成二种形式：一种是无结构的流式文件，是指对文件内信息不再划分单位，它是依次的一串字符流构成的文件。一种是有结构的记录式文件， 是用户把文件内的信息按逻辑上独立的含义划分信息单位，每个单位称为一个逻辑记录
文件的逻辑结构：
文件的逻辑结构是用户可见结构。逻辑文件从结构上分成二种形式：
一种是无结构的流式文件，是指对文件内信息不再划分单位，它是依次的一串字符流构成的文件。
一种是有结构的记录式文件, 是用户把文件内的信息按逻辑上独立的含义划分信息单位，每个单位称为一个逻辑记录（简称记录）。
所有记录通常都是描述一个实体集的，有着相同或不同数目的数据项，记录的长度可分为定长和不定长记录两类。
在文件系统设计时，选择何种逻辑结构才能更有利于用户对文件信息的操作呢?
一般情况下，选取文件的逻辑结构应遵循下述原则：
(1)当用户对文件信息进行修改操作时，给定的逻辑结构应能尽量减少对已存储好的文件信息的变动。
(2)当用户需要对文件信息进行操作时，给定的逻辑结构应使文件系统在尽可能短的时间内查找到需要查找的记录或基本信息单位。
(3)应使文件信息占据最小的存储空间。
(4)应是便于用户进行操作的。
‘肆’ 简述记忆的多重存贮模型
当前得到公认的解释记忆储存的模型是记忆的三存储模型,该模型认为记忆加工有三个不同的阶段,它们分别是感觉记忆,短时记忆和长时记忆.来自环境的信息首先到达感觉记忆.如果这些信息被注意,它们则进入短时记忆.正是在短时记忆中,个体把这些信息加以改组和利用并作出反应.为了分析存人短时记忆的信息,你会调出储存在长时记忆中的知识.同时,短时记忆中的信息如果需要保存,也可以经过复述存入长时记忆.
一,感觉记忆
感觉记忆又称感觉寄存器或瞬时记忆,是感觉信息到达感官的第一次直接印象.感觉寄存器只能将来自各个感官的信息保持几十到几百毫秒.在感觉寄存器中,信息可能受到注意,经过编码获得意义,继续进入下一阶段的加工活动,如果不被注意或编码,它们就会自动消退.
各种感觉信息在感觉寄存器中以其特有的形式继续保存一段时间并起作用,这些存储形式就是视觉表象和声音表象,称视象和声象.它们虽然保存的时间极短,但在生活中也有自己的作用.例如,在看电影时,是视象帮助我们把相继出现的一组图片看成是一个平滑连续的画面.大多数视象持续的时间不会超过一秒钟,但在有些情况下,一些视象可以持续更长的时间.这取决于刺激的强度(如亮度),视觉剌激的强度越大,视象消失得越慢.
声象记忆和视象记忆基本上具有相同的性质,只是声象在感觉寄存器中的持续时间较长,可达几秒钟.使得我们能够有更多的时间加工语音信息,达到词的意义.研究表明,视象和声象是物理刺激的忠实复制品,是感觉器官提供的信息的有效拷贝.选择性注意控制着什么信息将得到进一步的加工,传递到短时记忆.
二,短时记忆
短时记忆(STM)也称工作记忆,是信息加工系统的核心.在感觉记忆中经过编码的信息,进入短时记忆后经过进一步的加工,再从这里进入可以长久保存的长时记忆.信息在短时记忆中一般只保持20~30秒,但如果加以复述,便可以继续保存.复述保证了它的延缓消失.短时记忆中储存的是正在使用的信息,在心理活动中具有十分重要的作用.首先,短时记忆扮演着意识的角色,使我们知道自己正在接收什么以及正在做什么.其次,短时记忆使我们能够将许多来自感觉的信息加以整合构成完整的图像.第三,短时记忆在思考和解决问题时起着暂时寄存器的作用.例如在做计算题时每做下一步之前,都暂时寄存着上一步的计算结果供最后利用.最后,短时记忆保存着当前的策略和意愿.这一切使得我们能够采取各种复杂的行为直至达到最终的目标.正因为发现了短时记忆的这些重要作用,在当前大多数研究中被改称为工作记忆.
‘伍’ 简述企业存货管理的存储模型原理
存货管理实质就是库存管理,1915年，美国的F·W·哈里斯发表关于经济订货批量的模型，开创了现代库存理论的研究。在此之前，意大利的V·帕雷托在研究世界财富分配问题时曾提出帕雷托定律，用于库存管理方面的即为ABC分类法。随着管理工作的科学化，库存管理的理论有了很大的发展，形成许多库存模型，应用于企业管理中已得到显着的效果。
库存管理模型的分类：
（1）不同的生产和供应情况采用不同的库存模型。按订货方式分类，可分为5种订货模型。
①定期定量模型：订货的数量和时间都固定不变。
②定期不定量模型：订货时间固定不变，而订货的数量依实际库存量和最高库存量的差别而定。
③定量不定期模型：当库存量低于订货点时就补充订货，订货量固定不变。
④不定量不定期模型：订货数量和时间都不固定。
以上4种模型属于货源充足、随时都能按需求量补充订货的情况。
⑤有限进货率定期定量模型：货源有限制，需要陆续进货。
（2）库存管理模型按供需情况分类可分为确定型和概率型两类。确定型模型的主要参数都已确切知道；概率型模型的主要参数有些是随机的。
（3）按库存管理的目的分类又可分为经济型和安全型两类。经济型模型的主要目的是节约资金，提高经济效益；安全型模型的主要目的则是保障正常的供应，不惜加大安全库存量和安全储备期，使缺货的可能性降到最小限度。库存管理的模型虽然很多，但综合考虑各个相互矛盾的因素求得较好的经济效果则是库存管理的共同原则。
具体的详细模型，您可以参照网络文库里的资料，在网络文库里输入“存储模型”，点击查看其中的PPT，查看更加方便快捷，看起来也舒服。
‘陆’ 仓库管理系统的背景和意义
一、仓库管理系统的背景：
随着计算机的应用普及，目前大多数企业的仓库管理数据资料已开始采用计算机数据系统管理，但数据还是采用先纸张记录、再手工输入计算机的方式进行采集和统计整理。这不仅造成大量的人力资源浪费，而且由于人为的因素，数据录入速度慢、准确率低。
随着企业规模的不断发展，仓库管理的物资种类机数量在不断增加、出入库频率剧增，仓库管理作业也已十分复杂和多样化，传统的人工仓库作业模式和数据采集方式已难以满足仓库管理的快速、准确要求，严重影响了企业的运行工作效率，成为制约企业发展的一大障碍。
二、仓库管理系统的意义：
仓库管理系统帮助企业解决了以下问题：
（1）采集输入代替手工输入减少了失误率。
（2）使产品信息能快速录入到数据库中
（3）减少了原材料的浪费和成品的丢失。
（4）为企业把生产和销售整合在一起。
拓展资料：
简介：
使用条形码管理系统 , 对仓储各环节实施全过程控制管理，并可对货物进行货位、批次、保质期、配送等实现条形码标签序列号管理，对整个收货、发货、补货、集货、送货等各个环节的规范化作业 , 还可以根据客户的
仓库管理系统流程示意
需求制作多种合理的统计报表 .凭借丰富的条码资源及多年实施条码系统的经验，将条码引入仓库管理，去掉了手工书写票据和送到机房输入的步骤，解决库房信息陈旧滞后的弊病。不论物品流向哪里，我们都可以自动跟踪。条码技术与信息技术的结合帮助企业合理有效地利用仓库空间，以快速、准确、低成本的方式为客户提供最好的服务。
仓库管理系统是通过入库业务、出库业务、仓库调拨、库存调拨和虚仓管理等功能，综合批次管理、物料对应、库存盘点、质检管理、虚仓管理和即时库存管理等功能综合运用的管理系统，有效控制并跟踪仓库业务的物流和成本管理全过程，实现完善的企业仓储信息管理。该系统可以独立执行库存操作，与其他系统的单据和凭证等结合使用，可提供更为完整全面的企业业务流程和财务管理信息。
‘柒’ 云存储的核心技术：虚拟化存储，究竟虚拟是怎样实现的
虚拟化改变了计算机使用存储的方式。就像物理机器抽象成虚拟机（VM：Virtual Machine）一样，物理存储设备也被抽象成虚拟磁盘（Virtual Disk）。今天我们就来聊聊虚拟化存储（Storage Virtualization）技术，究竟虚拟磁盘是怎样实现的？
虚拟磁盘的实现
我们知道，服务器扩展存储的手段主要有直连存储（DAS）、存储区域网络（SAN）和网络附加存储（NAS）这三种类型。那么哪种存储类型可以用来实现虚拟磁盘呢？
在虚拟化环境中，类似VMWare这样的虚拟机管理程序hypervisor，要同时给很多VM分配存储空间。这个过程中，我们需要先把物理存储资源重新划分成虚拟磁盘，然后再分配给VM。
显然我们不能用DAS方式把物理磁盘直连到VM上，如果这样，需要的物理磁盘就太多了。SAN是以逻辑单元（LUN：Logic Unit）的形式提供存储资源，但是虚拟环境中VM的数量是很大的，而且伦的数量不足以支持这么多虚拟磁盘。
更重要的是，虚拟磁盘是为大量VM共享的，由于VM需要随时创建、删除或迁移，所以需要在迁移VM时共享存储空间，只有原始数据不会丢失。DAS还是SAN，都不适合共享存储。
考虑到资源分配以及共享的问题，虚拟机管理程序以NAS的方式实现虚拟磁盘。VMware通常使用VMFS（虚拟机文件系统）或NFS协议实现虚拟磁盘，VMFS文件系统是专门针对虚拟机环境协议。
每一个虚拟机的数据实际上是一堆文件，及最重要的文件的虚拟磁盘文件（VMDK文件），也有交换分区文件（VSWP文件，等价交换），非易失性存储器（NVRAM的文件相当于BIOS），等等。每个VM对虚拟磁盘的IO操作实际上是对虚拟磁盘文件的读写操作。
设计、施工、和虚拟服务器环境和优化，允许多个虚拟机访问集成的集群存储池，从而大大提高了资源的利用率。使用和实现资源共享，管理员可以直接从更高的效率和存储利用率中获益。
那么我们如何在云计算中使用虚拟磁盘呢？
实例存储
最主要的一种使用虚拟磁盘的方式就是实例存储，每个VM都是虚拟机的一个实例，虚拟机管理程序在每个实例中提供一个仿真硬件环境，它包括CPU、内存和磁盘。这样，虚拟磁盘就是虚拟机实例的一部分，就像物质世界。删除VM后，虚拟磁盘也将被删除。
在这个实例存储模型中，虚拟磁盘与虚拟机之间的存储关系，事实上，它是DAS存储。但是虚拟磁盘的底层实现，我们说，它是以NAS的方式实现的。虚拟机管理程序的作用是存储VM层的存储模型，这是从实施协议分离（VMFS或NFS）的虚拟机的低层。
VMFS协议实现了存储资源的虚拟化，再分配各VMs
卷存储
实例存储有它的限制，开发人员通常希望分离实例数据，例如OS和安装的一些服务器应用程序和用户数据，这样重建VM的时候可以保留用户的数据。
这个需求衍生出另外一种存储模型：卷存储。卷是存储的主要单元，相当于虚拟磁盘分区。它不是虚拟机实例的一部分，它可以被认为是虚拟机的外部存储设备。
该卷可以从一个VM卸载，然后附加到另一个VM。通过这种方式，我们实现了实例数据与用户数据的分离。OpenStack的煤渣是一个体积存储的实现。
除了实例存储和卷存储之外，最后我们还提到另一种特殊的虚拟存储：对象存储。
对象存储
很多云应用需要在不同的VM之间共享数据，它常常需要跨越多个数据中心，而对象存储可以解决这个问题。在前一篇文章中的云计算IaaS管理平台的基本功能是什么？》中曾经提到过对象存储。
在对象存储模型中，数据存储在存储段（bucket）中，桶也可以被称为“水桶”，因为它字面意思。我们可以用硬盘来类推，对象像一个文件，而存储段就像一个文件夹（或目录）。可以通过统一资源标识符（URI：统一资源标识符）找到对象和存储段。
对象存储的核心设计思想实际上是虚拟化，它是文件的物理存储位置，如卷、目录、磁盘等，虚拟化是木桶，它将文件虚拟化为对象。对于应用层，简化了对数据访问的访问，屏蔽了底层存储技术的异构性和复杂性。
对象存储模型
NAS与对象存储各有所长
当然你也许会问，NAS存储技术也是一个可以解决数据共享的问题吗？由于对象存储的大小和成本优势，许多云环境使用对象存储而不是NAS。
因为对象存储将跨多个节点传播，最新数据并不总是可用的 因此，对象存储的数据一致性不强。如果有强一致性的要求，然后你可以使用NAS。目前，在云计算环境中，NAS和对象存储是共存的。
和NAS一样，对象存储也是软件体系结构，而不是硬件体系结构。应用程序通过REST API直接访问对象存储。公共对象存储包括：Amazon S3和OpenStack的Swift。
结语
在实际的云平台应用中，我们需要根据自己的实际情况来合理运用不同的虚拟化存储技术。
对于非结构化的静态数据文件，如音视频、图片等，我们一般使用对象存储。
对于系统镜像以及应用程序，我们需要使用云主机实例存储或者卷存储。
对于应用产生的动态数据，我们一般还需要利用云数据库来对数据进行管理。
‘捌’ 北大青鸟java培训：Java内存模型原理
这篇文章主要介绍模型产生的问题背景，解决的问题，处理思路，相关实现规则，环环相扣，希望读者看完这篇文章后能对Java内存模型体系产生一个相对清晰的理解，知其然知其所以然。
内存模型产生背景在介绍Java内存模型之前，java课程http://www.kmbdqn.cn/认为应该先了解一下物理计算机中的并发问题，理解这些问题可以搞清楚内存模型产生的背景。
物理机遇到的并发问题与虚拟机中的情况有不少相似之处，物理机的解决方案对虚拟机的实现有相当的参考意义。
物理机的并发问题硬件的效率问题计算机处理器处理绝大多数运行任务都不可能只靠处理器“计算”就能完成，处理器至少需要与内存交互，如读取运算数据、存储运算结果，这个I/O操作很难消除(无法仅靠寄存器完成所有运算任务)。
由于计算机的存储设备与处理器的运算速度有几个数量级的差距，为了避免处理器等待缓慢的内存完成读写操作，现代计算机系统通过加入一层读写速度尽可能接近处理器运算速度的高速缓存。
缓存作为内存和处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速运行，当运算结束后再从缓存同步回内存之中。
缓存一致性问题基于高速缓存的存储系统交互很好的解决了处理器与内存速度的矛盾，但是也为计算机系统带来更高的复杂度，因为引入了一个新问题：缓存一致性。
在多处理器的系统中(或者单处理器多核的系统)，每个处理器(每个核)都有自己的高速缓存，而它们有共享同一主内存(MainMemory)。
当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致。
为此，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议进行操作，来维护缓存的一致性。
‘玖’ 魔兽争霸模型载入问题
魔兽争霸3 地图的游戏载入画面背景是一个 *.mdx 文件. 所有魔兽3的单位3D模型都是这种文件。
这种模型由两部分组成, 一是存储模型坐标动画等各种信息的MDX文件, 还有就是BLP或者TGA贴图文件(或者叫蒙皮,就是包裹模型的皮肤).
两部分都得正确才能显示出模型来.
注: BLP是暴雪开发的一种模型贴图压缩格式, TGA是一种常见的图片格式. 可以用ACDsee或者PhotoShop来转换格式.
用PhotoShop保存为TGA格式的时候一般选为24位,若是需要透明效果则选32位. 建议勾上"压缩RLE"以减小文件大小.
若希望制作自己的载入画面, 有两种办法:
一种是下载现成的载入画面模型,将其中的贴图文件修改成自己想要的样子.
另一种就是用3DMAX来完全自己制作, 当然这个比较复杂. 仅适合有制作过魔兽模型的朋友
现成载入画面修改：
这里我整理和制作了几种载入画面放到这个ZIP包里。请下载后选择自己适合的MDX和对应的TGA文件。
1.修改将要显示的tga图片文件为你需要的内容。
图象编辑通常工具用: WINDOWS画图, PhotoShop, CorelDRW......
2.导入你的地图中(注意导入后的tga文件路径为根目录)
打开WE,按"F12" 打开输入文件管理器. 导入相应的MDX和贴图文件.
3.指定运用该MDX文件为载入画面。
WE的菜单里 "情节->地图读取设定" ,选"使用输入的文件". 然后选中导入的载入画面MDX文件.保存地图后就可以察看效果了.
=========================================
LoadingScreen.mdx
4张图片显示地图载入画面左上,右上,下左,下右四个区域,其余区域为黑色背景.
图片路径为:
LoadingScreenTL.tga (左上, 尺寸: 512*512)
LoadingScreenTR.tga (右上, 尺寸: 512*512)
LoadingScreenBL.tga (下左, 尺寸: 512*256)
LoadingScreenBR.tga (下右, 尺寸: 512*256)
Loading.mdx
一张图片显示整个地图载入画面. 图片路径为: LoadingScreenTL.tga
建议图片尺寸为:1024*768 /800*600 /640*480 /512*384
Loading 2.mdx
一张图片显示地图载入画面左上方区域,其余区域为黑色背景. 图片路径为: LoadingScreenTL.tga
建议图片尺寸为:512*512 或 256*256
BOOMmapLoad.mdx
水元素动态效果的地图载入画面. (动态效果演示)
全部共使用魔兽争霸3自带的8张图片,无须再导入 图片路径为: Textures\Lords0000.blp ~~~ Textures\Lords0007.blp
BOOMmapLoad2.mdx
群星闪烁动态效果的地图载入画面. (动态效果演示)
使用魔兽争霸自带的的"Textures\Star7b.blp"图片作为星星, 另外需要导入一张路径为"LoadingscreenTL.tga"的512*512图片作为显示内容.
3DMAX制作魔兽3载入画面要求:
制作魔兽3模型只能是3DMAX4或5。需要安装 WarcraftIIIArtTools1.01 这些常识就不说了。
讲一下地图载入画面和一般模型区别的特殊之处：
3DMAX中仅仅很小一部分区域显示为地图载入画面的屏幕。
他们是从坐标: X=0, Y=0, Z=0, 到 X= 0.6 , Y= -0.8, Z=0。也就是第4象限靠着原点一个很小的矩形。
（有点奇怪的是3DMAX中的坐标和MDL文件中的坐标方向不一样， 当然我们不用管他）
贴图同一般的魔兽贴图，但贴图材质必须要勾上"Unshaded"才能显示出来。否则是看不到的。
可以加个轨迹还有动画片段：如 Birth。也可以不加。建议加上吧。
=================
1月份的时候我应某某要求地图需要载入画面中加入一些LOGO，搜索了网上都是些用现成的MDX来修改，我就想既然是魔兽模型那么应该可以用3DMAX来自己做个动态的，于是进行尝试却发现不少问题。经过反复实验总算找到了其中规律，在此分享给大家。相信很快就能在网络上看到各种漂亮的载入画面。