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

文章比较全面分析了系统可伸缩性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修改过]