高并发服务器框架设计方案

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
简介: 这样的框架存在一个很严重的问题,当客户端高并发请求到来,服务器需要进行大量的数据库操作,假设数据库最大连接数为1000个,此时有10000个请求访问应用服务器

简单谈一谈高并发服务器框架设计的基本思路

基本的服务器框架都是C/S结构的,请求和相应流程是这样的:

gao1

这样的框架存在一个很严重的问题,当客户端高并发请求到来,服务器需要进行大量的数据库操作,假设数据库最大连接数为

1000个,此时有10000个请求访问应用服务器,那么应用服务器只能处理1000个请求,剩下99000个等待1000个请求处理好后

再进行访问数据库处理。可以在应用服务器和数据库服务器中间增加中间层DAL,DAL采用缓冲队列和连接池设计。

gao2

DAL设计缓冲队列,存储等待的请求,并且DAL中设计数据库连接池,当数据库连接池中有空闲连接,

那么从缓冲队列中取出一个请求处理,以此类推。这种做法有效的降低了服务器的压力,但是没有提高处理速度,

仅仅保证了请求被缓存,处理效率仍受限于数据库的并发数。那么可以再增加一层缓存,将常用的数据加载如缓存,

有请求到来时,应用服务器先从缓存中获取数据,如果缓存中有数据,那么不需要访问数据库,如果缓存中没有,

在访问数据库取出数据,并更新缓存。

gao3

缓存如何同步?

有两种手段:

第一种方法: 缓存是具有时效的,在一定时间过后会超时timeout,如果缓存失效,那么重新去数据库查询,

查询后更新缓存,这种方法不是实时的,实时性比较差。

第二种方法:当有请求修改数据时,更新缓存,并且将要修改的数据投入DAL层,当数据库有空闲连接时,再持久化

存盘。

缓存的不足之处:

当缓存足够多时,需要将不活跃缓存数据换出内存,叫做缓存换页。缓存换出算法和操作系统换页算法类似,FIFO,LRU(least recently used),

LFU(least frequently used)等。实际缓存的实现不需要自己去实现,有很多开源技术,nosql技术就是非关系型数据库的意思。

非关系型数据库如redis,memcatched等。缓存可以跟应用服务器部署在同一台机器上,也可以部署在单独机器上。我推荐将缓存服务器部署在

单独机器上,假设有两台应用服务器,如果将缓存部署在不同的应用服务器上,那么不同的应用服务器很难访问彼此的缓存,非常不方便。将缓存

部署在单独服务器上,各个应用服务器都能访问该缓存服务器。

gao4

如果有大量的业务请求到来,虽然设计了多个应用服务器,也架设了缓存服务器,完善了中间层的缓冲队列和数据库连接池,

但是数据库服务器仍然会出现瓶颈。比如当有大量复杂的写操作数据库,很多读数据库的操作就被阻塞了,为解决这个问题可

将数据库实现读写分离。由于数据库读操作会比写操作多,那么可以对数据库执行负载均衡。主流数据库都有replication机制,

采用replication机制可以实现负载均衡。中间层的写数据库操作投递到master数据库中,读操作从slave数据库中读取,

当master数据库中数据被修改后,数据库采用replication机制将数据同步给slave服务器。
gao5

同样的道理,应用服务器也可以实现负载均衡,架设多个应用服务器,不同的请求分配给不同的应用服务器。

可单独设计一个任务服务器监控各个应用服务器的负载情况,合理的分配任务给各个应用服务器。这种方式

是任务服务器主动地分配任务给应用服务器,应用服务器被动的接受任务,这种方式在任务请求类型相近的

情况下,分配方式非常合理。但是假设应用服务器A接受了3个任务,应用服务器B接受了5个任务,按照负载均衡的

权重法或最小连接法,肯定会分配给A任务,但是如果这3个任务都是复杂的写操作,而B的5个任务都是简单的

读操作,那么这就存在分配的不合理性,如何解决这个问题呢?

gao6

可以换一种思路去解决这个问题,让应用服务器主动去请求任务服务器,主动获取任务处理,如果应用服务器处于忙碌状态就不需要

请求新的任务,空闲的应用服务器会去请求任务服务器中的任务,这是最合理的负载均衡。如果所有应用服务器都处于忙碌状态,

那么任务服务器将任务缓存至自己的任务队列,当应用服务器空闲时会来取任务。

考虑这样一个问题,如果任务服务器出现故障怎么办?

任务服务器需要有多台,并且实现failover机制,多台任务服务器之间实现心跳,如果检测不到对方心跳,则使自己成为主任务服务器。

gao7

到目前为止,这个框架可以适用于大部分服务器逻辑。为保证数据库的响应速度和处理效率,可以对数据库进行分区。

数据库分区有两种形式(分库、分表)

分库:数据库可以按照一定的逻辑把表分散到不同的数据库。这叫做垂直分区,就是所每个库的表不同,功能不同。

这样做不常见,因为很大情况下,数据库中各个表是关联的,如果将不同的表分配到不同的数据库中,会存在很多不便。

分表:将一个表的不同数据分配到各个数据库,这样每个数据库的表结构是一样的,只是存储的用户数据不同而已,叫做水平

分区。分表的方式很常见,如果数据库的压力增加,我们就采取分表的方式减少数据库的压力。

另外服务器开发的几个性能杀手:

1 数据拷贝,数据从内核态copy到用户态,或者在用户态之间copy会造成性能损失,尽量采用缓存的方式解决。

2 环境切换 ,多线程上下文切换造成开销。如果服务器是单核的,那么采用状态机方式单线程效果最佳。如果是多核的,

合理采用多线程,可以提升性能。

3 内存分配,可以采用内存池,提前分配。

4 锁竞争,加锁解锁会造成一定的效率衰减。

到此为止,服务器框架介绍完毕。

高并发服务器框架设计方案用到的阿里云产品:

阿里云服务器ECS:https://www.aliyun.com/product/ecs
阿里云数据库RDS:https://www.aliyun.com/product/rds/mysql

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
目录
相关文章
|
1月前
|
存储 监控 NoSQL
140_异步推理:队列管理框架 - 使用Celery处理高并发请求的独特设计
在大型语言模型(LLM)部署的实际场景中,推理服务的并发处理能力直接影响用户体验和系统稳定性。随着LLM应用的普及,如何高效处理大量并发请求成为部署优化中的关键挑战。传统的同步请求处理方式在面对突发流量时容易导致系统过载,响应延迟增加,甚至服务崩溃。异步推理通过引入队列管理机制,能够有效缓冲请求峰值,平滑系统负载,提高资源利用率,从而为LLM服务提供更稳定、更高效的并发处理能力。
|
2月前
|
关系型数据库 Linux PHP
开源站群服务器方案:构建高效流量矩阵的全攻略
正在寻找高性价比、可控性强且功能强大的站群解决方案?小编将深度解析开源站群服务器方案,从核心优势、主流工具选型到部署实践,助您构建稳定、高效的站群流量体系。
|
2月前
|
数据采集 存储 弹性计算
高并发Java爬虫的瓶颈分析与动态线程优化方案
高并发Java爬虫的瓶颈分析与动态线程优化方案
|
3月前
|
存储 固态存储 Linux
从 0 学服务器虚拟化:VMware 搭建 3 个虚拟主机,个人 / 小企业够用的方案
服务器虚拟化技术通过在单台物理机上运行多个虚拟机,显著提升资源利用率和管理灵活性。本文以 VMware ESXi 8.0 Update 3e 为例,详解如何搭建经济实用的虚拟化环境,支持 3 个虚拟主机稳定运行,适合个人开发者和小企业降低硬件投入、实现数据本地化与安全存储。
649 0
|
4月前
|
运维 前端开发 JavaScript
半夜服务器告警不再错过!运维人员必备的语音通知方案
为解决深夜服务器宕机错过告警的问题,本文介绍一款专为个人开发者与运维人员设计的语音通知方案。通过电话直接推送重要告警,确保第一时间响应,避免故障扩大。支持多种编程语言调用,配置简单,3步即可完成,实时性强,适合各类关键业务场景。
339 5
|
3月前
|
弹性计算 监控 网络协议
香港云服务器访问速度慢?阿里云精品BGP线路EIP一键提速方案
香港云服务器因默认BGP线路访问不稳定,尤其中国大陆用户面临高延迟与丢包问题。本文详解问题根源,并介绍阿里云国际站推出的精品BGP线路EIP解决方案,通过直连优化显著降低延迟,提升稳定性,助力企业实现高效跨境网络访问。
|
3月前
|
运维 数据可视化 数据库
一小时搞定服务器软件部署:资深工程师实测方案
本文分享了一位运维工程师在短时间内将30个不同软件部署到新服务器上的实战经验。面对全新 Rocky Linux 系统,传统手工部署方式效率低下且容易出错。作者尝试多种自动化方案后,最终选择使用自动化部署工具,通过其内置的 Docker Compose 模板和可视化界面,实现快速、批量部署,大幅提升效率,30个应用仅用约1小时完成,显著节省时间和人力成本。
|
6月前
|
数据采集 Web App开发 监控
如何用Pyppeteer打造高并发无头浏览器采集方案
本文从电商行业数据采集痛点出发,结合 Pyppeteer 高并发无头浏览器技术,打造可配置代理的高效采集方案。通过爬虫代理突破 IP 限制,模拟真实用户行为,实现 Amazon 特价商品数据的稳定抓取与分析。代码示例详细展示了代理集成、并发控制及数据处理流程,实验验证效率提升超 4 倍。该方案助力商业决策、竞品分析,并支持技术扩展与创新应用。
221 13
如何用Pyppeteer打造高并发无头浏览器采集方案
|
5月前
|
NoSQL 安全 Java
Redisson框架使用:支持高并发的RBucket功能剖析
整体来看,无论你是在开发新的分布式应用,还是在维护一个现有的大型系统,Redisson 框架和 RBucket 功能都能为你提供非常大的帮助。正如扳手能让你轻松地拧紧螺丝,Redisson 和 RBucket 也能让你轻松处理并发的问题。一起来享受编程的乐趣吧!
296 10
|
6月前
|
NoSQL 算法 安全
redis分布式锁在高并发场景下的方案设计与性能提升
本文探讨了Redis分布式锁在主从架构下失效的问题及其解决方案。首先通过CAP理论分析,Redis遵循AP原则,导致锁可能失效。针对此问题,提出两种解决方案:Zookeeper分布式锁(追求CP一致性)和Redlock算法(基于多个Redis实例提升可靠性)。文章还讨论了可能遇到的“坑”,如加从节点引发超卖问题、建议Redis节点数为奇数以及持久化策略对锁的影响。最后,从性能优化角度出发,介绍了减少锁粒度和分段锁的策略,并结合实际场景(如下单重复提交、支付与取消订单冲突)展示了分布式锁的应用方法。
447 3

热门文章

最新文章