新型的大型bbs架构（squid+nginx）

这个架构基于squid、nginx和lvs等技术，从架构上对bbs进行全面优化和保护，有如下特点：

1、高性能：所有的点击基本上全部由前端缓存负责，提供最快速的处理。

2、高保障度：不需考虑应用程序稳定与否、程序语言是何种、数据库是何种，都能从架构上保证稳定。

3、高可用性：对应用程序的修改达到最简化：在程序的某些地方加入清缓存的语句即可，当然还需要做页面静态化的工作和统计工作。

首先看图，这个图比较大：



这个架构的特点和一些流程的说明：

1、主域名和图片域名分离

域名分离可以使流量分离，缓存策略分离等等，好处诸多。bbs初期一定要做好规划，将图片用另外的域名独立服务，即使没有足够机器，域名也要先分开。另 外，图片服务器可以使用有别于主域名的另一个域名，一个好处是可以减少读取cookie对图片服务器的压力，另一个是提高安全性，避免cookie泄露。

2、使用LVS作为前端、二级代理和数据库的访问入口

使用LVS作为入口，比其他任何一种方式都来得更优质。首先LVS的负载能力很强，因为它工作在网络协议的第4层，使用虚拟ip技术，所以它本身并不担负 任何流量的处理，仅仅是一个封包转发的功能；第二，LVS的配置相对简单而且稳定，一般去调整的几率比较低，也减少了因人为等因素而出现故障；第 三，LVS可以处理任何端口的负载均衡，所以它基本可以做所有服务的负载均衡和容错。在这个架构中，除了处理http的80端口之外，LVS也处理了数据 库mysql的3306端口，在数据库这个应用中是采用的双机热备策略。

3、使用nginx+squid作为最前端的缓存组合

在这个架构中，是最能体现app_nginx_squid_nginx架构的优势的。在这个架构中的bbs运行在缓存上，用户每发布一张帖子，都需要使用 purge指令清除该帖子的缓存，如果是squid在最前端，那么每次发布一张帖子，都需要在所有的squid中调用purge指令，这样在机器比较多的 时候，purge将成为一个巨大的压力。

所以在这里将nginx放在最前端并使用手工url_hash的方式分流，将经常需要purge的帖子页面和列表页面按一个url对应一台squid的策 略，分布到各台squid上，并提供了一台或一组backup的squid，个别squid出现异常时将自动使用backup的机器继续提供一段时间的服 务直到其正常。在这样的架构下，purge就不再是关键问题，因为一个url只会对应到一台机器上，所以purge的时候，后端app_server找到 对应的机器就可以了。

可以看到在前端中还有一台nginx(purge)的机器，这台机器是专用于purge的，只要发送purge指令和需要清除的url到这台机器，就可以 找到相应的服务器并清除缓存了。另外，purge时还需要清理backup机器上的缓存，所以无论前端机器增加到多少，purge指令只会在2台机器上执 行，如果backup机器使用到2-3台，purge指令就会在3-4台机器上执行，仍然在可接受范围之内。

nginx作为前端，另有的好处：

1/使用nginx的日志统计点击量非常方便
2/nginx也可作为缓存，一般可以直接负责favicon.ico和logo等固定的小图片

4、基于nginx的中层代理

nginx中层代理的优势，在：

nginx和squid配合搭建的web服务器前端系统

这篇文章中有解释。

在这个架构中，假如后端的app_server上把帖子页和列表页直接生成了静态页面，那么使用中层代理再做一次url_hash，将可以解决后端 app_server的硬盘容量的压力，但是如果使用到url_hash的话，那做容错就相对麻烦了。所以建议不要采用生成静态页的方式，后端的压力一般 不会非常的大，所以没有必要生成静态页。假如前端squid的命中率实在太低下，造成大量穿透，可以考虑使用二级代理暂顶。

5、基于LVS的数据库双机热备

在这个架构中，因为大量的并发和访问量都由前端的缓存处理掉了，所以后端的mysql主要压力来自于数据的写入，所以压力并不是非常大，并且负载比较稳 定，一般不会随着访问量上升而提高过快，估计目前一台64位的机器，加满内存并使用高速的硬盘，前端负载数亿访问量时数据库都不会出现性能问题。在数据库 这方面应主要考虑故障恢复，因为数据库崩溃的话，按照一般使用备份恢复的做法，耗时很长而且难免丢失数据，是很棘手的问题。使用双机热备的方案，出现故障 时首先可由一台时刻同步着的备用数据库即刻充当主数据库，然后卸下的数据库可以有充分的时间对其进行维修，所以是个很安全有效的办法。

当然，数据库的优化还是要细心做的，参考：

mysql性能的检查和调优方法

细心地调一遍，性能会好很多。

6、图片服务器

图片服务器我在这个架构中没有特别详细的介绍，在大型的bbs系统下，图片常常会出现容灾现象——图片数量严重超过了单台前端服务器容纳能力，导致前端服务器命中率低下。处理容灾问题也是非常棘手的，往后会有更详细的介绍。

7、简单的点击量统计办法

1/使用js的script标签访问另一（台）组服务器的空文件，然后定期向数据库更新
2/在前端的nginx上直接开启日志功能，按需要统计点击量的链接规则进行记录，然后定期更新数据库