1、NoSQL
一个基于Web 2.0的大型社交网络系统。就该系统的数据架构而言，李工决定采用公司熟悉的数据架构，使用通用的商用关系型数据库，系统内部数据采用中央集中方式存储。该系统投入使用后，初期用户数量少，系统运行平稳。6个月后，用户数出现了爆炸式增长，系统暴露出诸多问题，集中表现在：
1.用户执行读写操作时，响应时间均变得很慢；
2.随着系统功能的扩充，原有数据格式发生变化，又出现新的数据格式，维护困难；
3.数据容量很快超过系统原有的设计上限，数据库扩容困难；
4.软件系统不断出现宕机，整个系统可用性较差。
经过多次会议讨论，公司的王工建议采用NoSQL数据库来替代关系数据库，以解决上述问题。但李工指出NoSQL数据库出现时间不长，在使用上可能存在风险。公司技术人员对NoSQL数据库产品进行了认真测试，最终决定采用NoSQL数据库来替代现有的数据库系统。
【问题1】
分别解释产生问题(1)～(4)的原因。
(1)用户响应时间慢。大型社交网络系统要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强可以，但是应付上万次SQL写数据请求，硬盘I/O就已经无法承受了。特别是涉及到多表连接操作，会导致响应变慢。
(2)数据格式变化。大型社交网络系统随着用户的使用，会不断地增加新的功能，导致原有数据格式发生变化，甚至出现新的数据格式。但关系数据库中采用元组方式组织数据，难以使用新型数据格式，难以维护。
(3)数据容量超过设计上限。对于大型社交网络系统，往往会在很短时间内产生海量数据。关系数据库多采用中央数据存储，使得数据容量受限于前期设计的上限，很难实现数据容量的横向扩展。
(4)系统可用性差：关系数据库采用中央数据存储，容易成为系统的性能瓶颈，单点故障很容易导致系统崩溃，负载过高往往导致系统出现宕机现象。
【问题2】
请针对问题(1)～(4)，分别指出NoSQL数据库的哪些特点促使公司最终采用了NoSQL数据库。
针对问题(1)，NoSQL数据库支持高并发数据访问，性能较高。
针对问题(2)，NoSQL数据库的数据存储结构松散，能够灵活支持多种类型的数据格式。
针对问题(3)，NoSQL数据库能够支持海量数据的存储，且易于横向扩展。
针对问题(4)，NoSQL数据库基于分布式数据存储，不存在单点故障和性能瓶颈，系统可用性高。
【问题3】
请指出该系统采用NoSQL数据库时可能存在的问题。
(1)NoSQL数据库的现有产品不够成熟，大多数产品处于初创期。
(2)NoSQL数据库并未形成一定的标准，产品种类繁多，缺乏官方支持。
(3)NoSQL数据库不提供对SQL的支持，学习和应用迁移成本较高。
(4)NoSQL数据库支持的特性不够丰富，现有产品提供的功能比较有限。
2、分布式对象调用
分布式基础设施为构建分布式系统所提供的基本支撑：
(1)构件管理支持：现有分布式基础设施一般通过构件容器为构件提供基本的运行环境；具体功能一般包括管理构件的实例及其生命周期、管理构件的元信息等。
(2)互操作支持：现有分布式基础设施均提供了高层通信协议以屏蔽节点的物理特性以及各节点在处理器、操作系统、程序设计语言等方面的异构性；基于互操作支持，开发人员在开发与调用分布式对象时，均不需自己编写处理底层通信的代码。
(3)公共服务支持：现有分布式基础设施通常将针对分布式软件的通用支持集成于一身，以公共服务的形式提供给应用程序；其提供的常见公共服务包括命名服务、事务服务、安全服务、持久性 服务等。
- 客户端（client）以本地调用方式（即以接口的方式）调用服务；
- 客户端存根/桩（client stub）接收到调用后，负责将方法、参数等组装成能够进行网络传输的消息体（将消息体对象序列化为二进制 byte[]）；
- 客户端通过sockets将消息发送到服务端；
- 服务端存根/框架( server stub）收到消息后进行解码（将消息对象反序列化）；
- 服务端存根( server stub）根据解码结果调用本地的服务；
- 本地服务执行并将结果返回给服务端存根( server stub）；
- 服务端存根( server stub）将返回结果打包成消息（将结果消息对象序列化）；
- 服务端（server）通过sockets将消息发送到客户端；
- 客户端存根（client stub）接收到结果消息，并进行解码（将结果消息反序列化）；
- 客户端（client）得到最终结果。
RPC的目标是要把2、3、4、7、8、9这些步骤都封装起来。