大并发server架构 && 大型站点架构演变

时间:2023-12-28 21:52:32

server的三条要求:

高性能:对于大量请求,及时高速的响应

高可用:7*24 不间断,出现问题自己主动转移。这叫fail over(故障转移)

伸缩性:使用跨机器的通信(TCP)

另外不论什么网络系统结构都能够抽象成C/S架构。我们常说的B/S模式本质上也是C/S架构(浏览器看作client)。

一个典型的server架构:

大并发server架构 && 大型站点架构演变

注: epoll是linux下最高效的网络I/O

因为server须要高效处理大并发连接。因此多个位置均可能出现性能瓶颈,以下我们分析不同位置产生瓶颈的原因及其处理方法:

(一)数据库瓶颈

【1】超过数据库的连接数的解决方法:加上一层DAL。使用队列等待(队列等待--数据訪问层)。也能够再使用连接池(DAL队列服务+连接池)这样不须要又一次连接。直接从池中找资源。

【2】超出时限的解决方法:

(1)将业务逻辑放置应用server(操作系统业务处理),数据库逻辑不要太复杂。仅仅是进行一定的辅助业务处理。

(2)缓存数据。可是面临缓存的更新和同步的问题,例如以下:

1. 缓存的时效性。if timeout then 又一次去数据库查询。(将热点数据放至缓存)这样的方法实时性较差。

2. 一旦数据库更新,马上通知前端缓存更新。

Update之后改动更新缓存,实时性较好。可能实现起来较难。

假设内存不够用,那么就放到外部磁盘,使用缓存换页机制(类似OS中的内存换页)。

上面提到的这些都能够使用开源产品实现:Nosql ---> (反sql )

主要存放非关系的数据。key/value

还有Redis 。memached 缓存等分布式开源软件。这些软件是能够跨server的。可是假设部署在应用server上,则是局部的,其它同级server訪问非常麻烦。

可是假设单独布置机器,使用分布式缓存,这些就是全局的。全部的应用server都能够訪问。方便快捷。

【3】数据库读写分离

数据库的查询操作一般比写操作频繁,我们能够对数据库进行负载均衡。使用主server进行写操作,从server进行读操作。DAL进行读写分离,通过replication机制进行主从server间的同步。

【4】数据分区(分库、分表)

分库:数据库能够依照一定的逻辑把表分散到不同的数据库--->垂直分区(用户表,业务表)

更加经常使用的分表--水平分区:将表中的记录分至不同的数据库,10条记录分至10个数据库,类似这样,这样的方式非常easy扩展水平结构。

(二)应用server瓶颈

加入任务server相应用server的任务分配进行负载均衡,当中又分为主动和被动两种方案:

(1)应用server被动接受方案:

使用任务server实现负载均衡,暴露一个接口,任务server能够当作一个client,应用server看作httpserver

任务server能够监视应用server的负载,CPU/IO/并发/内存换页高,查询到信息后,选取负载最低(算法确定)的server来分配任务.

(2)应用server主动到任务server接受任务进行处理

应用server处理完自己的任务后主动向任务server申请求任务。

(1)的方式可能会造成不公平。(2)的缺点是假设应用server处理不同的业务。那么可能任务server的编程逻辑会非常复杂。

当中任务server能够设置多台。彼此之间通过心跳联系------>满足 高可用性(fail over机制)。

如此一来(数据库,缓存,应用server,任务server)不论什么位置出现瓶颈就仅仅须要添加server好了。

为了高效的进行服务端的编程。我们也须要知道server性能四大杀手:

(1)数据拷贝 ----> 缓存来解决

(2)环境切换 -----> 理性创建线程:是否须要多线程。哪个好?单核server(採用状态机的编程效率最佳,类似OS中的进程切换)

多线程可以充分发挥多核server的性能,也要注意线程间切换的开销

(3)内存分配 ------> 内存池,降低向操作系统申请内存

(4)锁竞争 -------> 通过逻辑尽量降低锁的使用

以上的信息能够归纳为以下的这张图:

大并发server架构 && 大型站点架构演变

我们接下来介绍实际中的大型站点架构的演变过程,和我们上面的问题处理流程基本一致:

[Step1]web server与数据库分离

大并发server架构 && 大型站点架构演变

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

大并发server架构 && 大型站点架构演变

Apache/Nginx处理静态(前端server)  JBoss/Tomat处理动态 (后端server)

[Step2]缓存处理

大并发server架构 && 大型站点架构演变

1.浏览器缓存降低对站点的訪问

2.前端server静态页面缓存降低对webserver的请求

3.动态中相对静态的部分使用ESI

4.本地缓存降低对数据库的查询

[Step3]web server集群+读写分离

大并发server架构 && 大型站点架构演变

负载均衡:
前端负载均衡
DNS负载均衡
在DNSserver中,能够为多个不同的地址配置同一个名字,对于不同的客户机訪问同一个名字,得到不同的地址。
反向代理
使用代理server将请求发给内部server,让代理server将请求均匀转发给多台内部webserver之中的一个。从而达到负载均衡的目的。标准代理方式是客户使用代理訪问多个外部Webserver。而这样的代理方式是多个客户使用它訪问内部Webserver。因此也被称为反向代理模式。
基于NAT的负载均衡技术
LVS
F5硬件负载均衡
应用server负载均衡

数据库负载均衡

[Step4]CDN、分布式缓存、分库分表

大并发server架构 && 大型站点架构演变

眼下流行分布式缓存方案:memcached、membase、redis等,基本上当前的NoSQL方案都能够用来做分布式缓存方案

[Step5]多数据中心+分布式存储与计算

大并发server架构 && 大型站点架构演变

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

技术点:分布式文件系统(DFS)

大并发server架构 && 大型站点架构演变

Map/Reduce:

文件太大,无法载入至内存。切割得到key-value数据,这个是map过程(多个机器完毕)

将其合并的过程称为reduce。Map-->combine-->reduce,这就是所谓的分布式计算。