高性能大并发服务器架构

一个典型的服务器结构


主要由三部分组成


网络I/O+服务器高性能编程技术+数据库



一:网络I/O

网络I/O方面,linux下面使用 epoll,windows上面有IOCP,其他平台还有kqueue,dev/poll等机制。


二:服务器及数据库的负载均衡


1.数据库

数据库可能会有以下几点需要解决:


1.超出数据库连接数
    假设数据库并发连接数10个,应用服务器这边有1000个并发访问请求,将会有990个失败。
    
解决方法: 队列 + 连接池
    即加一个中间层DAL(数据库访问层),DAL和应用服务器即可以部署在同一台服务器,
也可以部署在不同台服务器,它们使用TCP通信。最好使用DAL队列服务+连接池的方式。


2.超出时限

数据库并发连接数10个,数据库1秒之内最多能处理1000个请求,应用服务器这边有10000个并发请求,会出现0~10秒的等待



解决方法: 使用缓存
    数据库上的业务逻辑处理应该简单,主要业务逻辑的处理放在应用服务器上。不过这也很有限的降低

数据库的压力。更好的方法是缓存。但是一旦应用了缓存,就会出现缓存的更新,缓存的同步问题。


1.缓存具有一定的时效timeout,如果缓存失效,有两种方法:
(1)对于查询上的缓存,就需要重新去数据库里面查询,查询到数据后更新缓存,进行缓存同步。
将一些热点数据存至缓存,这种方法实时性比较差。
(2)一旦数据库中数据更新,立即通知前端的缓存更新,实时性比较高,但实现有一定难度。


2.缓存换页
内存不够,将不活跃的数据换出缓存。可以使用FIFO,LRU(least recently used)即最近最少使用、
LFU(least frequently used)最近最不频繁使用。
这些技术nosql中都有这种功能。比如redis,memcached都可以作为分布式缓存。
同样,由于 可伸缩性,缓存也可以不跟服务器放在同一台机器上。如果放在同一台机器上,它就只是
一个局部的缓存,只能被该机器访问。如果是部署在独立的机器上,并且使用了分布式缓存机制,它就是全局缓存,
可以被各个服务器访问。


那么如果前端还有大并发请求呢?
我们应该做数据库 读写分离
对于大部分数据库而言,数据库的读操作多于写操作。我们可以对数据库进行负载均衡。
现在主流的数据库都有replication机制。
查询到读库,写到写库,对于写数据需要更新到读库,这就是主从分布replication机制。

那么数据库负载均衡了,现在压力又到应用服务器上了。

二.应用服务器

应用服务器的负载均衡
方案一: 应用服务器被动接受任务方案
增加一个任务服务器来实现,任务服务器可以监视应用服务器的负载,到底是CPU高还是I/O高,还是并发
高,或者是内存换页高。
应用服务器可以暴露一个http接口给任务服务器,任务服务器选取负载最低的服务器分配任务。


方案二: 应用服务器主动请求任务方案
当应用服务器任务执行完毕后,主动去任务服务器请求任务。


那么任务服务器如果故障了怎么办呢?
任务服务器需要有两台,甚至多台!任务服务器应该具有 fail over(故障转移)机制。
当其中一台任务服务器故障或者失效了,另一台应该可以立刻投入使用,它们两者之间通过心跳来实现,
这就是 服务器的高可用(HA机制high abalitity)。


但是对于大型的应用来说,数据库的量是非常庞大的。
这时候应该对数据库进行数据分区(分库,分表)
分库,即垂直分区,是指数据库可以按照一定的逻辑,把表分散到不同的数据库。比如一个数据库有用户
相关的表,有业务相关的表,有基础信息相关的表,就可以分成三个库。


但更加常用的是水平分区,将一个数据库水平切割为若干个数据库,每个数据库都有这些表,用户表,业务表,信息表。
这种方式需要改写DAL的代码。

三:高性能编程技术

服务器性能四大杀手:
数据拷贝:应该尽可能减少数据拷贝,内存拷贝,同样得利用缓存机制解决。
环境切换:(理性创建线程)线程切换,该不该用多线程,单线程好还是多线程好?
答:单核服务器(状态机编程效率是最高的),单核服务器是不能够并行处理任务的。如果使用多线程,
   会增加线程间的切换开销。如果服务器是多核的,多线程能够充分发挥多核并行的优势,但是多核
   服务器使用多线程,也应该尽可能避免线程之间的环境切换。
内存分配:使用内存池技术解决
锁竞争:锁竞争会降低程序性能,应该尽可能通过逻辑来避免锁的使用。

整理的高性能并发服务器架构文章,内容预览:  初创网站与开源软件 6  谈谈大型高负载网站服务器的优化心得! 8  Lighttpd+Squid+Apache搭建高效率Web服务器 9  浏览量比较大的网站应该从哪几个方面入手? 17  用负载均衡技术建设高负载站点 20  大型网站的架构设计问题 25  开源平台的高并发集群思考 26  大型、高负载网站架构和应用初探 时间:30-45分钟 27  说说大型高并发高负载网站的系统架构 28  mixi技术架构 51 mixi.jp:使用开源软件搭建的可扩展SNS网站 51 总概关键点: 51 1,Mysql 切分,采用Innodb运行 52 2,动态Cache 服务器 -- 52 美国Facebok.com,中国Yeejee.com,日本mixi.jp均采用开源分布式缓存服务器Memcache 52 3,图片缓存和加 52  memcached+squid+apache deflate解决网站大访问量问题 52  FeedBurner:基于MySQL和JAVA的可扩展Web应用 53  YouTube 的架构扩展 55  了解一下 Technorati 的后台数据库架构 57  Myspace架构历程 58  eBay 的数据量 64  eBay 的应用服务器规模 67  eBay 的数据库分布扩展架构 68  从LiveJournal后台发展看大规模网站性能优化方法 70 一、LiveJournal发展历程 70 二、LiveJournal架构现状概况 70 三、从LiveJournal发展中学习 71 1、一台服务器 71 2、两台服务器 72 3、四台服务器 73 4、五台服务器 73 5、更多服务器 74 6、现在我们在哪里: 75 7、现在我们在哪里 78 8、现在我们在哪里 79 9、缓存 80 10、Web访问负载均衡 80 11、MogileFS 81  Craigslist 的数据库架构 81  Second Life 的数据拾零 82  eBay架构的思想金矿 84  一天十亿次的访问-eBay架构(一) 85  七种缓存使用武器 为网站应用和访问加速发布时间: 92  可缓存的CMS系统设计 93  开发大型高负载类网站应用的几个要点 105  Memcached和Lucene笔记 110  使用开源软件,设计高性能可扩展网站 110  面向高负载的架构Lighttpd+PHP(FastCGI)+Memcached+Squid 113  思考高并发高负载网站的系统架构 113  "我在SOHU这几年做的一些门户级别的程序系统(C/C++开发)" 115  中国顶级门户网站架构分析1 116  中国顶级门户网站架构分析 2 118  服务器的大用户量的承载方案 120  YouTube Scalability Talk 121  High Performance Web Sites by Nate Koechley 123 One dozen rules for faster pages 123 Why talk about performance? 123 Case Studies 124 Conclusion 124  Rules for High Performance Web Sites 124  对于应用高并发,DB千万级数量该如何设计系统哪? 125  高性能服务器设计 130  优势与应用:再谈CDN镜像加速技术 131  除了程序设计优化,zend+ eacc(memcached)外,有什么办法能提高服务器的负载能力呢? 135  如何规划您的大型JAVA多并发服务器程序 139  如何架构一个“Just so so”的网站? 148  最便宜的高负载网站架构 152  负载均衡技术全攻略 154  海量数据处理分析 164  一个很有意义的SQL的优化过程(一个电子化支局中的大数据量的统计SQL) 166  如何优化大数据量模糊查询(架构,数据库设置,SQL..) 168  求助:海量数据处理方法 169 # re: 求助:海量数据处理方法 回复 更多评论 169  海量数据库查询方略 169  SQL Server 2005对海量数据处理 170  分表处理设计思想和实现 174  Linux系统高负载 MySQL数据库彻底优化(1) 179  大型数据库的设计与编程技巧 本人最近开发一个访问统计系统,日志非常的大,都保存在数据库里面。 我现在按照常规的设计方法对表进行设计,已经出现了查询非常缓慢地情形。 大家对于这种情况如何来设计数据库呢?把一个表分成多个表么?那么查询和插入数据库又有什么技巧呢? 谢谢,村里面的兄弟们! 183  方案探讨,关于工程中数据库的问题. 184  web软件设计时考虑你的性能解决方案 190  大型Java Web系统服务器选型问题探讨 193  高并发高流量网站架构 210 1.1 互联网的发展 210 1.2 互联网网站建设的新趋势 210 1.3 新浪播客的简介 211 2.1 镜像网站技术 211 2.2 CDN内容分发网络 213 2.3 应用层分布式设计 214 2.4 网络层架构小结 214 3.1 第四层交换简介 214 3.2 硬件实现 215 3.3 软件实现 215  网站架构高性能和可扩展性 233  资料收集:高并发 高性能 高扩展性 Web 2.0 站点架构设计及优化策略 243  CommunityServer性能问题浅析 250 鸡肋式的多站点支持 250 内容数据的集中式存储 250 过于依赖缓存 250 CCS的雪上加霜 250 如何解决? 251  Digg PHP's Scalability and Performance 251  YouTube Architecture 253 Information Sources 254 Platform 254 What's Inside? 254 The Stats 254 Recipe for handling rapid growth 255 Web Servers 255 Video Serving 256 Serving Video Key Points 257 Serving Thumbnails 257 Databases 258 Data Center Strategy 259 Lessons Learned 260 1. Jesse • Comments (78) • April 10th 261 Library 266 Friendster Architecture 273 Information Sources 274 Platform 274 What's Inside? 274 Lessons Learned 274  Feedblendr Architecture - Using EC2 to Scale 275 The Platform 276 The Stats 276 The Architecture 276 Lesson Learned 277 Related Articles 278 Comments 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 280  PlentyOfFish Architecture 281 Information Sources 282 The Platform 282 The Stats 282 What's Inside 283 Lessons Learned 286  Wikimedia architecture 288 Information Sources 288 Platform 288 The Stats 289 The Architecture 289 Lessons Learned 291  Scaling Early Stage Startups 292 Information Sources 293 The Platform 293 The Architecture 293 Lessons Learned 294  Database parallelism choices greatly impact scalability 295  Introduction to Distributed System Design 297 Table of Contents 297 Audience and Pre-Requisites 298 The Basics 298 So How Is It Done? 301 Remote Procedure Calls 305 Some Distributed Design Principles 307 Exercises 308 References 309  Flickr Architecture 309 Information Sources 309 Platform 310 The Stats 310 The Architecture 311 Lessons Learned 316 Comments 318 How to store images? 318 RE: How to store images? 318  Amazon Architecture 319 Information Sources 319 Platform 320 The Stats 320 The Architecture 320 Lessons Learned 324 Comments 329 Jeff.. Bazos? 329 Werner Vogels, the CTO of 329 Re: Amazon Architecture 330 Re: Amazon Architecture 330 Re: Amazon Architecture 330 It's WSDL 330 Re: It's WSDL 331 Re: Amazon Architecture 331  Scaling Twitter: Making Twitter 10000 Percent Faster 331 Information Sources 332 The Platform 332 The Stats 333 The Architecture 333 L
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值