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

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

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

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

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

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

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

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

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

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

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

三、使用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等固定的小图片

四、基于nginx的中层代理

nginx中层代理的优点，在：

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

这篇文章中有解释。

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

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

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

固然，数据库的优化仍是要细心作的，参考：

mysql性能的检查和调优方法

细心地调一遍，性能会好不少。

六、图片服务器

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

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

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

FROM:http://sudone.com/archie/archi_bbs.html