首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件架构设计 >

一切对象都是资源,请用形式管理(I)

2012-10-29 
一切对象都是资源,请用模式管理(I)??? 作者:江南白衣,原文地址:http://blog.csdn.net/calvinxiu/archive/2

一切对象都是资源,请用模式管理(I)

??? 作者:江南白衣,原文地址:http://blog.csdn.net/calvinxiu/archive/2007/05/25/1625454.aspx,版权所有,转载请保留原文链接。

??? 写下标题,就想起冬冬那句"人生像个舞台,请良家妇女离开"??,什么时候开始,已写不出那样的文字。?

??? 在程序世界,内存,文件,网络连接,数据库会话,线程甚至一切的对象,都是资源。《Pattern-Oriented Software Architecture V3 --Patterns for Resource Management 》(POSA第三卷),讲的就是资源管理,外表轻薄(145页)而内里熟悉,很好读。

一切对象都是资源,请用形式管理(I)

?? 什么资源需要管理?

数量有限,有引起竞争的资源 获取的代价昂贵的资源

?

?? 全书把10个模式分成生命期分成三个部分:资源获取,资源生命周期,资源释放。

一、资源获取

资源获取,一是LookUp模式,二是Lazy/Eager/Partial 三种获取模式。

1.Lookup

??? 大家熟悉的Corba的Naming Service,J2EE的JNDI,COM+的注册表,WebService的UDDI,还有最有现实感的DNS,所有这些,都是通过中介实例来发现和访问资源,屏蔽资源的物理位置(还可以进一步屏蔽资源的负载均衡和故障转移)。

?????? 几个值得笔记的地方:

获得LookUp服务的实例:在查找资源实例前,先要获得Lookup服务的实例。使用预配置文件或使用广播/多播的自举发现协议。 设计查询语言:支持复杂的查询。 单点故障:如果查找服务崩溃就引起整个系统崩溃,需要群集机制。 悬挂引用:资源已失效,注册的引用变得过时,需要资源注销机制,如leasing模式。 Federate Lookup:多个LookUp实例联合提供查询服务,如多级DNS,Half-Object Plus Protocol模式。 Replicated Lookup:在Lookup实例处就可以实现负载均衡,如Borland的Corba实现Visibroker。

2.Lazy Acquisition:

??? Hibernate的Lazy Load已经深入人心,一种朴素的JIT思路。

???? ?? 几个值得笔记的地方:

透明性:使用资源代理使LazyLoad对使用者透明。 支持关闭“Lazy Load机制”的开关。 可能增加额外的时间开销,比如在lazy load时其实多了一次数据库往返。 执行时间的不可预测,这是最要命的,在实时性要求很高的系统里,忽然要去跑一下数据库的话.....

3.Eager Acquisition:

??? 财大气粗,内存多多的服务器,喜欢在启动时就将数据先装进内存里,使得运行时性能(Performance)与可预测(Predictability)兼得,不会忽然来一个时间不可控的数据库查询。

减慢系统启动速度,像我家的旧服务器启动要40分钟,正在改进。 对某类资源可改为运行时检测未来的使用量抢先获得。
好处是减低了启动时间,更贴切资源的使用量,但多了监控系统的开销。 过度获取资源,且对其他资源使用者不公平。 支持动态配置预获取资源的数量。

4.Partial Acquisition:

??? 中庸从来都是解决实际问题的不错方式,既然上面两种方式互有长短,那我们可以把资源获取分成多个阶段。
??? 比如邮件系统的认证模块,就会eager load这两个月里有登陆邮箱的活动用户,而lazy load其他long time no see的用户。
??? 又如浏览器里渐进的图像加载,或者数据驱动的网路协议中先解包数据包头,再逐步获取数据包体等等。

思考顺序:决定分哪些步骤,每个步骤的策略(lazy,eager),每个步骤获取多少资源(固定尺寸,或以时间等为标准自适应策略) 实现获取触发器,建立负责执行资源获取的每一步的机制,如Reactor[POSA2]之类的模式。

?

剩下还有6个模式,下篇继续。



?

热点排行