案例分析 4 分布式数据库缓存及其他

分布式数据库缓存及其他"/>

案例分析 4 分布式数据库缓存及其他

案例分析 4 分布式数据库缓存及其他

• 21
• 20
• 19 分布式缓存系统
• 18
• 17
• 14
• 13 second
• 13 fifth
• 12 first
• 12 fourth

21

【Q2】预约人员(患者)登录系统后发超预约挂号请求，进入预约界面。进行预约挂号时使用数据库访问类获取医生的相关信息，在数据库中调用医生列表，并调取医生出诊时段表，将医生出诊时段反馈到预约界面，并显示给预约人员;预约人员选择医生及就诊时间后确认预约，系统反馈预约结果,并向用户显示是否预约成功。
采用面向对象方法对预约挂号过程进行分析，得到如图2-2所示的顺序图,使用题千中给出的描述，完善图2-2中对象(1),及消息(2)~(4)的名称，将正确答案填在答题纸上，请简要说明在描述对象之间的动态交互关系时，协作图与顺序图存在哪些区别。

顺序图强调的是对象交互的时间次序；协作图强调的是对象之间的组织结果。

【Q3】采用面向对象方法开发软件，通常需要建立对象模型、动态模型和功能模型，请分别介绍这3种模型，并详细说明它们之间的关联关系,针对上述模型,说明哪些模型可用于软件的需求分析?

对象模型：描述了系统的静态结构，一般使用对象图来建模。对象模型是整个体系中最基础、最核心的部分。
动态模型：描述了系统的交互次序，一般使用状态图来建模。
功能模型：描述了系统的数据变换，一般使用数据流图来建模。

相互关系如下，

对象模型描述了动态模型和功能模型所操作的数据结构，对象模型中的操作对应与动态模型中事件和功能模型中的函数。
动态模型描述了对象模型的控制结构，告诉我们哪些决策是依赖于对象值，哪些引起对象的变化，并激活功能；
功能模型描述了由对象模型中操作和动态模型中动作所激活的功能，而功能模型作用在对象模型说明的数据上，同时还表示了对对象值的约束。

【Q 2 3 延伸】

【2】
该问考查UML中的顺序图，本问比较容易，累扣题目描述来组织内容即可，从题千中"预约人员(患者)登录系统后发起预约挂号请求，进入预约界面”的信息可知（1)应为预约人员(患者)，(2)为预约挂号请求;从题千中将医生出诊时段反馈到预约界面，并显示给预约人员”的信息可知(3)应为显示医生可预约时段;从题千中"系统反馈预约结果，并向用户显示是否预约成功"”的信息可知(4）应为显示预约是否成功。
序列图(顺序图）是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺字图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
协作图，和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色,以及它们彼此之问是如何通信的。
如果强调时问和顺序，则使用序列图;如果强调上下级关系或对象问组织结构，则选择协作图;这两种图合称为交互图。
【3】
该问考了一个较为早期提出的面向对象模型——OMT.OMT方法的OOA模型包括对象模型、动态模型和功能模型。
对象模型表示静态的，结构化的"数据^性质，它是对模拟客观世界实体的对象及对象间的关系映射，描述了系统的静态及结构。通常用类图表示。对象模型描述系统中对象的静态结构、对象之间的关系、对象的属性、对象的操作。对象模型表示静态的、结构上的、系统的”数据′特征。对象模型为动态模型和功能模型提供了基本的框架。对象模型用包含对象和类的对象图来表示。
动态模型表示瞬间的，行为化的系统控制性质，他规定了对象模型中的对象合法化变化序列。通常用状态图表示。动态模型描述与时间和操作顺序有关的系统特征–激发事件、事件序列、确定事件先后关系的状态以及事件和状态的组织。动态模型表示瞬间的、行为上的、系统的"控制"特征。动态模型用状态图来表示，每张状态图显示了系统中—个类的所有对象所允许的状态和事件的顺序。
功能模型表示变化的系统的功能性质，它指明了系统应该做什么，因此直接地反映了用户对目标系统的需求，通常用数据流图表示。功能模型描述与值变换有关的系统特征–功能、映射、约束和函数依赖。

20

【Q1】Redis支持丰富的数据类型，并能够提供一些常见功能需求的解决方案。请选择题干描述的(a)_{(g)功能选项，填入表4-1中(1)}(5)的空白处。

见： (关于redis)

【Q2】该网上社区平台需要为用户提供7×24小时的不间断服务。同时在系统出现宕机等故障时，能在最短时间内通过重启等方式重新建立服务。为此，开发团队选择了Redis 持久化支持。Redis有两种持久化方式，分别是RDB(Redis DataBase)持久化方式和AOF(Append OnlyFile)持久化方式。开发团队最终选择了RDB方式。请用200字以内的文字，从磁盘更新频率、数据安全、数据一致性、重启性能和数据文件大小五个方面比较两种方式，并简要说明开发团队选择RDB的原因。

Redis提供了两种持久化存储的机制，分别是RDB（Redis DataBase）持久化方式和AOP（Append Only File)持久化方式。RDB持久化方式是指在指定
的时间间隔内将内存中的数据快照写入磁盘，是Redis默认的持久化方式。AOF方式是指redis会将每一个收到的写命令都通过write函数追加到日志文件中。

两种方式各有优缺点，大致比较如下：
(1)磁盘更新频率：AOF比RDB文件更新频率高。
(2)数据安全:AOF比RDB更安全。
(3)数据一致性：RDB间隔一段时间存储，可能发生数据丢失和不一致；AOF通过append模式写文件，即是发生服务器宕机，也可以通过redis-check-aof工具解决数据一致性问题。
(4)重启性能：RDB性能比AOF好。
(5)数据文件大小：AOF文件比RDB文件大。
该项目的实际需求是：在系统出现宕机等故障时，需要在最短时间内通过重启等方式重新建立服务，因此重启性能是最重要的考虑因素，故该开发团队选择RDB方式。

【Q3】缓存中存储当前的热点数据，Redis为每个KEY值都设置了过期时间，以提高缓存命中率。为了清除非热点数据，Redis选择定期删除+惰性删除°策略。如果该策略失效，Redis内存使用率会越来越高，一般应采用内存淘汰机制来解决。请用100字以内的文字简要描述该策略的失效场景，并给出三种内存淘汰机制。

失效场景：如果“定期删除”没有删除KEY，也没有即时去请求KEY，也就是说“惰性删除”也没生效。这样，Redis默认的“定期删除+惰性删除”策略拒失效了。
对此，可以采用内存淘汰机制解决：
（1）从已设置过期时间的数据集最近最少使用的数据淘汰。
（2）从已设置过期时间的数据集将要过期的数据淘汰。
（3）从已设置过期时间的数据集任意选择数据淘汰。
（4）从数据集最近最少使用的数据淘汰。
（5）从数据集任意选择数据淘汰。
【Q3 延伸】
见： (关于redis)

19 分布式缓存系统

【Q1】 该系统使用过程中，由于同样的数据分别存在于数据库和缓存系统中，必然会造成数据同步或数据不一致性的问题。该企业团队为解决这个问题,提出了如下解决思路:
应用程序读数据时，首先读缓存，当该数据不在缓存时，再读取数据库;应用程序写数据时，先写缓存，成功后再写数据库;或者先写数据库,再写缓存。
王工认为该解决思路并未解决数据同步或数据不一致性的问题，请用100字以内的文字解释其原因。王工给出了一种可以解决该问题的数据读写步骤如下:
读数据操作的基本步骤:
1.根据key读缓存;
2.读取成功则直接返回;
3.若key不在缓存中时,根据key (a);
4.读取成功后, (b);
5.成功返回。
写数据操作的基本步骤:
1.根据key值写©;
2.成功后(d);
3.成功返回。
请填写完善上述步骤中(a) ~ (d)处的空白内容。

【A1】

数据同步或数据不一致的原因解释：
在原有方案中，应用程序写数据时,先写缓存,成功后再写数据库;或者先写数据库，再写缓存。这里存在双写不一致问题。不管先写缓存还是数据库，都会存在一方写成功，另一方写失败的问题，从而造成数据不一致。当多个请求发生时，也可能产生读写冲突的并发问题。

（a）~ (d)空白内容，

(a)从数据库中读取数据或读数据库
(b)更新缓存中key值或更新缓存
©数据库
(d)删除缓存key或使缓存key失效或更新缓存(key值)

（a）~ (d)空白内容 解释：

王工的解决思路是:读操作的顺序是，先读缓存，如果数据在缓存中，则直接返回，无须数据库操作;如果数据不在缓存,则读数据库,如成功，则更新缓存,如失败,则返回无此数据。
读操作主要解决查询效率问题。写操作的顺序是先写数据库，如失败，则返回失败;如成功，则更新缓存。更新缓存可能的方式有:如缓存中无此key值，则在缓存中不作处理;如缓存中存在此key值，则删除key值或使该key值失效。写操作的顺序主要防止数据库写操作失败，缓存更新为内存操作，失败的概率很小。同时删除key或使key失效，则在下一次查询该key值时，会发起数据库读操作，并同步更新缓存中的key值，从而最大程度上避免双写不—致问题。

【Q2】 缓存系统一般以key/value形式存储数据，在系统运维中发现，部分针对缓存的查询，未在缓存系统中找到对应的key，从而引发了大量对数据库服务器的查询请求，最严重时甚至导致了数据库服务器的宕机。
经过运维人员的深入分析,发现存在两种情况:
(1)）用户请求的key值在系统中不存在时，会查询数据库系统,加大了数据库服务器的压力;
(2）系统运行期间，发生了黑客攻击，以大量系统不存在的随机key发起了查询请求，从而导致了数据库服务器的宕机。经过研究，研发团队决定，当在数据库中也未查找到该key时，在缓存系统中为key设置空值，防止对数据库服务器发起重复查询。
请用100字以内文字说明该设置空值方案存在的问题,并给出解决思路。

存在问题:不在系统中的key值是无限的，如果均设置key值为空，会造成内存资源的极大浪费，引起性能急剧下降。
解决思路:查询缓存之前，对key值进行过滤，只允许系统中存在的key进行后续操作（例如采用key的bitmap进行过滤)。

【Q3】 缓存系统中的key一般会存在有效期，超过有效期则key失效;有时也会根据LRU算法将某些key移出内存。当应用软件查询key时，如key失效或不在内存，会重新读取数据库，并更新缓存中的key.
运维团队发现在某些情况下，若大量的key设置了相同的失效时间，导致缓存在同一时刻众多key同时失效，或者瞬间产生对缓存系统不存在key的大量访问，或者缓存系统重启等原因，都会造成数据库服务器请求瞬时爆星，引起大量缓存更新操作,导致整个系统性能急剧下降,进而造成整个系统崩溃。
请用100字以内文字，给出解决该问题的两种不同思路。

解决该问题的思路就是采取某种做法，使得缓存中同一时间不会出现大量的key值失效。具体的思路有:
1.缓存失效后，大量的缓存更新操作进行排队，通过加排它锁、队列等方式控制同时进行缓存更新操作的数量，使得缓存更新串行化,降低更新频率。此方式效果不佳,并没有从根源上解决大量缓存key值同时失效的问题。
2.在增加或更新缓存时,给不同key设置随机或不同的失效时间，使失效时间的分布尽星均匀，从根源上避免大量缓存key值同时失效。
3.设置两级或多级缓存，避免访问数据库服务器。此方式也没有从根源上解决大量缓存key值同时失效的问题。

18

【Q1】在李工和刘J工的方案中，均采用分布式数据库缓存技术来解决问题。请用100字以内的文字说明分布式数据库缓存的基本概念。
表4-1中对MemCache和Redis两种工具的优缺点进行了比较，请补充完善表4-1中的空(1)~(6).

分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。

MemCache和Redis两种工具的优缺点比较见： (关于redis)

【Q1 延伸】

MemCache与Redis主要的差异表现在以下方面:
1、Redis和MemCache都是将数据存放在内存中，都是内存数据库。他们都支持key-value数据类型。同时MemCache还可用于缓存其他东西，例种图片、视频等等，Redis还支持list、set,hash等数据结构的存储。2、Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。MemCache挂掉之后,数据就没了。
3、灾难恢复-MemCache挂掉后,数据不可恢复;Redis数据丢失后可以恢复。
4、在Redis中，并不是所有的数据都一直存储在内存中的。这是和MemCache相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。
5、Redis在很多方面支持数据库的特性,可以这样说他就是一个数据库系统，而MemCache只是简单地KNV缓存。所以在选择方面如果有持久方面的需求或对数据类型和处理有要求的应该选择Redis.
如果简单的key/value存储应该选择MemCache.

【Q2】 刘工认为李工的方案存在数据可靠性和一致性的问题，请用100字以内的文字解释说明。
为避免数据可靠性和一致性的问题，刘工的方案采用Redis作为数据库缓存，请用200字以内的文字说明基本的Redis与原有关系数据库的数据同步方案。

（1） MemCache没有持久化功能，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题。
（2） MemCache不支持事务，所以操作过程中可能产生数据的不一致性。

同步方案：
读数据时，先读Redis中的数据，如果Redis没有，则从原数据库中读取，并同步更新Redis中的数据。
写数据时，写入到原数据库中，并同步更新至Redis中，注意！！这里的更新至Redis操作包括：如缓存中无此key值，则在缓存中不作处理;如缓存中存在此key值，则删除key值或使该key值失效；
等待下次读数据时会将数据同步更新至Redis缓存，这样可以在最大程度上避免双写不—致问题。

【Q2 延伸】

本问题考查两种工具对数据可靠性和一致性的支持，并考查方案的设计能力。
MemCache无法进行持久化，数据不能备份，只能用于缓存使用，数据全部存在于内存，一旦重启数据会全部丢失。Redis支持数据的持久化。因此李工的方案存在数据可靠性和一致性问题，而刘工的方案解决了该问题。
刘工的方案中，采用Redis作为缓存，使得一份数据同时存储在缓存和关系数据库中，因此必须给出一个数据同步的方案。刘工的方案中，保留原有关系数据库，将Redis仅作为缓存,即热点数据缓存在Redis中，核心业务的结构化数据存储在原有关系数据库中，由于Redis只作为缓存，因此给出原关系数据库到Redis的同步方案即可。该方案的基本操作如下:
1.读操作，读缓存Redis，如果数据不存在，从原关系数据厍中读数据，并将读取后的数据值写入到Redis;2.写操作，写原关系数据库,写成功后，更新或者失效掉缓存Redis中的值。

【Q3】 请用300字以内的文字，说明Redis分布式存储的两种常见方案，并解释说明Redis集群切片的几种常见方式

Redis为单点方案,使用时必须提供分布式存储的集群拓展能力。Redis分布式存储的常见方案有主从(MasterlSlave)模式、哨兵(Sentinel)模式、集群(Cluster)模式。
Redis集群切片的常见方式有:
(1)客户端实现分片方式,分区逻辑在客户端实现，采用一致性哈希来决定Redis节点。
(2）中间件实现分片方式，即在应用软件和Redis中间，例如Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
(3)客户端服务端协作分片方式，Redis Cluster模式。客户端可采用一致性哈希，服务端提供错误节点的重定向服务。

17

【Q1】MVC架构中包含哪三种元素，它们的作用分别是什么?请根据图2-1所示架构将JavaEE中 JSP、Servlet、Service,JavaBean、DA0五种构件分别填入空(1)~(5)所示位置。

MVC架构包含：视图、控制器、模型。
视图（View）:视图是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，
但是它并不进行任何实际的业务处理。
控制器（Controller）：控制器接收用户的输入并调用模型和视图去完成用户的需求。该部分是用户界面与Model的接口。一方面他解释来自视图的输入，将其解释为系统能够理解的对象，
同时它也识别用户动作，并将其解释为对模型特定方法的调用；另一方面，它处理来自于模型的时间和模型逻辑执行的结果，调用适当的视图为用户提供反馈。
模型（Model）：模型是应用程序的主体部分。模型表示业务数据和业务逻辑。一个模型能为多个视图提供数据。

【Q2】 项目组架构师王工提出在图2-1所示架构设计中加入EJB构件，采用企业级JavaEE架构开发资源共享平台。请说明EJB构件中的Bean(构件)分为哪三种类型，每种类型Bean的职责是什么。

EJB中的Bean分为三种类型：Session Bean、 Entity Bean 和 Message-Driven Bean。

Session Bean 的职责是：维护一个短暂的会话。
Entity Bean的职责是：维护一行持久稳固的数据。
Message-Driven Bean的职责是：异步接收消息。

【Q3】如果采用王工提出的企业级JavaEE架构，请说明下列(a)-(e）所给出的业务功能构件中，有状态和无状态构件分别包括哪些。

【Q3延伸】
本题考查考生对Java EE架构中会话构件(Session Bean）的掌握情况。
会话构件负责维护客户端与服务端的交互状态，按照是否跨方法调用保存客户端与服务端的交互状态可以分为有状态(Stateful）会话构件和无状态(Stateless）会话构件，前者在交互过程中需要保存客户端与服务端交互的中间状态数据，一般在实现类中有自身的属性用于存储中间状态数据，无状态会话构件则不需要保存客户端与服务端的交互状态数据，客户端每次发起的请求相互独立，不会对服务端状态产生影响，因此服务端类不需要保存中间状态数据。身份认证构件完成初次身份认证后需要在服务端记录客户端的身份信息，在线编辑构件需要在操作过程中记录前一次编辑的操作结果，所以两者需要设计为有状态会话构件。资源发布、资源检索和统计分析构件对客户端多次请求均保持一致的处理过程和结果,所以应设计为无状态会话构件。

14

【Q1】 请用300字以内的文字解释什么是MVC架构风格以及其中的组件交互关系，并根据题干描述，指出该系统中的M.V、C分别对应什么。

MVC架构风格：用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
MVC架构将整个软件系统划分为模型、视图和控制器3个部分。
模型：负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化及时通知视图；
视图： 负责呈现模型中包含的业务数据，响应模型变化通知，更新呈现形式，并向控制器传递用户的界面动作；
控制器： 负责将用户的界面动作映射为模型中的业务处理功能并实际调用之，然后根据模型返回业务处理结构选择新的视图。

在本题中：
M： 监控组件 ，V：控制终端 ， C：管理模块

13 second

【Q1】 请用400字以内文字说明王工拟编制的项目计划中应包括哪些内容。

王工在接到任务后开始项目计划的编制工作，编制的计划应包括:
(1）项目总计划（包括范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、费用估算、进度计划及费用计)。
(2）项目辅助计划（质量计划、沟通计划、人力资源计划、风险计划、采购计划)。

13 fifth

【Q1】 在确定该支撑平台所采用的用户身份鉴别机制时，王工提出采用基于口令的简单认证机制，而李工则提出采用基于公钥体系的认证机制。项目组经过讨论，确定采用基于公钥体系的机制，请结合上述需求具体分析采用李工方案的原因。

(1)基于口令的认证方式实现简单，但由于口令复杂度及管理方面的原因，易受到认证攻击;而在基于公钥体系的认证方式中，由于其密钥机制的复杂性，同时在认证过程中私钥不在网络上传输，因此可以有效防止认证攻击，与基于口令的认证方式相比更为安全。
(2）按照需求描述，在完成用户身份鉴别后，需依据用户身份进一步对业务数据进行安全保护，且受保护数据中包含用户私有的终端机数据文件，在基于口令的认证方式中，用户口令为用户和认证服务器共享，没有用户独有的直接秘密信息，而在基于公钥的认证方式中，可基于用户私钥对私有数据进行加密保护，实现更加简便。
(3）基于公钥体系的认证方式协议和计算更加复杂，因此其计算复杂度要高于基于口令的认证方式，但业务环境的总用户数在100人以内，用户规模不大，运行环境又为局域网环境，因此基于公钥体系的认证方式可以满足平台效率要求。

【Q2】 针对需求(7)，项目组经过讨论，确定了基于数字信封的加密方式，其加密后的文件结构如图5-1所示。请结合需求说明对文件数据进行加密时，应采用对称加密的块加密方式还是流加密方式，为什么?并对该机制中的数据加密与解密过程进行描述。

应采用流加密方式。因为需求中提及"单个敏感数据文件可能会达到数百兆的规模"”，文件数据量较大，使用流加密方式可以获得更高的加解密效率。
数据加密与解密过程如下:
其加密过程为:首先生成一个对称密钥，使用用户公钥加密这个对称密钥后存储在文件头，然后用生成的对称密钥加密文件数据存储。其解密过程为∶用户首先使用自己的私钥解密被加密的对称密钥，再用该对称密钥解密出数据原文。

【Q3】 对数据库服务器中的敏感关系数据进行加密保护时，客户业务系统中的敏感关系数据主要是特定数据库表中的敏感字段值，客户要求对不同程度的敏感字段采用不同强度的密钥进行防护，且加密方式应尽可能减少安全管理与应用程序的负担。目前数据库管理系统提供的基本数据加密方式主要包括加解密API和透明加密两种，请用300字以内的文字对这两种方式进行解释，并结合需求说明应采用哪种加密方式。

目前数据库管理系统提供的基本数据加密支持主要有以下两种:
(1）加解密API:数据库管理系统提供可在SQL语句中调用的加解密API，应用可以利用这些API构建自己的基础架构，对数据进行加密保护。
(2）透明加密:安全管理员为数据库敏感字段选择加密方式及密钥强度，应用访问受保护数据时只需使用口令打开或关闭密钥表，对数据的加密和解密由数据库管理系统自动完成。
加解密API方式的灵活性强，但构建和管理复杂;而透明加密方式管理简单，应用程序负担轻，但灵活性较差。用户要求尽可能减少安全管理与应用程序的负担，因此应选择透明加密方式。

12 first

【Q1】分别解释产生问题（1) ~ (4）的原因。

其原因主要是:
(1)用户响应时间慢。大型社交网络系统要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强可以，但是应付上万次SQL写数据请求，硬盘I/O就已经无法承受了。特别是涉及到多表连接操作，会导致响应变慢。
(2）数据格式变化。大型社交网络系统随着用户的使用，会不断地增加新的功能，导致原有数据格式发生变化，甚至出现新的数据格式。但关系数据库中采用元组方式组织数据，难以使用新型数据格式，难以维护。
(3）数据容量超过设计上限。对于大型社交网络系统，往往会在很短时间内产生海量数据。关系数据库多采用中央数据存储，使得数据容量受限于前期设计的上限，很难实现数据容量的横向扩展。
(4)）系统可用性差:关系数据库采用中央数据存储，容易成为系统的性能瓶颈，单点故障很容易导致系统崩溃，负载过高往往导致系统出现宕机现象。

【Q2】 请针对问题(1)~(4)，分别指出NoSQL数据库的哪些特点促使公司最终采用了NoSQL数据库。
针对问题(1) , NoSQL数据库支持高并发数据访问，性能较高。
针对问题(2)，NoSQL数据库的数据存储结构松散，能够灵活支持多种类型的数据格式。
针对问题(3)，NOSQL数据库能够支持海量数据的存储，且易于横向扩展。
针对问题(4)，NoSQL数据库基于分布式数据存储，不存在单点故障和性能瓶颈，系统可用性高。

【Q3】 请指出该系统采用NoSQL数据库时可能存在的问题。

该系统采用NoSQL数据库时可能存在的问题有:
(1) NoSQL数据库的现有产品不够成熟，大多数产品处于初创期。
(2)NoSQL数据库并未形成—定的标准，产品种类繁多，缺乏官方支持。
(3) NoSQL数据库不提供对SQL的支持，学习和应用迁移成本较高。
(4)NoSQL数据库支持的特性不够丰富，现有产品提供的功能比较有限。

12 fourth

【Q2】 在技术选择架构规划时，王工认为系统应基于现有分布式基础设施（分布式中间件）来构建，因为这样可以充分利用现有基础设施提供的各种支撑，在更短时间内构造出质量更高的分布式系统;而李工则认为可基于基本的进程间通信机制自主开发系统的支撑平台，这样可以避免对特定中间件的依赖，项目组经过认真讨论，最终采用了王工的方案。请用400字以内文字，从构件管理支持、互操作支持以及公共服务支持三个方面说明现有分布式基础设施为构建分布式系统所提供的基本支撑。

(1）构件管理支持:现有分布式基础设施一般通过构件容器为构件提供基本的运行环境;具体功能一般包括管理构件的实例及其生命周期、管理构件的元信息等。
(2)）互操作支持:现有分布式基础设施均提供了高层通信协议以屏蔽节点的物理特性以及各节点在处理器、操作系统、程序设计语言等方面的异构性;基于互操作支持，开发人员在开发与调用分布式对象时，均不需自己编写处理底层通信的代码。
(3)公共服务支持:现有分布式基础设施通常将针对分布式软件的通用支持集成于一身，以公共服务的形式提供给应用程序;其提供的常见公共服务包括命名服务、事务服务、安全服务、持久性服务等。

【Q3】 由于系统后台模块的分布式特性，后台分布式对象之间的互操作机制是需要考虑的核心问题之一。图2-2所示是当前分布式基础设施中支持分布式对象互操作的基本机制，请将相应部件名称填入图中（1)～(2)﹔基于图2-2给出的结构，用300字以内文字说明完成—次分布式对象调用的详细步骤。

(1)存根/桩(2〉框架或
(1)代理(2)存根
—次远程调用的过程如下:
①客户程序将调用请求发送给客户端桩，对于客户程序来说，桩就是服务程序在客户端的代理。客户端桩负责将远程调用请求进行编组并发送给通信总线。
③调用请求经通信总线传送到服务端框架。
④服务端框架将调用请求解组并分派给真正的远程对象实现(服务程序)。⑤服务程序完成客户端的调用请求，将结果返回给服务端框架。
服务端框架将调用结果编组并发送给通信总线。
⑦调用结果经通信总线传送到客户端桩。
⑧客户端桩将调用结果解组并返回给客户程序，客户程序得到调用结果。