web 网站优化分析

这里的web系统优化是指网站系统优化，之前一直认为网站系统的优化方面能做的应该是很少的，因为在我过去的认知里，网站是运行在服务器软件（常见的Tomcat）上，服务器软件完成了用户请求的获取，并交给自己的网站，再由网站处理，整体流程就是这样，当时认为若要优化的话应该从请求的转发过程处理（如果转发快了，系统自然就快了），但是这部分已经被服务器软件处理了，作为一般的程序员根本就处理不了请求转发的过程。但是由于时间的积累，发觉自己之前的优化点找错了，原因是：请求转发过程的确要优化，但是这个不是网站开发者做的，而是服务器软件开发者（以Tomcat为例，请求转发的优化应该由Tomcat 维护者处理）。而作为网站开发者要优化的地方应该是自己网站内部的实现，针对网站的运营要求（是否会存在高并发（同一时刻有大规模的用户访问网站）的情景）。

同一时刻大规模用户访问网站具体可分为以下几个场景：

1.   只是访问某个静态（不操作数据库的）页面（这种情况网站开发者是不需要优化的，因为这个仅涉及请求的转发和结果的返回，是服务器维护者该优化的，网站开发者是无法处理的，一般默认现有服务器的请求转发和结果返回的优化已经处理了的）。

2.   访问某个动态（有数据库操作）页面（这种情况就得对数据库操作进行优化了，优化分为两个层次，一。常规优化（避免内存泄漏，内存溢出，多线程数据安全问题）；二。在处理完常规优化的基础上，提高数据库访问速度（主要是使用内存级别的访问方式，但是这样的话又得做好别的防护，主要是和线程安全相关）。）

特别说一下多线程数据安全问题，要保证多线程安全就必须保证线程的有序性。关于更多的线程安全问题，笔者转了一篇博客相当到位的介绍了线程安全，点击可看。

当然前面的仅仅是常规网站开发方面，但是某些特殊情况下得使用特殊方法开发，举个例子可能有一个网站面向的是全球用户，而且用户会从网站上下载某些文件，这种情况下如果使用常规开发，由于不同的国家地区访问当地服务器是有快有慢的，这样下载速度就没法保证，解决这种问题的话就得使用分布式的方法存储了，一开始请求核心服务器，到下载文件时就下载距离用户较近的服务器上的文件这样子就可以保证下载速度了，但这样的话成本控制就得好好考虑了，但是如果使用常规方法，就得增加带宽，提升性能，可能可以提示效果，但是效果可能不明显。如果使用分布式的存储方式的话，就得处理好数据备份、同步更新及数据恢复问题了。数据备份是指将核心服务器上的数据库备份到非核心服务器上，同步更新是指当核心服务器上数据变了，备份服务器的也要变。数据恢复是指由于某些突发原因导致数据失效，就得从好的服务器上恢复过来。要特别留意的是这些操作发生的时机和控制这些操作发生规模，否则会导致系统瘫痪的，下面以数据恢复为例子，分析一下可能会出现的情况。

数据恢复在分布式存储系统里叫副本修复，如果在一段较短时间内发生大规模的副本恢复，这时候就可能导致系统瘫痪，这叫雪崩效应，雪崩效应的应对方法有两种，一种是特定时间内发生大雪崩，就是将副本恢复操作集中在一个时间段执行，这段时间就提前说明在系统维护，网站不能访问。这样就可以做到在雪崩来之前疏散人群，减少损失。这样的好处是简单粗暴，但是用户体验很差。另外一个做法就是严格控制副本恢复的规模，使之形不成雪崩，这样必须知道雪崩形成条件，但是这个条件是随当前网站的访问量变化的当访问量多时雪崩条件就低，反之访问量少时，条件就高，所以这个条件有两种方式设定，一种是静态设定（这种编程复杂度较低，但是不够灵活，不能完全避免雪崩），另一种是动态设定（这种可以完全避免雪崩，但是难度稍复杂）。

最后，总结一下，关于网站优化，一个是常规网站优化（分为常规优化（内存泄漏）和高并发优化（多线程安全，提升速度（数据库访问优化）））。另一种是非常规网站优化，在处理了常规网站优化后，可能还要涉及分布式存储的问题。网站一旦涉及高并发，就一定会涉及多线程安全问题，所以笔者还是强烈推荐自己转的一篇文章，点击这里，你会有所得的。