服务器架构

简介:

1.常用服务器模型
a.迭代服务器
只有一个进程/线程处理请求
设计方法:
一般为单进程,加上select多路复用,非阻塞socket
b.迭代/并发混合型服务器
平时迭代处理,对消耗大的请求并发处理
设计方法:
平时是迭代型的服务器
处理请求时设置一个超时,当请求的处理时间超时时,创建一个进程/线程,把处理转给新的进程/线程处理,主进程/线程继续处理其他请求
c.并发服务器
多个进程/线程并发处理请求
设计方法: 多进程,多线程

 

2.以上三类的服务器比较
迭代服务器:最简单,性能不高
并发服务器:性能较高,但结构相对比较复杂,开发难度中等
迭代/并发混合型服务器:性能不错,但结构通常比单纯的并发服务器更复杂

 

3.多进程的并发服务器
a.每个连接fork一个进程
主进程accpet连接,有新连接到来时fork一个进程,然后继续accept,等待新的连接
数据传输由子进程处理,处理完后子进程exit
每个子进程只处理一个连接
b.Prefork进程,各个子进程竞争accept
主进程预先fork一些进程
各个子进程竞争accept,然后处理数据传输
一个子进程可以处理一个连接,也可以同时处理多个连接(通过select等)
惊群现象
c.Prefork进程,由父进程accept请求,通过流管道转发fd到子进程
主进程accept,通过流管道转发fd到子进程
子进程收到fd后,处理数据传输,处理结束后通知父进程
父进程处理的事情比较简单,容易监控子进程
以上3种方式性能比较:
a.每个连接fork一个进程:处理smtp等状态较多,数据量比较大时比较简单实用,总体性能不大好
b.Prefork进程,各个子进程竞争accept:比较简单,性能不错
c.Prefork进程,由父进程accept请求,通过流管道转发fd到子进程:代码复杂,性能一般不如上一种

 

4.多线程的并发服务器
每个连接一个线程
Prethread多个线程,各个线程互斥accept
Prethread多个线程,主线程accept并分发连接给子线程

 

5.多进程与多线程的比较
使用线程的模型:性能比使用进程要高,但代码比较复杂,对代码质量要求更高
线程出错后可能会影响到所有线程,多进程的模式一个进程出错一般不会影响其他进程
多线程模型共享数据比较简单有效,多进程模型共享数据比较麻烦,效率也不如线程

 

6.一些流行的网络服务器采用的模型
Sendmail: 采用多进程,每个连接fork一个进程.
每个连接fork一个子进程
子进程只处理一个连接
子进程fork一个localmail进程(可以由用户自己编写),通过管道把数据转给localmail处理,把邮件处理业务逻辑独立出来
优点:结构简单,不用维护复杂的状态机
Apache1.3:采用多进程, prefork进程,各个子进程竞争accept
Prefork一些子进程
子进程竞争accept,每次只处理一个连接
主进程不accept,根据负载情况调整子进程数量
子进程运行一段时间后,主进程会让它退出,然后创建一个新的进程,防止内存泄漏等
主进程通过shared memory监控子进程

 

7.Tencent自己的一些网络服务器采用的模型
移动QQ: Prefork多个进程,竞争accept,
典型的一问一答TCP服务器,结构简单
Prefork多个进程,竞争accept
每个进程通过select可以同时处理多个连接
采用这种结构的原因有:
每秒请求<1000,可以满足要求
结构简单,容易开发、维护

相关文章
|
6月前
|
人工智能 大数据 数据处理
事件驱动架构在云时代的优势
事件驱动架构在云时代的优势
60 1
|
1月前
|
运维 监控 负载均衡
深入理解无服务器架构:优势与挑战
【10月更文挑战第6天】深入理解无服务器架构:优势与挑战
|
1月前
|
缓存 Java 数据库
后端技术探索:从基础架构到高效开发的实践之路
【10月更文挑战第7天】 在现代软件开发中,后端技术是支撑应用运行的核心。本文将探讨如何从后端的基础架构出发,通过一系列高效的开发实践,提升系统的性能与可靠性。我们将深入分析后端框架的选择、数据库设计、接口开发等关键领域,并提供实用的代码示例和优化策略,帮助开发者构建更稳定、高效的后端系统。通过这篇文章,读者将获得关于后端开发的全面理解和实践指导,从而更好地应对复杂项目需求。
67 0
|
3月前
|
缓存 NoSQL 数据库
高性能Web服务器架构设计
【8月更文第28天】在当今互联网时代,网站的响应速度直接影响用户体验和业务成功率。因此,构建一个高性能的Web服务器架构至关重要。本文将从硬件配置、软件架构以及网络设置三个方面探讨如何提高Web服务器的性能,并提供一些实际的代码示例。
229 0
|
4月前
|
机器学习/深度学习 监控 Serverless
无服务器架构
无服务器架构
|
4月前
|
负载均衡 安全 Cloud Native
云上负载均衡:构建高可用、高性能的网络应用架构
与云原生技术深度融合:随着云原生技术的普及和发展未来的云上负载均衡将更加紧密地与云原生技术相结合。例如与Kubernetes等容器编排平台集成实现自动化的服务发现和路由管理;与Serverless架构结合提供无缝的流量接入和请求处理能力。 安全性能提升:面对日益严峻的网络安全威胁云上负载均衡将更加注重安全性能的提升。通过引入加密传输、访问控制、DDoS防护等安全措施确保网络流量的安全性和隐私性;同时还将建立完善的安全监控和应急响应机制以应对各种安全事件和突发事件。 支持多协议和多场景:未来的云上负载均衡将支持更多种类的网络协议和应用场景以满足不同用户和业务的需求。例如支持HTTP/2、
237 0
|
5月前
|
Serverless 持续交付 测试技术
无服务器应用架构转型
【6月更文挑战第2天】Serverless架构虽新,但其软件生命周期仍遵循传统模式,需确保交付质量。
|
6月前
|
存储 物联网 Serverless
无服务器架构(Serverless)的革命性应用
无服务器架构是一种全新的云计算模型,它将传统的基于服务器的架构转变为以事件驱动的、按需自动化的架构。本文将探讨无服务器架构的定义、特点以及在现代应用开发中的应用。
239 2
|
存储 弹性计算 监控
无服务器架构的优势与挑战:解析FaaS和BaaS
随着云计算和微服务架构的发展,无服务器架构(Serverless Architecture)已经成为当今软件开发领域的热门话题。无服务器架构通过将服务器管理的责任交给云服务提供商,使开发人员能够专注于业务逻辑的编写,而无需关注基础设施的细节。本文将深入探讨无服务器架构的优势与挑战,并重点解析函数即服务(Function as a Service,FaaS)和后端即服务(Backend as a Service,BaaS)这两种常见的无服务器实现方式。
349 0
|
存储 安全 架构师
「无服务器架构」无服务器架构是应用程序的正确选择?需要考虑利弊。
「无服务器架构」无服务器架构是应用程序的正确选择?需要考虑利弊。