大型网站架构的灵魂—性能.docxVIP

大型网站架构的灵魂—功能 假如缓存数据较少，可以利用OSCache实现本地缓存： 当缓存数据过多时，利用Memcached实现分布式缓存： Memcached实现分布式缓存，缓存服务器之间是互不通信的，也就是我们可以便利的通过添加Memcached服务器对系统进行扩展。 3.2 异步操作 使用同步恳求的方式，在高并发的情况下，会对数据库形成很大的压力，也会让用户感觉响应时间过长。异步恳求方式，则可以快速的对用户做出响应，而具体的数据库操作恳求，则通过消息队列服务器发送给数据库服务器，做具体的插入操作。插入操作的结果则已其他方式通知客户端。例如一般在订票系统当中，出票行为就是异步完成，最终的出票结果会以邮件或其他方式告知用户。 3.3 代码优化 这里就不在具体描述。 3.4 存储优化 大型网站中海量的数据读写对磁盘形成很大压力，系统最大的瓶颈还是在磁盘的读写。可以考虑使用磁盘阵列、分布式储存来改善存储的功能。 4 功能的目标和测试 上面通过解析用户访问网站的过程来思考怎样提高用户感知的功能，对于用户来言功能就是快和慢。但对于我们来说，不能这样简约描述，我们需要去量化他，用一些数据目标去衡量它。这里讲到几个名词：响应时间、并发量、吞吐量。 响应时间：就是用户发出恳求到收到响应数据的时间； 并发量：就是系统同时能处理多少用户恳求； 吞吐量：就是单位时间内系统处理的恳求数量； 对于功能测试来说，基本也是围绕这些方面来测试，下图说明白功能测试的过程： 左图表示响应时间和并发用户量的二维坐标图，从图上可以看出，并发用户量在肯定量添加时，响应时间很短，并且没有太大的崎岖，这表示系统目前处于日 常运转期，可以很快处理用户恳求（A点之前）；随着并发量的添加，系统处于恳求高峰期，但仍旧可以有序的处理用户恳求，响应时间较日常有所添加（A、B之 间）；当并发量添加到肯定数量时，超过了系统的负载力量，系统处于濒临崩溃的边缘（B、C之间），响应时间严峻过长，直到系统崩溃。 右图表示吞吐量与并发用户量的二维坐标图，可以看出，随着并发用户量的添加，吞吐量渐渐添加；在并发量到达肯定量时，由于系统处理力量达到最大，吞吐量添加放缓；当并发量超过系统负载时（E点），系统处理力量开头下降，不能再恳求添加的用户恳求，吞吐量反而降低。 Java后端架构，关注猎取更多技术共享 欢迎加入 联系QQ：517894513 QQ群号码：217023887