采用什么架构才能够承受庞大的访问量?

迷彩 11天前 ⋅ 39 阅读

采用什么架构才能够承受庞大的访问量?

采用什么架构才能够承受庞大的访问量 -01.png

一般情况下,架构分两种来讨论的,一种是开发架构,一种是部署架构

部署架构,就是开发完的程序在实际运行环境下,通过负载均衡,DNS轮询,SquID等

等来减轻单台服务器负载,达到性能优化的目的,这里大家估计更想了解的是开发上的架构。

我对这个的观点是,所有的架构都是死的,而性能优化策略是活的,我在开发中,所有的东西

都不是一定要按照什么固定的模式,去死开发,更多的是针对需要优化的信息进行针对处理,

下面说说我的优化策略。

1、数据库优化

这个是所有的优化策略中最重要的,可以说数据库设计的好坏,直接影响

了一个系统的承受力。普通的数据库细节优化,网上已经有大笔文章了,没什么好说的,想了解的

自己去找。而我要说的就是在数据库设计中的一个思路,分库、分表、缓存表。

  • 1.1、分库 指的是在设计中,要考虑到后期数据量大的情况下,你的数据库能够随着应用随时拆

分,这个拆分并不是只是针对功能模块对应的数据拆分。举个例子,就拿CSDN论坛吧,比如里面有

很多类,C#版,JAVA版,系统设计版等等,拆分的目的是可以把任何一个版的数据拆分到单独的一

个数据库中去。

  • 1.2、分表 相对的就好理解了,就是说同类型的数据,你可以为了性能优化,进行拆分到多个

表中去,拆分规则可以有多种,按照类型、按照时间、按照姓名等等。同样以CSDN论坛来说,我

要设计的话,我会按照里面的大版面进行数据库拆分,而按照小版,进行表拆分。

  • 1.3、而对于缓存表,网上我还很少看到有人来说这个东西,这个的目的就是针对一个大的数

据表中,一般表中有死数据和活动数据,比如用户表,里面有很多基本不来的用户,那么针对这

样的情况,当表数据上了千万的时候,我就会采用缓存表的模式来进行了,就是在实际表和用户

之间在搭建一个临时表,访问用户数据时,首先访问临时表,如果不存在,则进入实际表中获取

,然后放入缓存表中,同时会通过后台线程,定时将缓存表数据同步到实际数据库中,同步时间

可以针对系统要求来进行。

如果理解了上面的东西,那么在数据承载上,可以上升一个很大的层次。

2、程序优化

这个对我来说相对的就不是那么的看中了,程序的优化,我更多的认为是个技巧,而不是架构了

,包括现在经常见到的那些各种设计模式,另外这里提下,很多设计模式,他的出发点并不是性

能优化,而是考虑的系统扩展性,所以在单个技术细节上,很多人也发现了,并不如直接的写代

码来的快,但是就是推荐那样,是因为采用了那些模式的程序,扩展性比你的强,那么一旦系统

需求变动,或者是要求进行拆分的时候要比你方便的多,在分担到多个服务器上时,性能相对的

就起到了优化也。废话说了一通,继续说我对程序部分经常采用的方式吧。

  • 2.1、首推静态化,这个的优化效果不用多说,直接减轻了服务器负担,不过如果用上了Squid

,那么有第三放来做静态,也可以达到同样的效果。

  • 2.2、合适的数据缓存,缓存很多人都用到了,但是在使用前,是否认真思考过为这个这个要

进行Cache,Cache他的标准是什么?我说下我的标准:小数据量、大访问量、更新尽量少的数据

,全部可以进行缓存。另外我提到的缓存,并不只是说。NET本身提供的Cache,我说的缓存还包

括了使用Static来进行的数据。

  • 2.3、活用线程,很多人的观念中感觉线程好象在B/S中是用不到的,或者是没有必要。其实这

个观念完全错,在特定情况下使用线程,可以提高的局部性能不是一点两点。

  • 2.4、功能模块拆分,这个一般人基本都在做,我要补充的是,不只是在单个项目中进行功能

模块的拆分,而是为了进行分步式开发而进行拆分。

在其它的基本都是细节优化了,这个没有太多兴趣写了,网上资料应该不少,可以自己搜索查阅。

3、结束语

上面的这几部分如果能在开发中,灵活运用上,可以说,你开发个大规模的站点,绝对不是难

事。我曾经开发的过的站点中,也有过社区,一个WEB服务器,一个DB服务器,主题帖千万,回

复帖有6000W左右吧,其它数据不算,运行过程中没出过任何问题,日访问在100WPV情况下,还

没有达到性能瓶颈。


全部评论: 0

    我有话说: