转自 http://www.sudone.com/archie/archi_bbs.html
新型的大型bbs架构(squid+nginx)
[2009-08-24 21:33:31]
这个架构基于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上直接开启日志功能,按需要统计点击量的链接规则进行记录,然后定期更新数据库
1、高性能:所有的点击基本上全部由前端缓存负责,提供最快速的处理。
2、高保障度:不需考虑应用程序稳定与否、程序语言是何种、数据库是何种,都能从架构上保证稳定。
3、高可用性:对应用程序的修改达到最简化:在程序的某些地方加入清缓存的语句即可,当然还需要做页面静态化的工作和统计工作。
首先看图,这个图比较大:
![](http://www.sudone.com/images/archi_bbs.png)
这个架构的特点和一些流程的说明:
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上直接开启日志功能,按需要统计点击量的链接规则进行记录,然后定期更新数据库