新型的大型bbs架构(squid+ngi

图片服务器我在那个架构中没有希奇详细的引睹，在大型的bbs系统下，图片常常会泛起容灾现象——图片数目严重超过了单台前端服务器包容能力，导致前端服务器命中率低下。处理容灾问题也是非常棘手的，往后会有更详细的引睹。

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

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

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

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

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

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

首先看图，那个图对照大：

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

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

mysql性能的检查和调优圆法

在那个架构中，是最能体现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等固定的小图片

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

nginx中层代理的优势，在：

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

那篇文章中有解释。

4、基于nginx的中层代理

6、图片服务器

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

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

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

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

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

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

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

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

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

新型的大型bbs架构(squid+ngi相关推荐

新型的大型bbs架构（squid+nginx
2019独角兽企业重金招聘Python工程师标准>>> 这个架构基于squid.nginx和lvs等技术,从架构上对bbs进行全面优化和保护,有如下特点: 1.高性能:所有的点击基本 ...
大型网站架构图片服务器分离
转自http://www.cnblogs.com/hukailee/p/5285018.html 大型网站架构图片服务器分离 1 介绍现在很多的网站上都会用到大量的图片,而图片是网页传输中 ...
大型网站架构演变和知识体系
存爱好,作为收藏,原地址:http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html ,同时向原创致敬之前也有一些介绍大型网站架构 ...
千万级流量的大型分布式系统架构设计
本文是学习大型分布式网站架构的技术总结.对架构一个高性能.高可用.可伸缩及可扩展的分布式网站进行了概要性描述,并给出一个架构参考.文中一部分为读书笔记,一部分是个人经验总结,对大型分布式网站架构有较好 ...
照抄不翻车：抗住千万流量的大型分布式系统架构设计
作者介绍烂猪皮,十余年工作经验,曾在 Google 等外企工作过几年,精通 Java.分布式架构.微服务架构以及数据库,最近正在研究大数据以及区块链,希望能突破到更高的境界. 本文是学习大型分布式网 ...
大型网站架构演变和知识体系--转
之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的.ebay的,都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不 ...
大型网站 linux,大型网站架构演变
之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的.ebay的,都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不 ...
一步步构建大型网站架构(转)
一步步构建大型网站架构(转) http://www.itivy.com/ivy/archive/2011/11/24/something-that-architecture-must-be-aware ...
BAT架构师进阶：大型网站架构书籍推荐
" 书籍推荐分为如下: 大型网站架构系列分布式系统系列 BAT技术系列架构设计系列一:大型网站架构系列第一本:<大型网站技术架构:核心原理与案例分析> 这本书主要从大型网 ...

新型的大型bbs架构(squid+ngi

新型的大型bbs架构(squid+ngi相关推荐

最新文章

热门文章