1、服务器系统架构解析这个架构基于 squid、nginx 和 lvs 等技术，从架构上对平台进行全面优化和保护，有如下特点：1、高性能：所有的点击基本上全部由前端缓存负责，提供最快速的处理。2、高保障度：不需考虑应用程序稳定与否、程序语言是何种、数据库是何种，都能从架构上保证稳定。3、高可用性：对应用程序的修改达到最简化：在程序的某些地方加入清缓存的语句即可，当然还需要做页面静态化的工作和统计工作。首先看图，这个图比较大：这个架构的特点和一些流程的说明：1、主域名和图片域名分离域名分离可以使流量分离，缓存策略分离等等，好处诸多。平台初期一定要做好规划，将图片用另外的域名独立服务，即使没有足够机器
2、，域名也要先分开。另外，图片服务器可以使用有别于主域名的另一个域名，一个好处是可以减少读取 cookie 对图片服务器的压力，另一个是提高安全性，避免 cookie 泄露。2、使用 LVS 作为前端、二级代理和数据库的访问入口使用 LVS 作为入口，比其他任何一种方式都来得更优质。首先 LVS 的负载能力很强，因为它工作在网络协议的第 4 层，使用虚拟 ip 技术，所以它本身并不担负任何流量的处理，仅仅是一个封包转发的功能；第二，LVS 的配置相对简单而且稳定，一般去调整的几率比较低，也减少了因人为等因素而出现故障；第三，LVS 可以处理任何端口的负载均衡，所以它基本可以做所有服务的负载均衡和
3、容错。在这个架构中，除了处理 http 的 80 端口之外，LVS 也处理了数据库 mysql 的 3306 端口，在数据库这个应用中是采用的双机热备策略。3、使用 nginx+squid 作为最前端的缓存组合在这个架构中，是最能体现 app_nginx_squid_nginx 架构的优势的。在这个架构中的平台运行在缓存上，用户每发布一张帖子，都需要使用 purge 指令清除该帖子的缓存，如果是squid 在最前端，那么每次发布一张帖子，都需要在所有的 squid 中调用 purge 指令，这样在机器比较多的时候，purge 将成为一个巨大的压力。所以在这里将 nginx 放在最前端并使用手工
4、 url_hash 的方式分流，将经常需要 purge 的帖子页面和列表页面按一个 url 对应一台 squid 的策略，分布到各台 squid 上，并提供了一台或一组 backup 的 squid，个别 squid 出现异常时将自动使用 backup 的机器继续提供一段时间的服务直到其正常。在这样的架构下，purge 就不再是关键问题，因为一个 url 只会对应到一台机器上，所以 purge 的时候，后端 app_server 找到对应的机器就可以了。可以看到在前端中还有一台 nginx(purge)的机器，这台机器是专用于 purge 的，只要发送purge 指令和需要清除的 url 到这
5、台机器，就可以找到相应的服务器并清除缓存了。另外，purge 时还需要清理 backup 机器上的缓存，所以无论前端机器增加到多少，purge 指令只会在 2 台机器上执行，如果 backup 机器使用到 2-3 台，purge 指令就会在 3-4 台机器上执行，仍然在可接受范围之内。nginx 作为前端，另有的好处：1/使用 nginx 的日志统计点击量非常方便2/nginx 也可作为缓存，一般可以直接负责 favicon.ico 和 logo 等固定的小图片4、基于 nginx 的中层代理nginx 中层代理的优势，在：这个架构和 app_squid 架构的区别，也是关键点就是：加入了一级
6、中层代理，中层代理的好处实在太多了：1、 gzip 压缩压缩可以通过 nginx 做，这样，后台应用服务器不管是 apache、resin、lighttpd 甚至 iis 或其他古怪服务器，都不用考虑压缩的功能问题。2、负载均衡和故障屏蔽nginx 可以作为负载均衡代理使用，并有故障屏蔽功能，这样，根据目录甚至一个正则表达式来制定负载均衡策略变成了小 case。3、方便的运维管理，在各种情况下可以灵活制订方案。例如，如果有人用轻量级的 ddos 穿透 squid 进行攻击，可以在中层代理想办法处理掉；访问量和后台负载突变时，可以随时把一个域名或一个目录的请求扔入二级 cache 服务器；可以很
7、容易地控制 no-cache 和 expires 等 header。等等功能。 。 。4、权限清晰这台机器就是不写程序的维护人员负责，程序员一般不需要管理这台机器，这样假如出现故障，很容易能找到正确的人。对于应用服务器和数据库服务器，最好是从维护人员的视线中消失，我的目标是，这些服务只要能跑得起来就可以了，其它的事情全部可以在外部处理掉。-在这个架构中，假如后端的 app_server 上把帖子页和列表页直接生成了静态页面，那么使用中层代理再做一次 url_hash，将可以解决后端 app_server 的硬盘容量的压力，但是如果使用到 url_hash 的话，那做容错就相对麻烦了。所以建议不
8、要采用生成静态页的方式，后端的压力一般不会非常的大，所以没有必要生成静态页。假如前端 squid 的命中率实在太低下，造成大量穿透，可以考虑使用二级代理暂顶。5、基于 LVS 的数据库双机热备在这个架构中，因为大量的并发和访问量都由前端的缓存处理掉了，所以后端的 mysql 主要压力来自于数据的写入，所以压力并不是非常大，并且负载比较稳定，一般不会随着访问量上升而提高过快，估计目前一台 64 位的机器，加满内存并使用高速的硬盘，前端负载数亿访问量时数据库都不会出现性能问题。在数据库这方面应主要考虑故障恢复，因为数据库崩溃的话，按照一般使用备份恢复的做法，耗时很长而且难免丢失数据，是很棘手的问题
9、。使用双机热备的方案，出现故障时首先可由一台时刻同步着的备用数据库即刻充当主数据库，然后卸下的数据库可以有充分的时间对其进行维修，所以是个很安全有效的办法。当然，数据库的优化还是要细心做6、图片服务器图片服务器我在这个架构中没有特别详细的介绍，在大型的平台系统下，图片常常会出现容灾现象 图片数量严重超过了单台前端服务器容纳能力，导致前端服务器命中率低下。处理容灾问题也是非常棘手的，往后会有更详细的介绍。7、简单的点击量统计办法1/使用 js 的 script 标签访问另一（台）组服务器的空文件，然后定期向数据库更新2/在前端的 nginx 上直接开启日志功能，按需要统计点击量的链接规则进行记录，然后定期更新数据库
