可伸缩性Scalable高性能系统设计

11-04-11 banq
                   

文章比较全面分析了系统可伸缩性scalable设计。

首先指出scalable和普通意义上性能提升有些不同,以至于更多人关注单台机器性能,而无视更高意义上性能扩充。

Scalable可伸缩性不等同于performance性能。可伸缩性是降低由于对性能,成本,可维护性等诸多方面要求的增长 带来的不利影响。

性能是指单用户访问时系统的快慢,当负载超出服务器可承受能力之外后急剧下降。

充分了解高负载环境:

用户数 交易量和数据量不断增长。

评价指标:响应时间,吞吐量Throughput,延迟性。

伸缩性方案:

Scale out 水平伸缩: 增加更便宜的机器

scale up 垂直伸缩: 升级到更强大的服务器(多CPU 昂贵大中型机)。

面向对象分割:

使你的代码切分为模块且简单。

Keep your code modular and simple

不要猜测瓶颈在哪里,用实验去发现。瓶颈是那些运行频繁但是每次运行很慢的代码,不要花时间优化那些很少执行的比较慢的代码。设立性能提升实验室,这样可以易于进行端到端的性能提升。

可伸缩性技术:

服务器农场:适合实时访问。

数据分区。

Map / Reduce :批量计算

CDN:静态页面缓存

Cache:动态缓存

资源池:数据库连接池 对象池

....

服务器农场:

如果有大量并发请求,可以在一个负载平衡器后加多台服务器。

应用程序本身必须要求是无态的,能被无条件的分发。

更有效的是使用云计算,这样应用程序有一个统一的API调用,服务器台数可以不断加入,应用程序丝毫无影响。

数据分区:

将数据切分到多个数据库中,分散访问。

因为数据是有状态的,必须有可靠机制保证某个服务器能够访问到上次访问的数据库。

降低数据之间的关系,使用分布式key/value 存储数据。

(banq附注:)

Http缓存:

通过Http头部控制,控制客户端浏览器缓存。

Http缓存Last-Modified、ETag和Expires的Java终结解决之道

使用Apache压缩mod_inflate传输http包。或Tomcat配置压缩

(banq附注结束)

异步机制

1.同步情况下:当你发出请求必然有一个响应结果,但是你可能接着还需要继续其他更多处理,不是立即用到这个响应结果。

2.这样,你不必发出请求后,就在那里傻等响应结果,而是继续做你其他更多处理,直到需要它时才过来取。

(banq注:)生活中排队,你去买两样东西,一样东西需要排队,那么先买不需排队的,再过来买。

不采取异步机制,可能造成高闲置系统,CPU负载不高,但是访问量提高不上去,对于一个高交互量的系统,线程闲置数= arrival_rate * processing_time)。如果arrival_rate很高,闲置数将非常高,系统工作在一个非常无效率的状态。等待线程闲置,会消耗系统资源。

使用异步处理模型asynchronous processing model来实现。

(1)Callback 回调

调用者当进行调用时,需要提供一个响应handler

被调用者在真正实际处理完成之前将立即首先返回结果。

当实际处理完成之后,响应将作为一个单独新的线程返回给之前已经注册了响应handler. 需要一些线程之间的协作和通讯。

(2)Polling模式

被调用者在被调用时,自己立即返回一个"future" handle.

调用者获得这个“future” Handle后,不从中获取结果,而是先忙别的事情,然后,从“future”中查看响应是否已经处理好。

无线程之间协作需要处理。使用JDK6.0 future处理。

(banq注)AJAX异步调用也属于该模式。

Jdon框架Domain Events也属于该模式,使得服务器端内部更有效率,在Jivejdon中再结合AJAX使用,浏览器和服务器之间又更有效率。

原文:

Scalable System Design | Architects Zone

[该贴被banq于2011-04-11 14:38修改过]

[该贴被banq于2011-04-11 14:39修改过]

[该贴被admin于2011-04-19 10:02修改过]

                   

6
banq
2011-04-14 15:30

相关主题:

Twitter 从Ruby的Rails移植到Java