`
javasee
  • 浏览: 965080 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

采用什么架构,才能够承受大访问量

 
阅读更多

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

部署架构,就是开发完的程序在实际运行环境下,通过负载均衡,DNS轮询,SquID等等来减轻单台服务器负载,达到性能优化的目的

这里大家估计更想了解的是开发上的架构

我对这个的观点是,所有的架构都是死的,而性能优化策略是活的,我在开发中,所有的东西都不是一定要按照什么固定的模式,去死开发,更多的是针对需要优化的信息进行针对处理,下面说说我的优化策略

1、数据库优化,这个是所有的优化策略中中重要的,可以说数据库设计的好坏,直接影响了一个系统的承受力。普通的数据库细节优化,网上已经有大笔文章了,没什么好说的,想了解的自己去找。而我要说的就是在数据库设计中的一个思路,分库、分表、缓存表。

1)分库指的是在设计中,要考虑到后期数据量大的情况下,你的数据库能够随着应用随时拆分,这个拆分并不是只是针对功能模块对应的数据拆分。举个例子,就用这个CSDN论坛吧,比如里面有很多类,C#版,JAVA版,系统设计版等等,拆分的目的是可以把任何一个版的数据拆分到单独的一个数据库中去。

2)分表相对的就好理解了,就是说同类型的数据,你可以为了性能优化,进行拆分到多个表中去,拆分规则可以有多种,按照类型、按照时间、按照姓名等等。同样以这个CSDN论坛来说,我要设计的话,我会按照里面的大版面进行数据库拆分,而按照小版,进行表拆分。

3)而对于缓存表,网上我还很少看到有人来说这个东西,这个的目的就是针对一个大的数据表中,一般中有死数据库和活动数据,比如用户表,里面有很多基本不来的用户,那么针对这样的情况,当表数据上了千万的时候,我就会采用缓存表的模式来进行了,就是在实际表和用户之间在搭建一个临时表,访问用户数据时,首先访问临时表,如果不存在,则进入实际表中获取,然后放入缓存表中,同时会通过后台线程,定时将缓存表数据同步到实际数据库中,同步时间可以针对系统要求来进行。

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

2、程序优化。这个对我来说相对的就不是那么的看中了,程序的优化,我更多的认为是个技巧,而不是架构了,包括现在经常见到的那些各种设计模式,另外这里提下,很多设计模式,他的出发点并不是性能优化,而是考虑的系统扩展性,所以在单个技术细节上,很多人也发现了,并不如直接的写代码来的快,但是就是推荐那样,是因为采用了那些模式的程序,扩展性比你的强,那么一旦系统要求变动,或者是要求进行拆分的时候要比你方便的多,在分担到多个服务器上时,性能相对的就起到了优化也。废话了通,继续说我对程序部分经常采用的方式吧

1) 首推静态化,这个的优化效果不用多说,直接减轻了服务器负担,不过如果用上了Squid,那么有第三放来做静态,也可以达到同样的效果

2) 合适的数据缓存,缓存很多人都用到了,但是在使用前,是否认真思考过为这个这个要进行Cache,Cache他的标准是什么?我说下我的标准:小数据量、大访问量、更新尽量少的数据,全部可以进行缓存。另外我提到的缓存,并不只是说。NET本身提供的Cache,我说的缓存还包括了使用Static来进行的数据

3) 活用线程,很多人的观念中感觉线程好象在B/S中是用不到的,或者是没有必要。其实这个观念完全错,在特定情况下使用线程,可以提高的局部性能不是一点两点

4) 功能模块拆分,这个一般人基本都在做,我要补充的是,不只是在单个项目中进行功能模块的拆分,而是为了进行分步式开发而进行拆分

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


上面的这几部分如果能在开发中,灵活运用上,可以说,你开发个CSDN这样规模的站点,绝对不是难事。
我曾经开发的过的站点中,也有过社区,一个WEB 服务器,一个DB服务器,主题帖千万,回复帖有6000W左右吧,其它数据不算,运行过程中没出过任何问题,日访问在100W PV情况下,还没有达到性能瓶颈

7
0
分享到:
评论

相关推荐

    互联网架构,如何进行容量设计

    在互联网公司中,经常会遇到技术老大向产品经理或开发人员提出类似的问题:“我们的系统能够承受即将到来的大规模活动吗?”或者“我们需要对数据库进行分库处理吗?如果需要,应该分成多少个库?”这些问题的核心...

    大型网站架构演变和知识体系.pdf

    随着访问量持续增长,单个Web服务器已经难以承受高峰期的访问压力。这时,通过添加更多的Web服务器来分担负载成为必要的选择。增加Web服务器的同时需要考虑如何实现负载均衡,即将请求均匀地分发到多个服务器上。...

    收集的大型网站架构实例

    【大型网站架构实例详解】 ...通过对Mixi和Flickr等大型网站架构的分析,我们可以学习到如何构建能够承受大规模用户负载、保持高可用性和可扩展性的系统。这些实践经验对其他大型网站的架构设计提供了宝贵的参考。

    互联网高并发技术架构图

    高并发技术架构设计是确保系统稳定、高效运行的关键,尤其在处理大规模用户访问和数据交互时显得尤为重要。"互联网高并发技术架构图" 描述了如何构建一个能够应对高并发的复杂系统,涉及到多个关键领域和组件。 1. ...

    网站--高并发web架构

    在IT行业中,高并发Web架构是构建大型、高性能互联网应用的核心技术之一。它涉及如何处理大量用户同时访问网站或服务的场景,确保系统的...通过学习和实践这些技术,可以构建出能够应对大规模用户访问的高效Web系统。

    国内大公司数据架构

    ### 国内大公司数据架构概述 随着大数据时代的到来,数据已经成为推动企业发展的核心资源之一。对于大型互联网公司而言,构建高效稳定的数据架构是至关重要的。本文将基于百度与淘宝这两家国内顶级互联网企业的实际...

    高并发高负载大型网站系统架构

    【高并发高负载大型网站系统架构】是指设计和构建能够处理大规模用户访问、高并发请求的网站系统。这种系统架构必须具备高安全性、高稳定性、高并发处理能力和高负载承受能力,以应对如淘宝等大型电商平台所面临的...

    大型WEB网站架构深入分析

    6. **负载均衡**:当网站面临极高访问量和并发请求时,负载均衡是必备技术。它能够将流量分散到多台服务器,确保没有单一故障点,同时提高可用性和响应时间。负载均衡可通过硬件设备(如四层交换机)或软件实现(如...

    大规模网站架构技术原理透析.pdf

    随着访问量的增大,网站需要能够承受巨大的并发流量。这需要采用高性能的服务器、负载均衡技术以及优化的数据库设计。负载均衡可以通过DNS轮询、IP哈希、会话持久化等方式分散流量,确保单一节点不会过载。 3. 用户...

    12大型 HTTP 服务器架构演进路线及思路(2).md

    这种架构简便易行,能够满足初期业务量小、访问量低、业务单一的需求。在这个阶段,尽管资源集中,但解耦的设计思想仍然需要被重视,以保证后续的可扩展性。 #### 应用程序、数据和存储分离 随着业务量的增长,单体...

    大规模网站架构.rar

    【大规模网站架构】是互联网行业中一个至关重要的主题,它涉及到如何设计、构建和维护能够处理海量用户请求的网络应用系统。这份名为“大规模网站架构.ppt”的文档很可能提供了关于这一主题的深入讲解,包括常见的...

    大数据环境下基于MySQL的数据库架构设计与实现.pdf

    现阶段,大数据的定义已经不再单纯局限于数据的规模大小,它代表着传统的计算机技术已经难以有效处理庞大的数据信息,同时也代表着大数据处理的新技术和新方法,将会带来更大的发展。通常来说,大数据具有四个特征。...

    大型网站架构方案分析与总结.doc

    大型网站架构的设计与实施是一项复杂的工程,它涉及到许多关键问题,以确保网站能够承受高负载、高数据交换和高数据流动性。以下是一些核心的关注点: 1、海量数据处理:随着用户数量的增加,网站需要处理的数据量...

    京东商城无线端运营后台(通天塔)架构演变

    - **订单峰值**:6月18日当天订单量达到了高峰,表明系统在高峰期能够承受巨大的压力。 - **流量变化**:通过流量趋势图可以看出,从6月1日到6月18日期间,网站流量呈稳步上升的趋势,在6月18日达到顶峰。 这些数据...

    大型高并发高负载网站的系统架构

    【大型高并发高负载网站的系统架构】是一个关键的话题,涉及到如何设计和构建能够承受大量用户访问和高并发请求的网站。随着互联网业务的发展,网站技术已经变得极为复杂,特别是对于大型网站而言,它们需要应对的...

    淘宝技术架构分享.rar

    淘宝的技术架构必须能够应对流量的剧烈波动,比如在“双十一”等大型促销活动期间,系统需要承受比平时高出几倍甚至几十倍的访问压力。这要求系统设计时就考虑到了水平扩展,通过分布式计算和存储,实现服务的横向扩...

    亿级流量网站架构核心技术高清版——双11及618实战架构

    《亿级流量网站架构核心技术高清版——双11及618实战架构》是一本深入探讨高并发、大规模流量场景下网站架构设计的专业书籍。它针对电商行业中的两大关键节点——双11与618大促,详尽剖析了如何应对海量用户访问带来...

Global site tag (gtag.js) - Google Analytics