高性能高并发服务器架构.pdf

所需积分/C币:9 2012-07-11 02:47:17 4.77MB PDF
收藏 收藏 5
举报

高性能高并发服务器架构.pdf,豆瓣案例
方案探讨关于工程中数据库的问题己结贴 软件设计时考虑你的性能解决方案 ●大型 系统服务器选型问題探讨 ●高并发高流量网站架构 互联网的发展 互联网网站建设的新趋势 新浪播客的简介 镜像网站技术 内容分发网终 应用层分布式设计 网络层架构小结 第四层交换简介 硬件实现 软件实现 ●网站架构的高性能和可扩展性 ●资料收集:高并发高性能高扩展性 站点架构设计及优化策略 性能问题浅析 鸡肋式的多站点支持 内容数据的集中式存储 过于依赖缓存 ccs的雪上加霜 如何解决? Library 不管怎么样,先要找出瓶颈在哪个部分:是负荷太高(经常%),还是内存不够用 (大量使用虚拟内存),还是磁盘性能跟不上(硬盘指示灯狂闪)?这几个都是可以通 过升级硬件来解决或者改善的(使用更高等级的,更快速和更大容量的内存,配貿硬 件磁盘阵列并使用更多数量的高速硬盘),但这需要较大的投入。 軟件方面,如果使用了更大容量的内存和改善的性能,凵经能够大幅提高数据库的运行 效率,还可以配置查询缓存和进一步优化数据库结构和查询语句,就能让数据库的性能再进 大步。 如果在服务器硬件投入上有困难,那就尽量生成静态贞面。 作者 标题目前的web系统架构 时间 点击 逐步迁移 静态文件 逐步迁移到 上 最大好处是静态文件加速。 以后准备把帖子内容也静态化,实现最低负荷 而且用 做前台便于负绒均衡,测试机可以拿来做静态文件的负载均衡 ●初创网站与开源软件 前面有一篇文章中提到过开源软件,不过主要是在系统运维的角度去讲的,主要分析一些系 统级的开源软件(例如bind, memcached),这里我们讨论的是用于搭建初创网站应用的开源 軟件(例如 phpbb, phparticle),运行在 Linux, MySQL, Apache,PHP,ava等下面。 创业期的网站往往采用比较简单的系统架构,或者是直接使用比较成熟的开源软件。使用开 源软件的好处是搭建速度快,基本不需要开发,买个空间域名,下个软件一搭建,用个半天 就搞定了,一个崭新的网站就开张了,在前期可以极大程度的节约时间成本和开发成本 当然使用开源软件搭建应用也存在一些局限性,这是我们要重点硏究的,而研究的目的就是 如何在开源软件选型时以及接下米的维护过程中尽量避免 方面是开源软件一般只有在比较成熟的领域才有,如果是一些创新型的项目很难找到合适 的开源软件,这个时候没什么好的解决办法,如果非要用开源的话一般会找一个最相似的改 下。实际上目前丌源的项目也比较多了,在 sf. net上可以找到各种各样的开源项目。选型 的时候尽量应该选取一个程序架构比较简单的,不一定越简单越好,但一定要简单,一目了 然,别用什么太高级的特性,互联网应用项目不需要太复杂的框架。原因有两个,一个是框 架复杂无非是为」实现史好的可扩展性和史清晰的层次,而我们正在做的互联网应用范围 般会比开源软件设计时所考虑的范围小的多,所以有的应用会显得设计过度,另外追求完关 的层次划分导致的太复杂的继承派生关系也会影响到整个系统维护的工作量。建议应用只需 要包含三个层就可以了,数据(实体)层,业务逻辑层,表现层。太复杂的设计容易降低开发 效率,提高维护成本,在出现性能问题或者突发事件的时候也不容易找到原因 另外一个问题是开源软件的后期维护和继续开发可能公存在问题,这一点不是绝对的,取决 于开源软件的架构是否清晰合理,扩展性好,如果是较小的改动可能一般不公存在什么问题, 例如添加一项用户属性或者文章属性,但有些需求可能就不是很容易实现了。例如网站发展 到一定阶段后可能会考虑扩展产品线,原来只提供一个论坛加上cms,现在要再加上商城, 那用户系统就会有问题,如何解决这个问题已经不仅仅是改一下论坛或者cms就可以解决 了,这个时候我们需要上升到更高的层次米考虑问题,是否需要建立针对整个网站的用户认 证系统,实现单点登录,用户可以在产品间无缝切换而且保持登录状态。由于网站初始的用 户数据可能大部分都存放在论坛里,这个吋候我们需要把用户数据独立出来就会碰到麻烦, 如何既能把用户数据独立岀来乂不影响论坛原有系统的继续运行会是件很头痛的事情。经过 段时间的运行,除非是特别好的设计以及比较好的维护,一般都会在论坛里存在各种各样 乱七八糟的对用户信息的调用,而且是直接针对数据库的,这样如果要将用户数据移走的话 要修改代码的工作量将不容忽视,而另外一个解决办法是复制一份用户数据出来,以新的用 户数据库为主,论坛里的用户数据通过同步或异步的机制实现同步。最好的解决办法就是在 选型时选一个数据层封裝的比较好的,sq代码不要到处飞的软件,然后在维护的时候保持 系统原有的优良风格,把所有涉及到数据库的操作都放到数据层或者实体层里,这样无论对 数据进行什么扩展,代码修改起米都比较方便,基本不会对上层的代码产生影响。 网站访问速度问题对初创网站来说一般考虑的比较少,买个空间或者托管服务器,搭建好应 用后基本上就开始运转了,只有到真正面临极大的速度访问瓶颈后才会真正对这个问题产生 重视。实际上在从网站的开始阶段丌始,速度问题就会·直存在,并且会随着网站的发展也 不断演进。个网站最基本的要求,就是有比较快的访问速度,没有速度,再好的内容或服 务也出不来。所以,访问速度在网站初创的时候就需要考虑,无论是采用井源软件还是自凵 开发都需要注意,数据层尽量能够正确,高效的使用 SQLo SQL包含的语法比较复杂,实现 同样一个效果如果考虑到应用层的的不同实现方法,可能有好几种方法,但里面只有一种是 最高效的,而通常情况下,高效的SQL一般是那个最简单的SQL。在初期这个问题可能不 是特别明显,当访问量人起来以后,这个可能成为最主要的性能瓶颈,各种杂乱无章的SQL 会让人看的疯掉。当然前期没注意的话后期也有解决办法,只不过可能不会解决的特别彻底, 但还是要吧非常有效的提升性能。看 MySQL的 SlowQuery Log是一个最为简便的方法,把 执行时间超过1秒的查询记录下来,然后分析,把该加的索引加上,该简单的SQL简化。 另外也可以通过 Showprocesslist査看当前数据库服务器的死锁进程,从而锁定导致问题的 sαL语句。另外在数据库配置文件上可以做一些优化,也可以很好的提升性能,这些文章在 网站也比较多,这里就不展开。 这些匚作都做了以后,下面数据库如果再出现性能问题就需要考虑多台服务器了,·台服务 器已经解决不了问题了,我以前的文章中也提到过,这里也不再展丌 其它解决速度问题的办法就不仅仅是在应用里面就可以实现的了,需要从更高的高度去设计 系统,考虑到服务器,网络的架构,以及各种系统级应用软件的配合,这里也不再展丌。 良好设计并实现的应用+中间件+良好的分布式设计的数据斥+良好的系统配置+良好的服 务器/网络结构,就可以支撑起个较大规模的网站了,加上前面的几篇文章,·个小网站 发展到大网站的过程基本上就齐了。这个过程会是个充满艰辛和乐趣的过程,也是·个可 以逐渐过渡的过程,主动出击,提前考虑,减少救火可以让这个过程辁松一些。 ●谈谈大型高负载网站服务器的优化心得! 因为工作的关系,我做过儿个大型网站(书库、证券)的相关优化工作,一般是 在世界排行 以内的 这些网站使用的程序各不一样,配置也不尽相同,但是它们有一个共同的特点, 就是使用的是 系统,高配置高负载,值非常高,都是需要用两台 以上独立主机来支持的网站 我在优化及跟踪的过程中,开始效果也差强人意,也不太理想,后来通过阅读大 量资料才慢慢理清了一些思路,写出来希望给人家有所帮助 服务器配置是 以上,内存以上,硬盘一块以上, 以上 数据库服务器与服务器类似 书库程序是使用的的,论坛是使用的 的 光纤独享带宽 定要重新编译内核,根据白己对内核认识的程度和服务器的具体配詈来优 化,记住打开 也可以使用调度 要优化系统的值,一般是添加入 里面,要加大内核文件并发数 量及其他优化等值。 使用 工作模式就可以了,我试过 模式,实在是差 强人意呀。修改 里面的值,加大并发数量和关闭不需要的模块。因为 非常消耗内存,尽量轻装上阵可以适当的使用长连接。关闭日志 、编译的吋候,注意要尽量以实用为目的加入参数,没有用到的坚决不加, 以免浪费系统瓷源 要使用较小的优化等级,就足够了,级别只会加重服务器负载 要尽量少使用长连接,限制为秒即可 要全部采用手工编译方式,不要用装,因为它会带上很多你不需要的 模块,切记。 、对于这类高负载髙在线人数的大站,所有优化的思路就是把尽可能多的系统 资源,提供给 和 服务,并且让这些服务单个进程可以占用尽可能 少的系统资源。如果系统一开始人量使用 ,对于这些服务器来说,服务器 状态将会极剧恶化。 长时间观察跟踪调试,有什么问题尽快解决 就想到这些东东,欢迎大家补充 梦飞 补充我的儿点优化 、编译 时使用参数传递对特定进行优化; 、如果网站小文件很多,可以老虑使用 磁盘系统,提升读写性能 、如不需要 ,则将 设置为 对于 服务器繁忙,加大内存可以解决不少问题。 纯交互站点,性能会是个瓶颈。需要长期跟踪更改参数 搭建高效率服务器 发表于 分类 ②會 架构原理 通常是开源界的首选服务器,因为它的强人和可靠,已经具有了品牌效应,可以 适用于绝大部分的应用场合。但是它的强大有时候却显得笨重,配置文件得让人望而生畏,高并 发情況下效率不太高。而轻量级的服务器 却是后起之秀,其静态文件的响应能力 远高于 ,据说是 的倍。 的高性能和易用性,足以打动我们,在它 能够胜任的领域,尽量用它。 的支持也很好,还可以通过 方式支持其 他的语言,比如 毕竞 是轻量级的服务器,功能上不能跟 比,某些应用无法胜仟。比如 还不支持缓存,而现在的绝大部分站点都是用程序生成动态内容,没有缓存的话即使程序的效率 再高也很难满足大访问量的需求,而且让程序不停的去做同一·件事情也实在没有意义。首先, 程序是需要做缓存处理的,即把反复使用的薮摭俶缓存。即使这样乜还不够,单单是启动 处理程序的代价就不少,缓存最后生成的静态页面是必不可少的。而做这个是 的强 项,它本是做代理的,攴持高效的缓存,可以用来给站点反向代理加速。把 放在 或者 的前端来缓存服务器生成的动态内容,而应用程序只需要适当地设置 页面实效时间即可。 即使是大部分内容动态生成的网站,仍免不了会有一些静态元素,比如图片、脚本、 等,将 放在 或者 前端后,反而会使性能下降,毕竞处理请求是 服务器的强项。而且已经存在于文件系统中的静态内容再在中缓存一下,浪费內存 和硬盘空间。因此可以考虑将 再放在 的前面,构成 的 一条处理链, 在最前面,专门用来处理静态内容的请求,把动态内容请求通过 模 块转发给 如果中有该请求的内容且没有过期,则直接返回给 。新请求或 者过期的页面请求交由 中程序来处理。经过 和 的两级过滤, 需要处理的请求将大大减少,减少了应用程序的压力。同时这样的构架,便于把不同的处 分散到多台计算机上进行,由 在前面统一把关。 在这种架构下,每一级都是可以进行单独优化的,比如 可以采用异步方式, 可以启用内存来缓存, 可以启用等,并且每一级都可以使用多台机器来均衡负载, 伸缩性很好。 实例讲解 下面以 和 域下面的几个站点为例来介绍一下此方案的具体做法 域下有几个用 实现的站点,几个的站点,一个 的小程序,以后可能还会架设儿个和 的站点而服务器非常弱,为 内存为 ,因此比较关注服务器的效率。这几个站点都是采用虚拟主机方式, 开在同一台机器的同一个端口上。

...展开详情
试读 127P 高性能高并发服务器架构.pdf
立即下载 低至0.43元/次 身份认证VIP会员低至7折
一个资源只可评论一次,评论内容不能少于5个字
votary 不错,很有参考价值
2020-06-25
回复
青衣慕云 东西是好东西,可惜水平不够,很多东西都看不懂。还得努力学习
2015-11-16
回复
Navagate 看了看,觉得非常有参考价值
2015-05-23
回复
hzrlxl 非常有参考价值,多谢楼主
2015-05-02
回复
retunfalse 理论的东西看不懂,需要有实际操作机会
2014-12-25
回复
IAMWilliamLee 该书确实是作者整理出的各种方案,涉及面广。但是感觉不太适合初级工程师,看的不是太懂,有些技术根本没听过,所以上面的心得根本不能体会出来
2014-09-25
回复
ytlizhen1 下载完成 正在看 感觉不错 .
2014-06-26
回复
gy_bison 也许我的水平还不够,很多理论的东西看不懂,需要有实际操作机会
2013-12-31
回复
fy516619 看了看,总结的还行,各方面都有涉及。
2013-12-23
回复
daimaqing 下载完成 正在看 感觉不错
2013-03-20
回复
关注 私信 TA的资源
上传资源赚积分,得勋章
最新推荐
高性能高并发服务器架构.pdf 9积分/C币 立即下载
1/127
高性能高并发服务器架构.pdf第1页
高性能高并发服务器架构.pdf第2页
高性能高并发服务器架构.pdf第3页
高性能高并发服务器架构.pdf第4页
高性能高并发服务器架构.pdf第5页
高性能高并发服务器架构.pdf第6页
高性能高并发服务器架构.pdf第7页
高性能高并发服务器架构.pdf第8页
高性能高并发服务器架构.pdf第9页
高性能高并发服务器架构.pdf第10页
高性能高并发服务器架构.pdf第11页
高性能高并发服务器架构.pdf第12页
高性能高并发服务器架构.pdf第13页
高性能高并发服务器架构.pdf第14页
高性能高并发服务器架构.pdf第15页
高性能高并发服务器架构.pdf第16页
高性能高并发服务器架构.pdf第17页
高性能高并发服务器架构.pdf第18页
高性能高并发服务器架构.pdf第19页
高性能高并发服务器架构.pdf第20页

试读结束, 可继续阅读

9积分/C币 立即下载 >